GSM Association Ir32 - pt1

GSM Association
Official Document: IR.32 UNRESTRICTED

Part 1
End-to-End Functional Capability Specification for

Inter-PLMN CAMEL-Roaming
(CAMEL Phase 1, Phase 2 and Phase 3)
Part 1: Test Specification
Version 3.3.3
???? 2005
Security Classification Category (see next page):

Unrestricted X
UNRESTRICTED Version 3.3.3 Page 1 of 165

GSM Association
Part 1
Security Classification: Unrestricted

This document is subject to copyright protection. The GSM Association (“Association”)
makes no representation, warranty or undertaking (express or implied) with respect to and
does not accept any responsibility for, and hereby disclaims liability for the accuracy or
completeness or timeliness of the information contained in this document. The information
contained in this document may be subject to change without prior notice. Access to and
distribution of this document by the Association is made pursuant to the Regulations of the
Association.
Copyright Notice
Copyright © 2005 GSM Association
GSM™ and the GSM Logo™ are registered and the property of the GSM Association.
Document History
Version Date Brief Description

IREG Doc 10/99 with changes according to 1st Meeting of IREG
0.0.1 15.07.1999
CAMEL
0.0.3 05.08.1999 Changes according to 2nd Meeting of IREG CAMEL-WP
0.0.4 06.09.1999 Pre-Final Version; Input for IREG #37.
3.0.0 21.09.1999 Final Version for approval
3.0.1 12.01.2000 Changes according to 3rd Meeting of IREG CAMEL-WP
3.0.2 31.01.2000 Changes according to 5th Meeting of IREG CAMEL-WP
Changes according to email discussions since the 5th Meeting of IREG
3.0.3 13.03.2000
CAMEL-WP
3.1.0 14.03.2000 Changes according to 6th Meeting of IREG CAMEL-WP
Clarification in test case 2.1.5
Corrections to test case 2.2.4 and according change in Appendix B
2.2.4
Corrections to test case 2.2.7
3.1.1 06.02.2001
Correction in chapter 3.1
Corrections to appendix B 2.1.4
Corrections to appendix B 2.1.5
Corrections to appendix B 2.1.8.1
3.2.0 21.10.2001 Changes according to 8th and 9th Meeting of IREG CAMEL-WP
Test cases 2.1.6.1, 2.1.6.2, 2.2.8.1 and 2.2.8.2: In case SCP does not
allow sending no answer to IDP an Abort message should be sent.
Chapter 2.3 “Camel Phase 3” includedChanges
3.3.0 31.01.2003
Chapter 3.4 “User Equipment for CAMEL phase 3 tests” included
Annex A.1 enhanced with CAMEL Ph3 information
Annex A.3 included
3.3.1 22.05.2003 Test-sheets for CAMEL Ph3 added
3.3.2 20/10/2004 Corrections to test case 2.2.6.3
Corrections to test case 2.2.6.1
3.3.3 13/10/2005
Corrections to test case 2.2.6.3
References
GSM CAMEL CAMEL
Specification Phase1 Phase2
"Customised Applications for Mobile network Enhanced

GSM 02.78 V5.6.0 V6.3.0
Logic (CAMEL); Service definition – Stage 1"

GSM Association
Part 1
GSM CAMEL CAMEL

Specification Phase1 Phase2
"Customized Applications for Mobile network Enhanced
GSM 03.78 V5.8.0 V6.4.1
Logic (CAMEL) – Stage 2"
"Customized Applications for Mobile network Enhanced
GSM 09.78 V5.6.0 V6.4.0 Logic (CAMEL); CAMEL Application Part (CAP)
specification"
GSM 09.02 V5.9.0 V6.4.0 "Mobile Application Part (MAP) specification"
3GPP
CAMEL Phase3
Specification
“Customised Applications for Mobile network Enhanced
3GPP TS 22.078 V3.9.0 Logic (CAMEL); Service description, Stage; (Release
1999)”
3GPP TS 23.078 V3.13.0
Logic (CAMEL) Phase 3 - Stage 2; (Release 1999)”

3GPP TS 29.078 V3.12.0 Logic (CAMEL) Phase 3; CAMEL Application Part (CAP)
specification;(Release 1999)”
“Mobile Application Part (MAP) specification; (Release
3GPP TS 29.002 V3.13.0
1999)”
Other Information
Type Description
Document Owner IREG
Revision Control Semi-annual
Document editor/company Javier Sendin
Feedback
This document is intended for use by the members of GSMA. It is our intention to provide a
quality product for your use. If you find any errors or omissions, please contact us with your
comments. You may notify us at mailto:[email protected]. Your comments or suggestions are
always welcome.

GSM Association
Part 1
Table of Contents
1 INTRODUCTION 6
1.1 SCOPE OF DOCUMENT 6
1.2 ABBREVIATIONS 6
1.3 OBJECTIVE OF TESTS 9
1.4 STRATEGY FOR TESTING 11
1.5 SERVICE LOGIC 12
1.6 PREREQUISITES FOR TESTING 15
2 TEST CASES 16
2.1 CAMEL PHASE 1 17
2.1.1 Location Update 19
2.1.2 Check operation of IDP and CON 21
2.1.3 Check operation of PSI 23
2.1.4 Check reporting of EDP O_Answer and operation of RC 25
2.1.5 Check operation of CUE 27
2.1.6 Check Default Call Handling 29
2.1.7 Check Suppression Of Announcement 31
2.1.8 Interaction with GSM Supplementary Services and ODB 33
2.2.1 Location Update 41
2.2.2 Check Operation of IDP and DP2 Criteria 43
2.2.3 Check operation of PSI 47
2.2.4 Check reporting of EDP O_Answer, O_Disconnect… 49
2.2.5 Check operation of CUE and FCI with Follow-On Call 51
2.2.6 Check operation of CIReq, SCI and AC 57
2.2.7 Check operation of ETC and DFC 69
2.2.8 Check Default Call Handling 72
2.2.9 Check Suppression Of Announcement 74
2.2.10 Interaction with GSM Supplementary Services and ODB 76
2.3.1 MO SMS Control 85
2.3.2 GPRS Control 100
2.3.3 Mobility Management 143
3 EQUIPMENT REQUIREMENTS 148
3.1 GENERAL 148
3.2 USER EQUIPMENT FOR CAMEL PHASE 1 TESTS 148
3.5 TEST EQUIPMENT 151
4 PRE-TESTING DATA EXCHANGE 153
4.1 TESTING CONTACT INFORMATION 153
4.2 PLMN ADDRESSING, NUMBERING AND ROUTING DATA 153
4.3 SIM ASSOCIATED DATA 153
4.4 TEST SERVICE ASSOCIATED DATA 153
APPENDIX A 156
A.1 PROTOCOL INFORMATION FLOWS AND FEATURES REFERENCE LIST 156
A.2 OVERVIEW OF CAMEL PHASE 1 FEATURES 159
A.3 OVERVIEW OF CAMEL PHASE 2 FEATURES 160
A.4 OVERVIEW OF CAMEL PHASE 3 FEATURES (IN ADDITION TO CAMEL PHASE 2)162

GSM Association
Part 1
A.5 TEST ANNOUNCEMENTS 164
A.6 TEST NUMBERS 164
A.7 TEST APNS 165

GSM Association
Part 1
1 Introduction
1.1 Scope of document
This document contains the specification of IREG End-to-end Functional Capability tests
relating to the international roaming of a Mobile Station subscribed to CAMEL services,
belonging to a home PLMN(a), to and within a visited PLMN(b).
The tests specified here do not replace the End-to-end Functional Capability tests for Inter-
PLMN Roaming [see Stage 4: IREG PRD IR24], because not every roamer will be
subscribed to a CAMEL service. This document represents rather an extension to the IR24
tests. The tests should be done after successful Stage 4 testing.
Whilst it is expected that CAMEL-roaming will be a bilateral activity between two PLMNs,
please note that this document is written in an unidirectional context. Hence Roaming is
taking place by a MS(a) to VPLMN(b) only. There is no reference to a Mobile Station MS(b)
visiting PLMN(a) .
To complete IREG End-to-end Functional Capability tests for bilateral CAMEL roaming, it is
necessary to perform the tests in this document twice: the second time the real identities of
PLMN(a) and PLMN(b) are swapped.
IREG Document PRD IR23 defines the scope and purpose of each stage of testing.
This document does not cover:

• SCCP testing [see Stage 2: IREG PRD IR25]
• Exchange of PLMN numbering, addressing and routing data [see Stage 3:
IREG PRD IR23]
• Testing of Transferred Account Procedure, billing applications and any
inter-PLMN financial statements; [see TADIG PRD TD06]. However the
production of a Toll Ticketing file, for use in the TADIG Stage 3 testing is
included.
• Definition of operation and maintenance procedures such as contact
points for fault reporting and notification of planned works. [See Stage 3:
IREG PRD IR23]
• IR24 International Roaming testing. [See Stage 4: IREG PRD IR24]
• OR aspects: it is assumed that the IMSC is always located in the HPLMN
The Scope of this issue of the document extends to CAMEL Phase 1 and Phase 2.
1.2 Abbreviations
AAC Automatic Answering Circuit
AACx destination Number of announcement x
ABT TCAP-Abort
AC CAP-Apply Charging
ACgprs CAP-Apply Charging GPRS message
ACR CAP-Apply Charging Report
ACRgprs CAP-Apply Charging Report GPRS message
ANM ISUP-Answer
AoCI Advice of Charge Information
APN Access Point Name
ARI CAP-Assist Request Instructions

GSM Association
Part 1
AT CAP-Activity Test
ATI Any Time Interrogation
CAMEL Customised Applications for Mobile networks using Enhanced Logic

CAP CAMEL Application Part
CC Country Code
CIRep CAP-Call Information Report
CIReq CAP-Call Information Request
CON CAP-Connect
CONgprs CAP-Connect GPRS message
CPD max Call Period Duration
CS Circuit Switched
CSE CAMEL Service Environment
CTR CAP-Connect To Resource
CUE CAP-Continue
CUEgprs CAP-Continue GPRS message
DFC CAP-Disconnect Forward Connection

DNc Destination Number which is located in country(c)
DRA Destination Routing Address
EDP Event Detection Point

ERB Event Report BCSM
ERELgprs CAP-Entity Release GPRS message
ERgprs CAP-Event Report GPRS message
ETC CAP-Establish Temporary Connection
FCI CAP-Furnish Charging Info

FCIgprs CAP-Furnish Charging Information GPRS
FFD Free Format Data
FTN Forwarded To Number
GMSC Gateway Mobile Services Switching Centre
HLR Home Location Register

HPLMN Home PLMN
IAM ISUP-Initial Address Message

IDP CAP-Initial DP
IDPgprs CAP-InitialDP GPRS message
IMSC Interrogating MSC
IR International Roaming
ISD Insert Subscriber Data
METime maxElapsedTime
MM Mobility Management
MS Mobile Station (MS(b) indicates that the MS subscription is managed by
PLMN(b)
MSIN Mobile Subscriber Identification Number
MTVol maxTransferredVolume
NDC Network Destination Code
O-CSI Originating CAMEL Subscription Information

GSM Association
Part 1
ODB Operator Determined Barring
OR Optimal Routing
PA CAP-Play Announcement
PCCoP PDP Context Change of Position
PCD PDP Context Disconnection
PCE PDP Context Establishment
PDP Packet Data Protocol
PLMN Public Land Mobile Network including RSS ("Radio Sub-System") and NSS
("Network Sub-System") (PLMN(a) indicates the "ath" PLMN)
PSI MAP-Provide Subscriber Information
PSTN Public Switched Telephone Network; PSTN(b) indicates a PSTN telephone in
country b.
RC CAP-Release Call
REL ISUP-Release
Rgprs CAP-Release GPRS message
RIDE Release If Duration Exceeded
RRBE CAP-Request Report BCSM Event
RRgprsE CAP-RequestReportGPRSEvent message
SCF Service Control Function

SCI CAP-Send Charging Info
SCP Service Control Point
SGSN Serving GPRS Support Node
SM Short Message
SMS Short Message Service
SMSC Short Message Service Centre
SoA Suppression of Announcement
SRF Specialized Resource Function
SRR CAP-Specialized Resource Report
SS Supplementary Services
TAP Transferred Account Procedure

TC_Begin TCAP-Begin message
TC_CUE TCAP-Continue message
TC_END TCAP-End message
TgprsINTS TimeGPRSIfNoTariffSwitch
TgprsSLTS TimeGPRSSinceLastTariffSwitch
TgprsTSI TimeGPRSTariffSwitchInterval
TINTS Time If No Tariff Switch
TS Tariff Switch
TSI Tariff Switch Interval
TSLTS Time Since Last Tariff Switch
VMSC Visited Mobile Services Switching Centre, including the always co-located
entities MSC ("Mobile Services Switching Centre") and VLR ("Visitor Location
Register").
VolINTS VolumeIfNoTariffSwitch
VolSLTS VolumeSinceLastTariffSwitch
VolTSI VolumeTariffSwitchInterval
VPLMN Visited PLMN

GSM Association
Part 1
1.3 Objective of tests

The fundamental objective of this testing is to confirm the capability of CAMEL services
which GSM users subscribed-to these services will receive when roaming from their Home
PLMN(a) to PLMN(b). Consequently the tests are restricted to top-level capability testing.
There is no provocative or inopportune behaviour testing.
Because the testing is at a top-level, its scope includes checking the correct working of
CAMEL features. The term "CAMEL features" relate to CAMEL Phase 1 and Phase 2
through the document.
The overall objective of the tests is to confirm that the CAMEL features, which are known to
operate correctly within each separate PLMN, will also operate correctly for Inter-PLMN
roaming.
The specific objectives:

• "Location updating" and the associated "Inserting of Subscriber data"
including O-CSI can be successfully completed for MS(a) roaming in
PLMN(b).
• "Provide Subscriber Info" is successfully executed.
• Outgoing speech calls by MS(a) are handled for:
− Calls to VPLMN(b) country (i.e. local calls)
− International calls
• Encountered Event Detection Points are reported correctly.
• SCF is able to terminate calls.
• The default call handling described in O-CSI is correctly executed.
• Suppression of announcements in VMSC is successfully executed.
• Interworking with GSM SS and ODB is correctly executed.
Specific objectives for CAMEL Phase 2

• IDP Trigger Criteria are correctly executed.
• Encountered Event Detection Points lead to successful Follow-On calls
and reconnections, respectively.
• Control of call duration, transmission of Advice Of Charge parameters and
the report of specific information about a single call party are successfully
executed.
• The assist procedure to connect a roaming subscriber to an IN-
announcement located in his HPLMN is successfully executed.
• The operation of SS-CSI is correctly executed.
The following topics are not tested:

General topics
• Features regarding terminating CAMEL services are not tested, because
they are not relevant in the roaming environment as long as optimal
routing is not supported. SoA is an exception that is tested.
• Charging aspects are not specifically verified here. However TAP Records
will be produced, which may be used to check charging procedures.
WARNING: CAMEL specific parameters will be included in TAP Records!
• "Any Time Interrogation" over network boundaries is not tested, because
this requires specific agreements between the involved operators.
• Termination of call establishment via ReleaseCall is not tested to reduce
expenditure.

GSM Association
Part 1
• It is not tested, that in case an emergency call is requested, the SCF is not
invoked. It is recommended to run this test during VPLMN internal tests.
• The ActivityTest information flow is not tested, because the initiation timers
are SCP dependent.
Topics related to CAMEL Phase 1

• Provocative reconnection after a reported disconnect event is not tested.
This is a scenario, which is not allowed in CAMEL Phase 1 and could lead
to billing problems. It is recommended to run this test scenario during
VPLMN internal tests.
• Reporting of disconnect events is not tested, because it is not possible to
make this event visible to the tester without using a protocol analyser.
However the ability to arm a disconnect event detection point is part of the
tests.
Topics related to CAMEL Phase 2

• IDP Trigger Criteria tests are restricted to the Destination-Number-Length
criteria to reduce expenditure. The other Trigger Criteria are not tested.
• The following SRF information flows are not tested over network
boundaries: CAP-ResetTimer, CAP-PromptAndCollectUserInfo, CAP-
ConnectToResource, CAP-PlayAnnouncement and CAP-
SpecializedResourceReport. On medium-term the usage of IN-
announcements in foreign PLMNs is not expected. Thus the information
flow CAP-ARI is only used inside the HPLMN(a) and is not tested over
network boundaries.
• CAP-Cancel is not tested because the usage of this information flow in
foreign PLMNs is not expected on medium-term.
• The support of USSD communication between MS and gsmSCF is not
tested because the transmission of the USSD from the HLR to the
gsmSCF is inside PLMN(a) and thus no IR topic. It is recommended to
run this test during HPLMN internal tests.
• Testing of the support of alerting categories downloaded from SCF is not
considered as important.
• Testing of the support of CellID in geographical data to give the VLR the
option to return a stored CellID in response to a request for location
information is not considered as important.
• The support of forwarded-to-numbers in SPNP or other short number
format by CAMEL supporting VLRs is a pure HLR functionality and thus
not part of IREG testing. It is recommended to run this test during HPLMN
internal tests.
• Reporting of abandon events is not tested, because it is not possible to
make this event visible to the tester without using a protocol analyser.
Topics related to CAMEL Phase 3: Circuit Switched Call Control

• Features already available in CAMEL Phase 2 are not tested for CAMEL
Phase 3 because it is assumed, that HPLMN(a) will choose CAMEL Ph2
O-CSI for this purpose.
• The information flow CAP-ContinueWithArgument is not considered as
important, because also CAP-CON may be used by services for the same
purpose. Thus CAP-ContinueWithArgument is not tested here.
Topics related to CAMEL Phase 3: MO SMS control

GSM Association
Part 1
• The information flow CAP-FurnishChargingInformationSMS is not
considered as important and thus not tested here.
• The information flow CAP-ResetTimerSMS is not considered as important
and thus not tested here.
Topics related to CAMEL Phase 3: GPRS control

• Because of the high expenditure to be spent in VPLMN(b)
ChangeOfPosition is not tested.
• The information flow CAP-SendChargingInformationGPRS - used for AoC
- is not considered as important and thus not tested here.
• The information flow CAP-CancelGPRS is not tested because the usage
of this information flow in foreign PLMNs is not expected on medium-term.
• The information flow CAP-ResetTimerGPRS is not considered as
important and thus not tested here.
• The information flow CAP-ActivityTestGPRS is not tested, because the
initiation timers are SCP dependent.
Topics related to CAMEL Phase 3: general

• The features within “Control and interrogation of subscription data” are
only used inside the HPLMN(a) and thus they are not tested over network
boundaries.
• The feature AoC within CAMEL Phase 3 is not considered as important
and thus not tested here.
• It is not expected on medium-term that operators will use the feature
“Terminating CAMEL Subscription Information for the VMSC (VT-CSI)”,
thus no tests are included.
• There are no tests included for Trigger Detection Points
“DP Analysed_Information” and “DP Route_Select_Failure” because they
are not considered as important.
• “Network Service CAMEL Subscription Information (N-CSI)” identifies
services offered on a per-network basis by the VPLMN operator, and so it
is out of scope for international roaming tests.
• “Dialled Service CAMEL Subscription Information (D-CSI)” is not tested,
because it is not expected that operators will use this feature on medium-
term.
• The information flow CAP-CallGap is not tested because it is unlikely that
overload will origin from a VMSC and the feature is very hard to test in an
international roaming environment.
• Parts within CAMEL Phase3 regarding Support of Optimal Routing are not
tested because no operator has yet announced to use SOR.
1.4 Strategy for Testing

To execute the described test cases a CAMEL test service is required. In order to maximise
the efficiency of testing, the test cases have been drawn up so as to minimise the
requirement for simultaneous joint activity by both PLMN(a) and PLMN(b). This concerns on
the one hand the administration of mobile subscriber data in the HLR and on the other hand
the administration of data for the CAMEL test service. To achieve this, the required reaction
of the SCF follows from the dialled digits (Figure 1).
In the test service for CAMEL Phase1 and Phase2 a list of dialled numbers, called
destination list, is included. The numbers listed here are linked to a corresponding action,
which is required for the specific test case.

GSM Association
Part 1
Within CAMEL Ph3 SMS Control the combination of SMSC address,

DestinationSubscriberNumber and CallingPartyNumber is used in the test service to
determine the appropriate action. For GPRS Control the gprsEventType and the APN and for
Mobility Management the parameter eventMet within the information flow NoteMMEvent is
used for this purpose.
Additionally the test cases have been drawn up so that it is possible to execute them
automatically.
The test programme consists of three distinct components:

1. HPLMN(a) issues pre-programmed SIM cards and programmes HLR and the
Service Logic
2. PLMN(b) performs tests
3. PLMN(b) and HPLMN(a) discuss results.
Figure 1: Schematic representation of the test service for CAMEL Ph1 and Ph2.
1.5 Service logic

A description for the implementation of the originating and the terminating service logic entry
processes is show in chapter 2.1 for CAMEL Phase1 and chapter 2.2 for CAMEL Phase 2 by
means of a SDL diagram. The actions referred to in these diagrams are described at the end
of the single test cases.
General requirements for the implementation of the service logic are detailed below:

GSM Association
Part 1
• Four different service keys are used for originating and terminating
triggered services in CAMEL Phase 1 and Phase 2. The ability to
administrate these service keys has to be given.
• Only the parameters included in the SDL diagrams for received messages
have to be checked from the service logic. If no value is given here, only
the existence has to be checked. There may be additional parameters
included; these should not influence the service behaviour.
• Only the parameters shown in the SDL diagrams have to be included in
the outgoing messages.
• The service logic shall only follow the explicitly shown behaviour,
otherwise go into the idle state and not continue the call handling. This is
necessary to avoid success test cases after error conditions.
• The ability to administrate the numbers in the destination list has be given.
This applies to:
4. Test Numbers: TestNbr1, ...
5. Destination numbers of announcements: AAC1, ...
6. Country code (CC) and network destination code (NDC) of country(a)
• The ability to configure several different network destination codes of
country(a) has to be given. In case a number has to be compared to
CC+NDC of country(a), this has to be done for each NDC configured (see
test case 2.1.3). HPLMN(a) has to take care, that all the NDCs of the SIM
cards used for IREG CAMEL tests (MSx(a)) are listed in the destination
list.
• The ability to administrate the destination number located in country(c),
DN(c), has to be given.
• The service logic shall be designed in a way that SCCP-XUDT messages
as a result of multiple operations in one TCAP message are not used.
XUDT messages will not be supported throughout all networks.
The following shows the entries in the destination list:
Originating Service Terminating Originating Service Terminating

Logic: CAMEL Service Logic: Logic: CAMEL Service Logic:
Phase 1 CAMEL Phase 1 Phase 2 CAMEL Phase 2
TestNbr1 CC+NDC TestNbr4 CC+NDC
TestNbr2 TestNbr5
TestNbr3 TestNbr6
AAC1 TestNbr7
AAC2 TestNbr8
AAC3 TestNbr9
CC+NDC1 TestNbr10
CC+NDC2 AAC4
... (Support of AAC5
several different CC+NDC1
NDCs) CC+NDC2
... (Support of
several different
NDCs)

GSM Association
Part 1
Additionally a data Additionally a data
field for the field for the
destination number destination number
in country(c), DN(c), in country(c), DN(c),
has to be available. has to be available.

GSM Association
Part 1
1.6 Prerequisites for testing

This section describes the pre-requisites that PLMNs are strongly recommended to have
completed prior to the start of CAMEL IREG testing as specified in this PRD.
The activity of inter PLMN testing will take place more effectively and efficiently if the two
PLMNs have already independently acquired practical expertise in the functions which are
being tested. Accordingly it is recommended that prior to the start of inter-PLMN testing of
CAMEL functionality, the two PLMNs have already achieved the following:
• Basic Roaming capability with several PLMNs, as specified in PRD IR24.

• CAMEL protocol level tests, to make sure, that CAMEL works properly in
the own PLMN.
• Practical experience of using CS-1, Core-INAP or CAMEL protocols within
their own PLMN. This practical experience should include the setting of
MSC/SSP and/or CAMEL server datafill, the ability to analyse the
CAP/INAP protocol and familiarity with the "test" service logic to be used in
the CAMEL server. It is recognised that the practical experience may need
to be gained from a test laboratory or demonstration/trial network.
Additionally, it is highly recommended that the service logic be very carefully tested in the
HPLMN(a) before starting International Roaming Tests. This is necessary because the IREG
tester in VPLMN(b) cannot determine, that the service logic for the test case is being
correctly invoked. If there are errors in the service logic, the test results will be unreliable.
HPLMNs are recommended to ensure that there is adequate control within their HLRs and
network infrastructure to allow the following types of roaming to exist simultaneously either
as independent or overlapping sets of VPLMNs:
• “IR24” roaming to be in operation with a VPLMN or set of VPLMNs for
Test SIMs,
• “IR24” roaming to be in operation with a different set of VPLMNs for all
customers,
• “CAMEL” roaming to be in operation with a further set of VPLMNs for Test
SIMs,
• “CAMEL” roaming to be in operation with a fourth set of VPLMNs for all
customers
Warning: Some implementations do not allow to provide CAMEL roaming on a per service
level. This may lead to the situation, that after introduction of CAMEL roaming for test
purposes, all CAMEL services of HPLMN(a) are accessible in VPLMN(b).

GSM Association
Part 1
2 Test cases
The test configuration is shown in Figure 2 below. It is anticipated that it may be necessary to
monitor both signalling messages and voice calls on any of the Network Entity interfaces
shown in the diagram. However this is not a firm requirement for this test specification.
With the destination numbers of announcement 1 to 3, AAC1 to AAC3, used in the service
logic to select a specific SCF action the corresponding AAC is reached.
The description of the test cases are built up as detailed below:

• Title
• Short textual test overview
• Informative Message flow (The message flows are not claimed to be
complete)
• Textual description of preconditions, actions, service logic, results and
comments
• Description of the service logic by means of a SDL diagram
Note: In some test cases the AACs are called directly from the MS. In this case, the
international format for type of number shall be used, that is, “+” shall be dialled when setting
up a call.
Figure 2: Test case Configuration

GSM Association
Part 1
2.1 Camel Phase 1

Originating Service Logic: CAMEL Phase 1
Idle
Signals to/from the left
are to/from the SSP.
IDP
Analyse
CalledPartyBCDNumber/
CalledPartyNumber *
calledPartyBCDNumber = TestNbr1
o1_1
calledPartyBCDNumber consists of CC + NDC of country(a)

and a MSIN which is not included in the destination list
o1_2
o1_3
CC + NDC of calledPartyBCDNumber differs from CC +

NDC of country (a)
o1_4
calledPartyBCDNumber = AAC1
o1_5
o1_6
calledPartyNumber = AAC3
o1_7
o1_8
* Note: Use Best Fit algorithm to branch into the proper path.
Figure 3: Entry process for originating service logic: CAMEL Phase 1

GSM Association
Part 1
Terminating Service Logic: CAMEL Phase 1
Idle
IDP
Analyse
CalledPartyNu
mber
calledPartyNumber consists of CC + NDC of country(a) and
a MSIN which is not included in the destination list
t1_1
Figure 4: Entry process for terminating service logic: CAMEL Phase 1

GSM Association
Part 1
2.1.1 Location Update

Message-flow:
VLR(b) HLR(a)
updateLocation
ISD(O-CSI)
ISD Res(supportedCamelPhases)
updateLocation Res
2.1.1.1 Location Update by MS1(a) in VPLMN(b)
Overview:
MS1(a) registers in VPLMN(b). The successful insertion of subscriber data –
example: O-CSI – in the VLR is verified.
Preconditions: MS1(a) contains SIM of HPLMN(a).
No VLR record exists for MS1(a).
HLR record contains basic and supplementary service
information as well as O-CSI.
Action: Power-up MS1(a) and perform location registration on VPLMN(b).
Check VLR record for the IMSI/MSISDN of MS1(a).
Service logic: -
Result: Successful result if at least the following entries are included in
VLR record:
Teleservice TS11 provisioned
SS: BOICexHC : Provisioned
SS: CFNRy : Provisioned
O-CSI
TriggerDetectionPoint: CollectedInfo, DP2
ServiceKey: equal to information provided by
HPLMN(a)
gsmSCFAddress: equal to information provided by
HPLMN(a)
defaultCallHandling: continueCall
Comments: This test case confirms operation of Insert Subscriber Data
procedure including O-CSI and that the required subscriber
profile for MS1(a) is available. If the required subscriber profile is
not included in the VLR, the error has to be sorted out before
continuation of tests.
SCP Service Logic

The service logic is not involved here.

GSM Association
Part 1
Overview:
MS2(a) registers in VPLMN(b). It is verified, that the required subscriber
profile for MS2(a) – example: O-CSI – is available.

HLR record contains basic and supplementary service
information as well as O-CSI.
Service logic: -
Result: Successful result if the following entries are included in VLR
record:
ODB-BOICexHC : Active
O-CSI
HPLMN(a)
HPLMN(a)
defaultCallHandling: releaseCall
Comments: This test case confirms that the required subscriber profile for
MS2(a) is available. If the required subscriber profile is not
included in the VLR, the error has to be sorted out before
continuation of tests.
SCP Service Logic


GSM Association
Part 1
2.1.2 Check operation of IDP and CON

Overview:
MS1(a), registered in VPLMN(b), makes a call to TestNbr1. Depending on
InitialDP contents, either Test Announcement 1 (AAC1) or Test
Announcement 2 (AAC2) is played. The contents of InitialDP are checked and
the operation of CAP-Connect is verified.
Message-flow:
SSP(b) SCP(a)
IDP(ServiceKey, TestNbr1 )
(i)
CON(AAC1 )
(ii)
CON(AAC2 )
Preconditions: MS1(a) has location updated successfully in VPLMN(b). HLR

entry for MS1(a) contains "O-CSI". [Set by HLR Admin]
Action: MS1(a) attempts a call to TestNbr1.
Service logic: IDP.calledPartyBCDNumber consists of TestNbr1:
(i) If SCF has received all required parameters within the IDP, the
SCF alters the destination address to be that of Test
Announcement 1.
SCF sends Connect.
(ii) If SCF does not receive all parameters within the IDP, the
SCF alters the destination address to be that of Test
Announcement 2.
SCF sends Connect.
Result: (i) Successful result if Test Announcement 1 is played to calling
party.
(ii) If Test Announcement 2 is played to calling party, at least one
parameter of the IDP is missing and the test has failed.
Comments: This test case confirms operation of IDP and Connect and
ensures that all parameters are present in the IDP. If no
announcement is played, a fundamental error has occurred and it
has to be sorted out before continuation of tests.

GSM Association
Part 1
SCP Service Logic
The following Parameter are

included in IDP:
serviceKey
are to/from the SSP. o1_1
callingPartyNumber
callingPartysCategory
locationNumber
bearerCapability
eventTypeBCSM
Yes
IMSI
locationInfomation.cellIdOrLAI
locationInformation.ageOfLocationInfo
locationInformation.VLRNumber
callReferenceNumber
MSCNumber
No CalledPartyBCDNumber
DRA = AAC1 DRA = AAC2

CON CON
Idle
Note: Additional parameter may be included in IDP. This still leads to CON(DRA=AAC1).

GSM Association
Part 1
2.1.3 Check operation of PSI

Overview:
MS1(a) makes a call to MS2(a), both registered in VPLMN(b). Depending on
the subscriber state retrieved, either Test Announcement 1 (AAC1) is played
or the call is connected. The operation of ProvideSubscriberInfo and the
correct reporting of the subscriber state is verified.
Message-flow:
SSP(b) SCP(a) HLR(a) VLR(b)
IDP(ServiceKey, MS 2(a) )
ATI(locationInfo, subscriber State, gsmSCFAddress )
PSI(locationInfo, subscriber State )
PSI Res (locationInfo, subscriber State )
ATI Res (locationInfo, subscriber State )
(i)
CON(AAC1 )
(ii)
CUE
Preconditions: MS1(a) and MS2(a) have location updated successfully in

VPLMN(b). HLR entry for MS1(a) contains "O-CSI". [Set by HLR
Admin]
MS2(a) is busy.
Action: MS1(a) attempts a call to MS2(a).
Service logic: IDP.calledPartyBCDNumber consists of CC+NDC of country (a)
and a MSIN which is not included in the destination list:
SCF starts Any Time Interrogation and requests Location
Information and Subscriber State of MS2(a).
(i) If subscriber state in Any Time Interrogation Result equals

camelBusy, SCF alters destination address to that of Test
Announcement 1 and sends CON.
(ii) If subscriber state is any other, SCF sends CUE.
Result: Successful result if Test Announcement 1 is played to calling
party.
If the busy tone is played to calling party, the subscriber state
was incorrect.
Comments: This test case confirms operation of Provide Subscriber
Information to retrieve a correct subscriber state.

GSM Association
Part 1
SCP Service Logic

Signals to/from the right
are to/from the HLR.
o1_2
msisdn = IDP.calledPartyBCDNbr
locationInformation
subscriberState
gsmSCFAddress ATI
ATI
Res
The following parameters are

included in ATI Res:
locationInformation.vlrNumber
Yes subscriberState = camelBusy
No
DRA = AAC1
CON CUE
Idle

GSM Association
Part 1
2.1.4 Check reporting of EDP O_Answer and operation of RC

Overview:
MS1(a), registered in VPLMN(b), makes a call to TestNbr2. 10 seconds after
Test Announcement 3 is connected to calling party, the call is released from
SCP. The operation of RequestReportBCSMEven, EventReportBCSM and
ReleaseCall is checked.
Message-flow:
SSP(b) SCP(a)
RRBE([O_Answer, notify ], [O_Disc, interrupted, legID=1 ], [ O_Disc, interrupted , legID=2 ])+CON(AAC3 )
ERB(O_Answer )
t=10 sec.
RC(NormalCallClearing )
Preconditions: MS1(a) has location updated successfully in VPLMN(b). HLR

entry for MS1(a) contains "O-CSI". [Set by HLR Admin]
Action: MS1(a) attempts a call to TestNbr2 and waits until the call is
disconnected.
The SCF alters the destination address to be that of Test
Announcement 3.
SCF sends RRBE([O_Answer, notify], [O_Disc, interrupted,
legID=1], [O_Disc, interrupted, legID=2])+CON. After reception of
ERB(O_Answer) SCF starts a timer of length 10 seconds. SCF
sends RC after expiration of this timer.
party and the call is released after 10 ±1 seconds from SCP.
If the connection to Test Announcement 3 is not disconnected
after 10 (±1) seconds, the test has failed.
Comments: This test case checks correctly reporting of EDP-N7, O_Answer,
and the ability to arm EDP-N9, O_Disconnect. Additionally the
operation of RC is checked.

GSM Association
Part 1
SCP Service Logic

are to/from the SSP. bcsmEvents
are to/from SCP-internal bcsmEvent
sub-processes. eventTypeBCSM = oAnswer (7)
o1_3
monitorMode = notifyAndContinue (1)
bcsmEvent
eventTypeBCSM = oDisconnect (9)
monitorMode = interrupted (0)
RRBE legID
sendingSide
Leg Type = leg1
bcsmEvent
CON legID
sendingSide
Leg Type = leg2
destinationRoutingAddress = AAC3
ABT ERB
eventTypeBCSM = oAnswer (7)
miscCallInfo
messageType = notification (1)
Start
Timer
Timer value = 10 sec.
Wait for
Timer
Expiration
Timer
ABT
expired
cause = normalCallClearing
RC
Idle

GSM Association
Part 1
2.1.5 Check operation of CUE

Overview:
MS1(a) makes a call to MS3(b), both registered in VPLMN(b). The operation of
CAP-Continue is checked. EDP-N9 is armed
Message-flow:
SSP(b) SCP(a)
IDP(ServiceKey, MS 3(b) )
RRBE([O_Disc, notify, legID=2 ])+CUE
ERB([O_Disc, notify, legID=2 ])
Preconditions: MS1(a) and MS3(b) have location updated successfully in

VPLMN(b). HLR entry for MS1(a) contains "O-CSI". [Set by HLR
Admin]
Action: MS1(a) attempts a call to MS3(b). MS3(b) accepts the call and the
call is established. Later MS3(b) disconnects the call.
Service logic: CC + NDC of IDP.calledPartyBCDNumber differs from CC + NDC
of country (a): SCF sends RRBE([O_Disc, notify, legID=2])+CUE.
Result: Successful result if call is established to MS3(b).
Comments: This test case checks operation of CUE. It is also possible for the
tester to check whether EDP-N9 has been properly reported to
the SCP by checking the ERB message after MS3(b) has
disconnected the call. For this it is necessary to use a Protocol
Analyser. This part of the test case is optional.

GSM Association
Part 1
SCP Service Logic
Signals to/from the left bcsmEvents

bcsmEvent
o1_4 eventTypeBCSM = oDisconnect (9)
legID
sendingSide
Leg Type = leg2
RRBE
CUE
Wait for
ERB eventTypeBCSM = oDisconnect (9)
legID
sendingSide
Leg Type = leg2
miscCallInfo
ABT ERB messageType = notification (1)
Idle

GSM Association
Part 1
2.1.6 Check Default Call Handling
Message-flow:
SSP(b) SCP(a)
IDP(ServiceKey, AACx )
no answer to IDP
2.1.6.1 defaultCallHandling set to continueCall

Overview:
MS1(a), roaming in VPLMN(b), makes a call to Test Announcement 1. SCP
does not answer to InitialDP. The Default Call Handling of MS1(a) equals
continueCall. The call is connected to Test Announcement 1. The correct
utilisation of the Default Call Handling is verified.
Preconditions: MS1(a) has location updated successfully in VPLMN(b).

HLR record of MS1(a) contains O-CSI with parameter
defaultCallHandling set to continueCall. [Set by HLR Admin]
Action: MS1(a) attempts a call to AAC1.
Service logic: IDP.calledPartyBCDNumber equals AAC1:
SCF does not answer to IDP. Alternatively SCF may send an
Abort message.
party.
Comments: This testcase checks the correct utilisation of the O-CSI
parameter defaultCallHandling=continueCall.
Some SCF implementations do not allow to send no answer to
IDP. In this case SCP should send an Abort message, which
triggers the default call handling in the SSF.

GSM Association
Part 1
2.1.6.2 defaultCallHandling set to releaseCall

Overview:
releaseCall. The call is released. The correct utilisation of the Default Call
Handling is verified.

defaultCallHandling set to releaseCall. [Set by HLR Admin]
SCF does not answer to IDP. Alternatively SCF may send an
Abort message.
Result: Successful result if call is NOT established and Test
Announcement 2 is NOT played to calling party.
Comments: This test case checks the correct utilisation of the O-CSI
parameter defaultCallHandling=releaseCall.
IDP. In this case SCP should send an Abort message, which
triggers the default call handling in the SSF.
SCP Service Logic
o1_5 o1_6
Idle Idle
Note: In case SCP implementation does not allow to send no answer to IDP an Abort
message should be sent.

GSM Association
Part 1
2.1.7 Check Suppression Of Announcement

Overview:
MS3(b) makes a call to MS2(a), both registered in PLMN(b). SCP instructs
VPLMN(b) to suppress announcements. The correct utilisation of the
parameter SuppressionOfAnnouncement is verified.
Message-flow:
GMSC/ MSC/
MSC(b) SCP(a) HLR(a) BSC(b)
SSP(a) VLR(b)
IAM(MS2(a) ) SRI
SRI(T-CSI )
IDP(ServiceKey, MS 2(a), TDP12 )
CON(MS2(a), SoA )
SRI(suppressT-CSI, SoA ) PRN(SoA )
SRI(MSRN ) PRN(MSRN )
IAM(MSRN ) Paging
no answer to Paging
no announcement
REL REL
Preconditions: MS2(a) and MS3(b) have location updated successfully in

VPLMN(b). HLR entry for MS2(a) contains "T-CSI". [Set by HLR
Admin]
No GSM Call Forwarding is active for MS2(a).
Action: MS2(a) takes battery off in order to provoke unsuccessful call
establishment detected in VMSC.
MS3(b) attempts a call to MS2(a).
Service logic: IDP.calledPartyNumber consists of CC+NDC of country(a) and a
MSIN which is not included in the destination list.
SCF sends CON with all parameters unchanged, including SoA
Information Element.
Result: Successful result if no announcement or the announcement of
HPLMN is played to calling party.
Unsuccessful result if an announcement of VPLMN(b) is played

to calling party.
Comments: This test case confirms operation of the suppression of
announcement in case of unsuccessful call establishment
detected at the VMSC.
Note 1: In some PLMNs the connection is released because of a
timeout on the ISUP interface. This event is not visible to the
tester and the test case seems to be passed. The result of this
test case is only reliable, if test case 2.1.8.1 or the test case "Call
Forwarding on Not Reachable before IMSI detached", specified in

GSM Association
Part 1
IREG PRD IR24, is successful.
Note 2: The outcome of the test case is only reliable in case

PLMN(b) plays an announcement on no paging response while
SoA is not invoked.
SCP Service Logic

t1_1
destinationRoutingAddress = IDP.calledPartyNumber *)
suppressionOfAnnouncement
CON
Idle
*) Note: The number format (natureOfAddressIndicator, ...) of the destinationRoutingAddress

has to be the same as the number format of IDP.calledPartyNumber. In case the number
format is changed, the GMSC/SSP(a) may decide that the destination has changed and that
a HLR interrogation for the new destination (SRI without the parameter suppress T-CSI) is
started. This may lead into a loop.

GSM Association
Part 1
2.1.8 Interaction with GSM Supplementary Services and ODB

To keep the expenditure low, interaction with the GSM supplementary services Call
Forwarding, Call Barring and Operator Determined Barring is tested exemplary.
2.1.8.1 Call Forwarding on no reply (CFNRy)

Overview:
MS3(b) attempts a call to MS1(a). MS1(a) has activated Call Forwarding on No
Reply to Test Announcement 3. MS1(a) does not answer the call. GSM call
forwarding takes place and because of that the originating camel service is
triggered. The triggering of originating camel services in case of late call
forwarding is verified. Additionally the contents of InitialDP are checked in the
mobile forwarded case.
Message-flow:
VLR /
MSC(b) GMSC(a) SCP(a) HLR(a) BSC(b)
SSP(b)
IAM(MS1(a) ) SRI PRN
IAM(MSRN ) Paging
... Alert
NoAnswer Timer expires
IDP(ServiceKey, AAC3 ) REL
(i)
CON(AAC1 )
(ii)
CON(AAC2 )
Preconditions: MS1(a) and MS3(b) have location updated successfully in VPLMN(b).

HLR entry for MS1(a) contains "O-CSI". [Set by HLR Admin]
MS1(a) has activated CFNRy to destination number of Test
Announcement 3.
Action: MS3(b) attempts a call to MS1(a). MS1(a) does NOT answer the call and
MS3(b) waits until NoAnswer timer expires.
Service logic: IDP.calledPartyNumber equals AAC3:
(i) If SCF has received all required parameter within the IDP, the SCF
alters destination address to that of Test Announcement 1.
SCF sends CON.
(ii) If SCF has not received all required parameter within the IDP, the
SCF alters destination address to that of Test Announcement 2.
SCF sends CON.
party.

GSM Association
Part 1
parameter of the IDP is missing and the test is failed.
Comments: This test case confirms that in case of CFNRy an originating
CAMEL service is invoked for a subscriber with O-CSI
subscription and all required parameters are included in IDP.
Note: In some PLMNs the connection is released because of a timeout
on the ISUP interface. In this case none of the Test Announcements is
played to the calling subscriber and the test is failed.
SCP Service Logic

Signals to/from the left o1_7 included in IDP:
serviceKey
CalledPartyNumber
eventTypeBCSM
redirectingPartyID
Yes redirectionInformation
IMSI
callReferenceNumber
MSCAddress
No

CON CON
Idle

GSM Association
Part 1
2.1.8.2 Barring of outgoing international calls except to HPLMN country

(BOICexHC)
Overview:
MS1(a) attempts a call to TestNbr3. MS1(a) has activated Barring of outgoing
international calls except those directed to the HPLMN country. SCF alters the
destination address to a number located in country(c). It is checked that
BOICexHC is executed correctly after mobile originated CAMEL service
invocation.
Message-flow:
SSP(b) SCP(a)
CON(DN(c) )

HLR entry for MS1(a) contains
"O-CSI". [Set by HLR Admin]
"SS : BOICexHC : Active". [Set by MS]
The SCF alters the destination address to be that of destination number
located in country(c).
SCF sends CON.
Result: Successful result if call attempt fails and no announcement or a
VPLMN(b) barring announcement is connected to calling party.
Unsuccessful result if a call attempt to DN(c) occurs.

Comments: This test case confirms that any originating CAMEL based service does
not violate the invocation of BOICexHC supplementary service in case
of mobile originated calls.
Note: For the destination number located in country(c) HPLMN(a) may

use an Automatic Answering Circuit or a Test SIM number of a country
where actually no CAMEL roaming tests are executed. It is in the
responsibility of HPLMN(a) to choose a proper number. A call attempt to
DN(c) occurs only if test case fails.

GSM Association
Part 1
SCP Service Logic

o1_8
DRA = DN(c)
CON
Idle

GSM Association
Part 1
2.1.8.3 ODB: Barring of outgoing international calls except to HPLMN country

(ODB-BOICexHC)
Overview:
MS2(a) attempts a call to TestNbr3. Operator Determined Barring - Barring of
outgoing international calls except those directed to the HPLMN country
applies to MS2(a). SCF alters the destination address to a number located in
country(c). It is checked that ODB-BOICexHC is executed correctly after
mobile originated CAMEL service invocation.
Message-flow:
SSP(b) SCP(a)
CON(DN(c) )

"ODB-BOICexHC : Active". [Set by HLR Admin]
located in country(c).
SCF sends CON.

not violate the invocation of ODB-BOICexHC in case of mobile
originated calls.
SCP Service Logic
The service behaviour is already described in test case 2.1.8.2

GSM Association
Part 1
2.2 Camel Phase 2

Originating Service Logic: CAMEL Phase 2
Idle
IDP
Analyse
CalledPartyBCDNumber/
CalledPartyNumber *
o2_1
o2_2
calledPartyBCDNumber consists of CC + NDC of country(a)

and a MSIN which is not included in the destination list
o2_3
CC + NDC of calledPartyBCDNumber differs from CC +

NDC of country (a)
o2_4
o2_5
o2_6
o2_7
* Note: Use Best Fit algorithm to branch into the proper path.
Figure 5: Entry process for originating service logic: CAMEL Phase 2 (part 1 of 2)

GSM Association
Part 1

1
o2_8
o2_9
o2_10
calledPartyNumber = AAC3 or TestNbr8
o2_11
o2_12
o2_13
o2_14
o2_15
Figure 6: Entry process for originating service logic: CAMEL Phase 2 (part 2 of 2)

GSM Association
Part 1
Terminating Service Logic: CAMEL Phase 2
Idle
IDP
Analyse
CalledPartyNu
mber
calledPartyNumber consists of CC + NDC of country(a) and
a MSIN which is not included in the destination list
t2_1
Figure 7: Entry process for terminating service logic: CAMEL Phase 2

GSM Association
Part 1
2.2.1 Location Update
Message-flow:
VLR(b) HLR(a)
updateLocation
ISD(O-CSI)
updateLocation Res
Overview:
example: O-CSI – in the VLR is verified.

HLR record contains basic and supplementary service information as
well as O-CSI.
Service logic: -
Result: Successful result if at least the following entries are included in VLR
record:
SS : BOICexHC : Provisioned
SS : AoCI : Provisioned
O-CSI
TriggerDetectionPoint CollectedInfo, DP2
CamelCapabilityHandling CAMEL phase 2
HPLMN(a)
GsmSCFAddress: equal to information provided
by
HPLMN(a)
defaultCallHandling: releaseCall
O-BcsmCamelTDP-CriteriaList
MatchType enabling
DestinationNumberLengthList 4
SS-CSI
ssEventList = MultiPTY
gsmSCF-Address
Comments: This test case confirms operation of Insert Subscriber Data procedure
including O-CSI and that the required subscriber profile for MS1(a) is
available. If the required subscriber profile is not included in the VLR,
the error has to be sorted out before continuation of tests.
SCP Service Logic

GSM Association
Part 1
Overview:
MS5(a) registers in VPLMN(b). It is verified, that the required subscriber
profile for MS5(a) – example.: O-CSI – is available.

well as O-CSI.
Service logic: -
Result: Successful result if the following entries are included in VLR record:
ODB-BOICexHC : Active
SS : CFNRy : Provisioned
O-CSI
HPLMN(a)
HPLMN(a)
defaultCallHandling: continueCall
Comments: This test case confirms that the required subscriber profile for MS5(a) is
available. If the required subscriber profile is not included in the VLR,
the error has to be sorted out before continuation of tests.
SCP Service Logic


GSM Association
Part 1
2.2.2 Check Operation of IDP and DP2 Criteria

2.2.2.1 Called Number of Length Within Destination Number Length List
Overview:
MS4(a), registered in VPLMN(b), makes a call to TestNbr4. This TestNbr4 is
of a length which is a predefined criteria for the collected_info trigger detection
point for MS4(a). Depending on the Initial DP contents, either Test
Announcement (AAC1) or Test Announcement 2 (AAC2) is played. The
correct usage of DP criteria is verified.
Or, if the HPLMN does not support DP criteria, an IDP will still be initiated and
the contents verified.
Message-flow:
SSP(b) SCP(a)
(i)
CON(AAC1 )
(ii)
CON(AAC2 )
Preconditions: MS4(a) has location updated successfully in VPLMN(b). HLR entry

for MS4(a) contains "O-CSI, DestinationNumberLengthList = 4,
enabling". [Set by HLR Admin]
Action: MS4(a) attempts a call to TestNbr4
Service logic: IDP calledPartyBCDNumber consists of TestNbr4:
(i) If SCF received all required parameters within the IDP, the SCF
alters the destination address to be that of Test Announcement 1.
SCF sends Connect.
(ii) If SCF does not receive all parameters within the IDP, the SCF
alters the destination address to be that of Test Announcement 2.
SCF sends Connect.
party.
parameter of the IDP is missing. However, the DP criteria has been
successfully implemented.
Comments: This test case confirms operation of the TDP criteria and ensures
that all parameters are present on the IDP.
If no announcement is played, either the criteria for triggering has
not been implemented correctly or a fundamental error has occurred.
If Test 2.1.2 has been successfully carried out previously, it is likely
that the triggering criteria has failed.

GSM Association
Part 1
SCP Service Logic

included in IDP:
Signals to/from the left serviceKey
are to/from the SSP. o2_1 callingPartyNumber
callingPartysCategory
locationNumber
bearerCapability
eventTypeBCSM
Yes IMSI
locationInfomation.cellIdOrLAI
locationInformation.ageOfLocationInfo
locationInformation.VLRNumber
callReferenceNumber
No MSCNumber
CalledPartyBCDNumber
TimeAndTimezone

CON CON
Idle
Note: Additional parameter may be included in IDP.

GSM Association
Part 1
2.2.2.2 Called Number Length not Defined by Destination Number Length List
Overview:
MS4(a), registered in VPLMN(b) makes a call to AAC4. AAC4 is not within the
predefined criteria for the collected_info trigger detection point for MS4(a). No
trigger to the SCF should take place.
If a SCF trigger occurs, Test Announcement 2 (AAC2) is played.
If the HPLMN does not support DP criteria, this test is not valid.
Message-flow:
SSP(b) SCP(a)
(i)
no CAMEL dialog
(ii)
IDP(ServiceKey, AAC4 )
CON(AAC2 )
Preconditions: MS4(a) has location updated successfully in VPLMN(b). HLR entry for
MS4(a) contains "O-CSI, DestinationNumberLengthList = 4, enabling".
[Set by HLR Admin].
Action: MS4(a) attempts a call to AAC4
Service logic: (i) There will be no service logic applicable if the triggering criteria has
been correctly implemented.
(ii) However, if the call did trigger a SCF enquiry:

The IDP calledPartyBCDNumber consists of AAC4. The SCF alters
the destination address to be that of Test Announcement 2.
SCF sends Connect.
Result: (i) Successful result if the call is routed to the destination of AAC4 .
(ii) If Test Announcement 2 is played to the calling party, an IDP has

been triggered to the SCP, and the test has failed.
Comments: This test confirms the operation of the Detection Point criteria when
the length of the dialled number is not that in the destination number
length list.

GSM Association
Part 1
SCP Service Logic
There is no service logic for the successful case of this test.
The service logic for the failure case:

o2_2
DRA = AAC2
CON
Idle

GSM Association
Part 1
2.2.3 Check operation of PSI

Overview:
MS5(a) makes a call to MS4(a), both registered in VPLMN(b). Depending on
the subscriber state retrieved, either Test Announcement 1 (AAC1) is played
or the call is connected. The operation of ProvideSubscriberInfo and the
correct reporting of the subscriber state is verified.
Message-flow:
SSP(b) SCP(a) HLR(a) VLR(b)
IDP(ServiceKey, MS 4(a) )
ATI(locationInfo, subscriber State, gsmSCF-Address )
PSI(locationInfo, subscriber State )
PSI Res (locationInfo, subscriber State )
ATI Res (locationInfo, subscriber State )
(i)
CON(AAC1 )
(ii)
CUE
Preconditions: MS4(a) and MS5(a) have location updated successfully in VPLMN(b).

MS4(a) is busy.
Action: MS5(a) attempts a call to MS4(a).
Service logic: IDP.calledPartyBCDNumber consists of CC+NDC of country (a) and a
MSIN which is not included in the destination list:
SCF starts Any Time Interrogation and requests Location Information
and Subscriber State of MS4(a).
(i) If subscriber state in Any Time Interrogation Result equals
camelBusy, SCF alters destination address to be that of Test
Announcement 1 and sends CON.
(ii) If subscriber state is any other, SCF sends CUE.

Result: Successful result if Test Announcement 1 is played to calling party.
If the busy tone is played to calling party, the subscriber state was
incorrect.
Comments: This test case confirms operation of Provide Subscriber Information to
retrieve a correct subscriber state.

GSM Association
Part 1
SCP Service Logic

are to/from the HLR.
o2_3
msisdn = IDP.CalledPartyBCDNbr
locationInformation
subscriberState
gsmSCF-Address ATI
ATI
Res
The following parameters are

included in ATI Res:
locationInformation.vlrNumber
Yes subscriberState = camelBusy
No
DRA = AAC1
CON CUE
Idle

GSM Association
Part 1
2.2.4 Check reporting of EDP O_Answer, O_Disconnect and operation of RC

Overview:
MS5(a), registered in VPLMN(b), makes a call to TestNbr11. 10 seconds after
Test Announcement 3 is connected to calling party, the call is released from
SCP. The operation of RequestReportBCSMEven, EventReportBCSM and
ReleaseCall is checked.
Message-flow:
SSP(b) SCP(a)
RRBE([O_Answer, notify ], [O_Disc, interrupted, legID=1 ], [O_Disc, interrupted , legID=2 ])+CON(AAC3 )
ERB(O_Answer )
t=10 sec.
RC(NormalCallClearing )
MS5(a) contains "O-CSI". [Set by HLR Admin]
Action: MS5(a) attempts a call to TestNbr11 and waits until the call is
disconnected.
Announcement 3.
SCF sends RRBE([O_Answer, notify], [O_Disc, interrupted, legID=1],
[O_Disc, interrupted, legID=2])+CON. After reception of
ERB(O_Answer) SCF starts a timer of length 10 seconds. SCF sends
RC after expiration of this timer.
Result: Successful result if Test Announcement 3 is played to calling party and
the call is released after 10 ±1 seconds from SCP.
If the connection to Test Announcement 3 is not disconnected after 10 ±
1 seconds, the test has failed.
Comments: This test case checks correctly reporting of EDP-N7, O_Answer, and
the ability to arm EDP-N9, O_Disconnect. Additionally the operation of
RC is checked.

GSM Association
Part 1
SCP Service Logic

are to/from the SSP. bcsmEvents
are to/from SCP-internal bcsmEvent
sub-processes. eventTypeBCSM = oAnswer (7)
o2_13
bcsmEvent
RRBE legID
sendingSide
Leg Type = leg1
bcsmEvent
CON legID
sendingSide
Leg Type = leg2
destinationRoutingAddress = AAC3
ABT ERB
eventTypeBCSM = oAnswer (7)
miscCallInfo
messageType = notification (1)
Start
Timer
Wait for
Timer
Expiration
Timer
ABT
expired
RC
Idle

GSM Association
Part 1
2.2.5 Check operation of CUE and FCI with Follow-On Call

Note: This testcase relies on certain release causes (busy, notReachable) to be correctly
reported back to the gsmSSF in order to be detected as trigger events. Part 2.2.5.2, 2.2.5.3
and 0 of this test are optional, because they may represent only special cases as far as the
capability of the signalling system between or within the networks are concerned. Therefore,
the result of the test has to be carefully interpreted.
Generally the MSC functions shown in the picture below can be distinguished. However,
during the test it is likely that the MSC where the tester is located will comprise all the
functions. As a result, the release causes are only processed internally.
MSC
MOC Serving MSC(A) GMSC(B) Serving MSC(B) MTC
MS3(B)
MAP SRI
gsmSSF Release Release
(cause) (cause)
IDP
Release
Connect
(cause)
CSE
HLR(B)
2.2.5.1 Follow-On Call due to "Called Party does not Reply"

Overview:
MS5(a) makes a call to a MS3(b), which is located in the VPLMN(b) and does
not answer the call. After the no-answer timer expires, the Re-connection to
Test Announcement 1 (AAC1) is triggered.
Message-flow:
SSP(b) SCP(a)
IDP(ServiceKey,MS3(b) )
RRBE ( [O_NoAnswer,Interrupted,leg2,applicationTimer =15sec], [O_Busy,Interrupted,leg2 ],

[RouteSelectFailure,Interrupted,leg2 ] ) + CUE
t=15sec
ERB(O_NoAnswer)
FCI (40byte FreeFormat ) +
CON(AAC1)

No GSM CF is active for MS3(b).
Action: MS5(a) attempts a call to MS3(b). MS3(b) does not answer the call.
Service logic: CC + NDC of IDP.calledPartyBCDNumber differs from CC + NDC of
country (a): SCF sends RRBE ([O_NoAnswer, Interrupted, leg2, 15sec],

GSM Association
Part 1
[O_Busy, Interrupted, leg2], [Route_Select_Failure, Interrupted,
leg2])+CUE.
After reception of ERB(O_NoAnswer) SCF sends transparent charging

information through FCI and reconnects to AAC1: FCI (40byte
FreeFormat(octet-string), legID=1)+ CON(AAC1)
Comments: This test case checks arming and correct reporting of EDP-R6,
O_NoAnswer, and the ability to reconnect a call while sending
transparent charging information.
The charging information may optionally contain a cause value
indicating the reconnect was due to no answer.

GSM Association
Part 1
2.2.5.2 Follow-On Call due to "Called Party is busy" (optional)

Overview: The same as test case 2.2.5.1 with MS3(b) busy.
MS5(a) makes a call to a MS3(b), which is located in the VPLMN(b) and rendered "busy".
Because ISUP is used within the VPLMN or the called MS is registered in the same MSC as
the calling MS, the busy cause is received in the SSF and the Re-connection to Test
Announcement 1 (AAC1) is triggered on EDP O_Busy.
Message-flow:
SSP(b) SCP(a)

ERB(O_Busy, busyCause =busy)

CON(AAC1)

HLR entry for MS5(a) contains "O-CSI". [Set by HLR Admin]. MS3(b) is
engaged in a call and therefore busy.
Action: MS5(a) attempts a call to MS3(b).
country (a): SCF sends RRBE ( [O_NoAnswer, Interrupted, leg2,
15sec], [O_Busy, Interrupted, leg2], [Route_Select_Failure, Interrupted,
leg2])+CUE.
After reception of ERB(O_Busy) SCF sends transparent charging

information through FCI and reconnects to AAC1: FCI (40byte
FreeFormat(octet-string), leg1)+ CON(AAC1)
Comments: This test case checks arming and correct reporting of EDP-R5, O_Busy
with indication of busy.
indicating the reconnect was due to busy.

GSM Association
Part 1
2.2.5.3 Follow-On Call due to "Called Party is NotReachable" (optional)

Overview: The same as test case 2.2.5.1 with MS3(b) not reachable.
MS5(a) makes a call to a MS3(b), which is located in VPLMN(b) and switched off (explicitly
detached). Because ISUP is used within the VPLMN or the called MS is registered in the
same MSC as the calling MS, the not reachable cause is received in the SSF and the Re-
connection to Test Announcement 1 (AAC1) is triggered on EDP Busy.
Message-flow:
SSP(b) SCP(a)

ERB(O_Busy, busyCause =notReachable)

CON(AAC1)

HLR entry for MS5(a) contains "O-CSI". [Set by HLR Admin]. MS3(b) is
switched off and therefore not reachable (detached).
Action: MS5(a) attempts a call to MS3(b).
leg2])+CUE.
After reception of ERB(O_Busy,BusyCause=not reachable)) SCF sends

transparent charging information through FCI and reconnects to AAC1.
FCI (40byte FreeFormat(octet-string), leg1)+ CON(AAC1)
Comments: This test case checks arming and correct reporting of EDP-R5, O_Busy
with indication of not reachable.
indicating the reconnect was due to not reachable.

GSM Association
Part 1
2.2.5.4 Follow-On Call due to "RouteSelectFailure" by "Release before Answer"

(optional)
Overview:
This testcase verifies reporting of the EventDetection Point
"Route_Select_Failure" to the SCP.
It is not clearly specified whether a network initiated release before answer,
e.g. after a network announcement, with cause "normal unspecified" will
trigger this DP. In terms of service functionality, this could be the preferred
option. The testcase relies on a VPLMN mapping of release "normal
unspecified" before answer to the Route_Select_Failure DP. It is optional as
long as this point is open.
MS5(a) makes a call to a number in the numbering range of VPLMN B, which
has the following properties: The call to the number is released by the network
before Answer/Connect is sent to the MS5(a). This may be the case for calls
to a number not allocated with an announcement played by the network for a
limited time period.
Because ISUP is used within the VPLMN or the called MS is registered in the
same MSC as the calling MS, the release cause is received in the SSF and
the Re-connection to Test Announcement 1 (AAC1) is triggered on EDP Busy.
Message-flow:
SSP(b) SCP(a)
IDP(ServiceKey,VPLMN B )

ERB(O_RouteSelectFailure )
CON(AAC1)
MS5(a) contains "O-CSI". [Set by HLR Admin].
Action: MS5(a) attempts a call to a number in the number range of VPLMN B.
Note: The properties of the number to be dialled are described in the
Overview of this test case.
leg2])+CUE.
After reception of ERB(Route_Select_Failure) SCF sends transparent

charging information through FCI and reconnects to AAC1. FCI (40byte
FreeFormat(octet-string), leg1)+ CON(AAC1)
Comments: This test case checks arming and correct reporting of EDP-R4,
Route_Select_Failure.

GSM Association
Part 1
indicating the reconnect was due to RouteSelectFailure.
SCP Service Logic
bcsmEvents
bcsmEvent.eventTypeBCSM = oNoAnswer
are to/from the SSP. bcsmEvent.monitorMode = interrupted
are to/from SCP-internal
bcsmEvent.legID.sendingSide.legType = leg2
sub-processes. bcsmEvent.dpSpecificCriteria.applicationTimer = 15 [sec]
o2_4
bcsmEvent.eventTypeBCSM = oCalledPartyBusy
bcsmEvent.monitorMode = interrupted
RRBE + CUE
bcsmEvent.eventTypeBCSM = routeSelectFailure
bcsmEvent.monitorMode = interrupted
Wait for ERB
ERB
ERB ERB
ERB (oCalledPartyBusy,
(oCalledPartyBusy, (routeSelectFailu
(oNoAnswer) busyCause=notRea
busyCause=busy) re)
chable)
FCI(40 byte FCI(40 byte free FCI(40 byte free

FCI(40 byte free
free format format indicating: format indicating:
format indicating:
indicating: cause = routeSelectFailur
cause = busy)
oNoAnswer) notReachable) e)
DRA = AAC1
CON
Idle

GSM Association
Part 1
2.2.6 Check operation of CIReq, SCI and AC

2.2.6.1 Check correct reporting of call periods (1)
Overview:
MS4(a), registered in VPLMN(b), makes a call to TestNbr5 and is connected to
Test Announcement 5 (AAC5). AAC5 disconnects the call after 30 seconds.
Depending on correct reporting of call periods, either Test Announcement 1
(AAC1) or Test Announcement 2 (AAC2) is played. The operation of CAP-
CallInformationRequest/-Report, CAP-SendChargingInfo, CAP-ApplyCharging
and CAP-ApplyChargingReport is verified.
Message-flow:
SSP(b) SCP(a)
IDP(ServiceKey,TestNbr5 )
CIReq (callAttemptElapsedTime,callStopTime,callConnectedElapsedTime,releaseCause ) +
AC (maxCallPeriodDuration=5sec, TariffSwitchInterval=1sec, PartyToCharge=leg1 ) +
SCI (aOCInitial.CAIElements, aOCSubsequent.CAIElements, PartyToCharge=leg1 ) +
RRBE ([O_Disconnect,Notify,leg1], [O_Disconnect,Interrupted,leg2] ) +
CON(AAC5 )
t>CPD1
ACR (PartyToCharge,TimeIfNoTariffSwitch )
AC (maxCallPeriodDuration=5sec, PartyToCharge=leg1 )
t=CPD2
ACR (PartyToCharge,TimeIfNoTariffSwitch )
AC (maxCallPeriodDuration=5sec,tariffSwitchInterval=2sec, PartyToCharge=leg1 ) +
t=30sec SCI (aOCAfterAnswer.cAIElements, PartyToCharge=leg1 )
t=CPD3
ACR (PartyToCharge,TimeSinceLastTariffSwitch,tariffSwitchInterval )
AC (maxCallPeriodDuration=3600sec, PartyToCharge=leg1 )
t<CPD4
ACR (PartyToCharge,TimeSinceLastTariffSwitch,callActive=false) +
CIRep (callAttemptElapsedTime,callStopTime,callConnectedElapsedTime,releaseCause ) +
ERB (O_Disconnect,Interrupted,leg2 )
(i)
CON (AAC1 )
(ii)
CON (AAC2 )
ERB (O_Disconnect,Notify,leg1 ) *)
*) ERB is sent in case A-party disconnects the call to AAC2.

If AAC2 terminates the call ERB is not sent from SSP

GSM Association
Part 1
Announcement 5 and sends CIReq+SCI+AC(CPD=5sec,
TSI=1sec)+RRBE+CON. After the first ACR is received AC(CPD=5sec),
after the second ACR SCI+AC(CPD=5sec, TSI=2sec) and after the third
ACR AC(CPD=3600sec) is sent.
(i) When SCF has received ERB and if the correct call periods within the
ACRs and the correct callConnectedElapsedTime=TSIACR+TSLTS2
within CIRep was received, the SCF alters the destination address to be
that of Test Announcement 1 and establishes a reconnection.
(ii) If SCF does not receive the correct values within the ACRs and
CIRep, the SCF alters the destination address to be that of Test
Announcement 2 and establishes a reconnection.
Result: (i) Successful result if Test Announcement 1 is played to calling party
after about 30 seconds.
(ii) If after about 30 seconds Test Announcement 2 is played to calling
party, at least one parameter-value of ACR or CIRep was wrong and the
test has failed.
Comments: This test case confirms the correct reporting of four call periods. One
tariff switch occurs before answering the call and a second one in the
third call period. If AoCI is supported in VPLMN(b) and MS4(a) the
operation of SCI is checked; 12 ± 3 units should be displayed.
Additionally the operation of CIReq/CIRep is tested.
The following figure shows a schematic presentation of the AC- and
ACR-parameters used in this call scenario:
Tariff_1 Tariff_2 (ca. 12 chargeable seconds) Tariff_1 (ca. 18 seconds)
AC(CPD1,TSI1) ACR(TINTS1) ACR(TINTS2) ACR(TSLTS3,TSI3) ACR(TSLTS4)

ANM AC(CPD2) AC(CPD3,TSI3) AC(CPD4) REL
TS TS time
AC-parameter:
TSI1 CPD1
CPD2
CPD3
TSI3
t<CPD4
ACR-parameter:
TINTS1
TINTS2
TSI3
TSLTS3
TSLTS4

GSM Association
Part 1
SCP Service Logic

CIReq.callAttemptElapsedTime
Signals to/from the left o2_5
are to/from the SSP. CIReq.callStopTime
CIReq.callConnectedElapsedTime
CIReq.releaseCause
CIReq + AC + SCI + AC.CPD = 50 [100 msec]

RRBE + CON AC.TSI = 1 [sec]
AC.partyToCharge.sendingSideID = leg1
SCI.aOCInitial.CAIElements = Tariff_1 *)
Wait for ACR SCI.aOCSubsequent.CAIElements = Tariff_2 *)
SCI.partyToCharge.sendingSideID = leg1
RRBE.bcsmEvents.bcsmEvent.eventTypeBCSM = oDisconnect
RRBE.bcsmEvents.bcsmEvent.monitorMode = notify
ACR RRBE.bcsmEvents.bcsmEvent.legID.sendingSide.LegType=leg1
RRBE.bcsmEvents.bcsmEvent.monitorMode = interrupted
RRBE.bcsmEvents.bcsmEvent.legID.sendingSide.LegType=leg2
1 NO
CON.DRA = AAC5
YES
ACR.PartyToCharge = leg1
ACR.TINTS = 50 ± 10 [100 msec]
AC
AC.timeDurationCharging.CPD = 50 [100 msec]

Wait for ACR
ACR
ACR.PartyToCharge = leg1
ACR.TINTS = 100 ± 10 [100 msec]
1 NO
YES AC.timeDurationCharging.TSI = 2 [sec]
AC + SCI SCI.aOCAfterAnswer.cAIElements = Tarif_1 *)

SCI.partyToCharge.sendingSideID = leg1
Wait for ACR

GSM Association
Part 1

are to/from the SSP. 2
ACR
ACR3.PartyToCharge = leg1
ACR3.TSLTS = 30 ± 30 [100 msec]
ACR3.TSI STORE VALUE
1 NO

YES
AC
ACR4.TSLTS + ACR3.TSI = 300 ± 30 [100 msec]
ACR4.CallActive = false
Wait for ACR
CIRep.CallAttemptElapsedTime received?
CIRep.CallStopTime received?
CIRep.CallConnectedElapsedTime = 300 ± 10 [100 msec]
ACR + CIRep CIRep.ReleaseCause received?
+ ERB
ERB.EventTypeBCSM = oDisconnect
ERB.legID.ReceivedSideID = leg2
NO
YES
CON.DRA = AAC2 CON.DRA = AAC1
CON CON
ERB(O_Disconnect,leg1) will be received in

case A-party disconnects the call to AAC2.
Idle

GSM Association
Part 1

1
AC
Wait for ACR

Evaluation of ACR,CIRep, and ERB is not necessary
due to incorrect call periods in previous ACR.
ACR + CIRep
+ ERB
CON.DRA = AAC2
CON
ERB(O_Disconnect,leg1) will be received in

case A-party disconnects the call to AAC2.
Idle
*) In the following table the tariffs are specified:
e-parameter Description RES Tariff_1 Tariff_2

e1 Units per interval 0.1 0 1.0
e2 Seconds/time interval 0.1 0 1.0
e3 Scaling Factor 0.01 0 1.00
e4 Unit increment 0.1 0 0
e5 Units per data interval 0.1 0 0
e6 Segments/data interval 1 0 0
e7 Initial secs/t interval 0.1 0 0

GSM Association
Part 1
2.2.6.2 Check reporting of call periods (2)

Overview:
Test Announcement 5 (AAC5). A tariff switch occurs in the first and in the
second Max. Call Period Duration. The call is released before the second tariff
switch. Depending on correct reporting of the call periods either Test
Announcement 1 (AAC1) or Test Announcement 2 (AAC2) is played.
Message-flow:
SSP(b) SCP(a)
CIReq (callAttemptElapsedTime,callStopTime,callConnectedElapsedTime,releaseCause,leg1 ) +
AC (maxCallPeriodDuration =15sec,TariffSwitchInterval =10sec,PartyToCharge=leg1 ) +
RRBE (O_Disconnect,Interrupted,leg2 ) +
CON (AAC5 )
t>CPD1
ACR (PartyToCharge,TimeSinceLastTariffSwitch,TariffSwitchInterval )
t=30sec
AC (maxCallPeriodDuration =86400sec,TariffSwitchInterval=86390sec, PartyToCharge=leg1)
t<TSI2 ACR (PartyToCharge,TimeSinceLastTariffSwitch,callActive =false) +

ERB (O_Disconnect,Interrupted,leg2 )
(i)
CON (AAC1)
(ii)
CON (AAC2)
CIRep (callAttemptElapsedTime,callStopTime,callConnectedElapsedTime,releaseCause,leg1 )
Announcement 5 and sends CIReq+AC(CPD=15sec,
TSI=10sec)+RRBE+CON. After reception of ACR AC(CPD=86400sec,
TSI=86390sec) is sent.
(i) If SCF receives ERB and if the correct call periods within the ACRs
was received, the SCF alters the destination address to be that of Test
Announcement 1 and establishes a reconnection.

GSM Association
Part 1
(ii) If SCF does not receive the correct values within the ACRs the SCF
alters the destination address to be that of Test Announcement 2 and
establishes a reconnection.
Result: (i) Successful result if Test Announcement 1 is played to calling party
after about 30 seconds.
(ii) If after about 30 seconds Test Announcement 2 is played to calling

party, at least one parameter-value of ACRs was wrong and the test has
failed.
Comments: This test case confirms that the call periods are reported correctly in
case of a tariff switch in the first and in the second Max. Call Period
Duration and a call release before the second tariff switch.
It is also possible for the tester to check whether CIRep parameter have
been properly reported to the SCP (CallConnectedElapsedTime should
be equal to TSIACR + TSLTS2). For this it is necessary to use a protocol
analyser. This part of the test case is optional.
The following figure shows a schematic presentation of the AC- and
ACR-parameters used in this call scenario:
AC(CPD1,TSI1) ACR(TSLTS1,TSI1) ACR(TSLTS2)

ANM AC(CPD2,TSI2) REL
TS TS time
AC-parameter:
TSI1
CPD1
TSI2
t<CPD2
ACR-parameter:
TSI1 TSLTS1
TSLTS2

GSM Association
Part 1
SCP Service Logic

o2_6
CIReq.requestedInformationType.callAttemptElapsedTime
CIReq.requestedInformationType.callStopTime
CIReq.requestedInformationType.callConnectedElapsedTime
CIReq + AC + RRBE CIReq.requestedInformationType.releaseCause
+ CON CIReq.legID.sendingSideID = leg1

AC.timeDurationCharging.TSI = 10 [sec]
Wait for ACR AC.partyToCharge.sendingSideID = leg1
RRBE.bcsmEvents.bcsmEvent.monitorMode = interrupted
RRBE.bcsmEvents.bcsmEvent.legID.sendingSide.LegType=leg2
ACR
CON.DRA = AAC5

GSM Association
Part 1

2 NO
YES
ACR1.TSLTS + (ACR1.TSI *10) = 150 ± 10 [100 msec]
AC
AC.timeDurationCharging.TSI = 86390 [sec]
Wait for ACR
ACR + ERB ACR2.PartyToCharge = leg1

ACR2.TSLTS + (ACR1.TSI*10) = 300 ± 30 [100 msec]
ACR.CallActive = false
ERB.EventTypeBCSM = oDisconnect
NO ERB.legID.ReceivedSideID = leg2
YES
CON CON
Wait for CIRep
CIRep
Idle

GSM Association
Part 1

2
AC
Wait for ACR

Evaluation of ACR andERB is not necessary due to
incorrect call periods in previous ACR.
ACR + ERB
CON.DRA = AAC2
CON
Wait for CIRep
CIRep
Idle

GSM Association
Part 1
2.2.6.3 Check warning tone and automatic call release

Overview:
Test Announcement 3 (AAC3). It is checked, that the call is disconnected
because of used up credit and if a warning tone is played before the call is
released.
Message-flow:
SSP(b) SCP(a)
AC (maxCallPeriodDuration =40sec,releaseIfDurationExceeded.Tone, PartyToCharge= leg1 ) +

CON (AAC3 )
t>CPD
ACR (PartyToCharge,TimeIfNoTariffSwitch,callActive =false)
Check if a warning tone is played to calling party after about 10
seconds.
Announcement 3 and sends AC(CPD=40sec, RIDE.Tone) and CON.
Result: Successful result if the call is automatically released after 40±1
seconds.
Comments: This test case confirms that the call is released from VMSC in case
credit is used up and that a warning tone is played.
Due to CAMEL phase 2 a warning tone should be played 30 seconds
before maxCallPeriodDuration expires, if the parameter
“releaseIfDurationExceeded.Tone = true” is included in ApplyCharging
message.

GSM Association
Part 1
SCP Service Logic
02 7
Signals
t /f th l ft
AC.timeDurationCharging.releaseIfDurationExceeded.Ton
AC+ CON e
CON.DRA = AAC3
Wa
ACR.partyToCharge.sendingSideID
ACR ACR.timeIfNoTariffSwitch
ACR.callActive = False
Idle

GSM Association
Part 1
2.2.7 Check operation of ETC and DFC

Overview:
MS4(a), registered in VPLMN(b), makes a call to TestNbr10 and is connected
to an IN announcement located in Assisting SSF(a). In case of success Test
Announcement 1 (AAC1) is played to calling party.
Message-flow:
VMSC/ SCP(a) GMSC(a) Assisting

SSP(b) SSF(a)
ETC(assistingSSPIPRoutingAddress )
ISUP-IAM(CdPN = assistingSSPIPRoutingAddress)
ARI(correlationID,iPSSPCapabilities )
CTR(iPRoutingAddress) +
PA(messageID)
ISUP-ANM
SRR
DFC+CON(AAC1 )
ISUP-REL
ISUP-IAM(AAC1)
SCP sets up connection to assisting SSF using the operations ETC,
CTR and PA. After reception of ARI the SCP instructs the assisting SSF
to play a PLMN(a) specific IN-announcement via CTR+PA. An
announcement completed indication (SRR) triggers the service logic to
clear the connection to the assisting SSF and to connect to test
announcement 1: DFC+CON(AAC1).
Result: Successful result if calling party is first connected to an PLMN(a)
specific announcement and secondly to AAC1.
Comments: This test case confirms the operation of the assist procedure, in detail
the operation of ETC and DFC. A prerequisite for this IR test is that the
operations ARI, CTR, PA and SRR are tested within PLMN(a) and that
they work properly.
PLMN(a) is responsible to choose a proper IN-announcement and to set
up a proper assistingSSPIPRoutingAddress which will be converted into
the CdPA used in the IAM to set up the call from the SSP(b) to the
assisting SSF(a). HPLMN(a) may use a SRF instead of an assisting
SSF. In this case a CTR-message should not be sent.
It is expected that most networks will not be introducing ISUP2000 for

GSM Association
Part 1
several years. Therefore it is not possible to use separate ISUP
parameters for the individual ETC parameters. As a result it is
anticipated that the CdPA will be a concatenation of the SRFid, SCFid
and CorrelationId. It is therefore also expected that the ETC parameter
assistingSSPIPRoutingAddress will in effect contain within its digit string
(the routing to the HPLMN's SRFs), the SRFid, the SCFid and the
CorrelationId.
This CdPA must be assigned from part of the HPLMN's numbering

range to allow the call to the SRF to reach the HPLMN. Accordingly
international and transit operators will expect the number length to
conform with the number plan of the HPLMN country and specifically to
that part of the number plan assigned to the HPLMN. Excess digits can
be expected to be truncated even though the CdPA conforms to the 15-
digit limit expressed in E.164.
Therefore it is important that the HPLMN's SCP constructs the contents

of the parameters of the ETC recognising these issues and constraints.

GSM Association
Part 1
SCP Service Logic
Signals to/from the left are to/

from the initiatingSSP.
Signals to/from the right are
to/from the assistingSSP.
o2_8
assistingSSPIPRoutingAddress = adjustable
ETC
Wait for ARI
correlationID
iPSSPCapabilities
ETCfaild ARI
CTR.resourceAddress CHOICE {
ipRoutingAddress
none
} = adjustable
CTR + PA PA.informationToSend.inbandInfo.messageID.
elementaryMessageID = adjustable
Wait for SRR
any error
SRR
indication
DFC
CON DFC + CON
Idle

GSM Association
Part 1
2.2.8 Check Default Call Handling
Message-flow:
SSP(b) SCP(a)
IDP(ServiceKey, AACx )
no answer to IDP
2.2.8.1 defaultCallHandling set to continueCall

Overview:
continueCall. The call is connected to Test Announcement 1. The correct
utilisation of the Default Call Handling is verified.

defaultCallHandling set to continueCall. [Set by HLR Admin]
SCF does not answer to IDP. Alternatively SCF may send an Abort
message.
Comments: This testcase checks the correct utilisation of the O-CSI parameter
defaultCallHandling=continueCall.
Some SCF implementations do not allow to send no answer to IDP. In
this case SCP should send an Abort message, which triggers the
default call handling in the SSF.

GSM Association
Part 1
2.2.8.2 defaultCallHandling set to releaseCall

Overview:
MS6(a), roaming in VPLMN(b), makes a call to AAC2. SCP does not answer
to InitialDP. The Default Call Handling of MS6(a) equals releaseCall. The call
is released. The correct utilisation of the Default Call Handling is verified.

defaultCallHandling set to releaseCall. [Set by HLR Admin]
SCF does not answer to IDP. Alternatively SCF may send an Abort
message.
Result: Successful result if call is NOT established and Test Announcement 2 is
NOT played to calling party.
Comments: This test case checks the correct utilisation of the O-CSI parameter
defaultCallHandling=releaseCall.
Some SCF implementations do not allow to send no answer to IDP. In
this case SCP should send an Abort message, which triggers the
default call handling in the SSF.
SCP Service Logic
o2_9 o2_10
Idle Idle
Note: In case SCP implementation does not allow to send no answer to IDP an Abort

GSM Association
Part 1
2.2.9 Check Suppression Of Announcement

Overview:
MS3(b) makes a call to MS5(a), both registered in PLMN(b). SCP instructs
VPLMN(b) to suppress announcements. The correct utilisation of the
parameter SuppressionOfAnnouncement is verified.
Message-flow:
GMSC/ MSC/
MSC(b) SCP(a) HLR(a) BSC(b)
SSP(a) VLR(b)
IAM(MS5(a) ) SRI
SRI(T-CSI )
IDP(ServiceKey, MS 5(a), TDP12 )
CON(MS5(a), SoA )
SRI(suppressT-CSI, SoA ) PRN(SoA )
IAM(MSRN ) Paging
no answer to Paging
no announcement
REL REL

HLR entry for MS5(a) contains "T-CSI". [Set by HLR Admin]
No GSM Call Forwarding is active for MS5(a).
Action: MS5(a) takes battery off in order to provoke unsuccessful call
establishment detected in VMSC.
MS3(b) attempts a call to MS5(a).
Service logic: IDP.calledPartyNumber consists of CC+NDC of country(a) and a MSIN
which is not included in the destination list.
SCF sends CON with all parameters unchanged, including SoA
Information Element.
Result: Successful result if no announcement or the announcement of HPLMN
is played to calling party.
Unsuccessful result if an announcement of VPLMN(b) is played to

calling party.
Comments: This test case confirms operation of the suppression of announcement
in case of unsuccessful call establishment detected at the VMSC.
NOTES 1: In some PLMNs the connection is released because of a timeout on
the ISUP interface. This event is not visible to the tester and the test
case seems to be passed. The result of this test case is only reliable, if
test case 2.1.8.1 or the test case "Call Forwarding on Not Reachable
before IMSI detached", specified in IREG PRD IR24, is successful.
2: The outcome of the test case is only reliable in case PLMN(b) plays
an announcement on no paging response while SoA is not invoked.

GSM Association
Part 1
SCP Service Logic

t2_1
destinationRoutingAddress = IDP.calledPartyNumber *)
suppressionOfAnnouncement
CON
Idle
*Note: The number format (natureOfAddressIndicator, ...) of the destinationRoutingAddress

has to be the same as the number format of IDP.calledPartyNumber. In case the number
format is changed, the GMSC/SSP(a) may decide that the destination has changed and that
a HLR interrogation for the new destination (SRI without the parameter suppress T-CSI) is
started. This may lead into a loop.

GSM Association
Part 1
2.2.10 Interaction with GSM Supplementary Services and ODB

To keep the expenditure low, interaction with the GSM supplementary services Call
Forwarding, Call Barring and Operator Determined Barring is tested exemplary.
2.2.10.1 Check Operation of SS-CSI, MPTY

Overview:
MS4(a) registered in VPLMN(b), makes a call to TestNbr12. A CAMEL enquiry
is made. MS4(a) puts this call on hold and initiates an additional call to
TestNbr13. Another CAMEL enquiry is made. When MS4(a) initiates a Multi-
Party call, the MSC informs the SCP of this. Service logic at the SCP waits 10
seconds and then releases the calls.
In case a HPLMN does not SS-CSI, this test is not valid. The VPLMN testing
personal is assumed to know whether the VPLMN supports the feature and
the test execution is sensible.
Message-flow:
AAC3/
MS4(a) VMSC(b) SSF(b) SCF(a)
AAC5 (a)
Setup (TestNbr12 ) IAM(TestNbr12 ) IDP(ServiceKey, TestNbr12 )
RRBE(O_Disc,interrupted,leg2 )+CON(AAC3 )
IAM(AAC3 )
Connect ANM ANM
Two way conversation
call hold
Setup (TestNbr13 ) IAM(TestNbr13 ) IDP(ServiceKey, TestNbr13 )
CON(AAC5 )
IAM(AAC5 )
Connect ANM ANM
Two way conversation
invoke MTPY SS-Invocation-Notification
SS-Invocation-Notification Result
Multi Party Conversation
Disonnect REL RC

GSM Association
Part 1
MS4(a) contains “O-CSI” and “SS-CSI”. [Set by HLR Admin]
Action: MS4(a) makes a call to TestNbr12 and places the call on hold. MS4(a)
then initiates a call to TestNbr13 and invokes a Multi Party call.
Service logic: IDP calledPartyBCDNumber consists of TestNbr12:
Announcement 3.
The SCF monitors for the call being disconnected and then sends
Connect.
IDP calledPartyBCDNumber consists of TestNbr13:

Announcement 5 and then sends Connect.
MAP-SS-Invocation-Notification indicates MS4(a) has initiated MultiPTY:

SCF indicated that MultiPTY is allowed via sending
SSNotificationInvocationResult and afterwards waits 10 seconds and
then sends a Release Call.
Result: Successful result if the call is released 10 seconds after the MultiPTY
establishment.
Comments: This test case confirms the correct operation of the visited PLMN when
a notification of SS invocation has been registered.

GSM Association
Part 1
SCP Service Logic

Signals to/from the right bcsmEvents
are to/from SCP-internal
sub-processes. bcsmEvent
o2_14 eventTypeBCSM = oDisconnect (9)
legID
sendingSide
Leg Type = leg2
o2_15 RRBE

CON CON
Idle Wait for

SS_Invocation_
Notification
IMSI = MS4(a)
MSISDN = MS4(a)
SS_Invocation SS-Event = multiPTY
_Notification
SS_Invocation
_Notification_
Result
Start
Timer
Wait for
Timer
Expiration
Timer
expired
RC
Idle

GSM Association
Part 1
2.2.10.2 Call Forwarding on no reply (CFNRy)

Overview:
MS3(b) attempts a call to MS5(a). MS5(a) has activated Call Forwarding on No
Reply to Test Announcement 3. MS5(a) does not answer the call. GSM call
forwarding takes place and because of that the originating camel service is
triggered. The triggering of originating camel services in case of late call
forwarding is verified. Additionally the contents of InitialDP is checked in the
mobile forwarded case.
Message-flow:
VLR /
MSC(b) GMSC(a) SCP(a) HLR(a) BSC(b)
SSP(b)
IAM(MS5(a) ) SRI
SRI(T-CSI,O-CSI )
IDP(ServiceKey,MS 5(a),TDP12 )
CON(MS5(a),SoA )
SRI PRN
IAM(MSRN ) Paging
... Alert
NoAnswer Timer expires
IDP(ServiceKey, AAC3 ) REL
(i)
CON(AAC1 )
(ii)
CON(AAC2 )

GSM Association
Part 1

MS5(a) has activated CFNRy to TestNbr8.
Note: If GSM CF to short codes is not supported by HPLMN(a),
PLMN(b) has to be informed and the test case should use AAC3 instead
of TestNbr8.
Action: MS3(b) attempts a call to MS5(a). MS5(a) does NOT answer the call and
MS3(b) waits until NoAnswer timer expires.
Service logic: IDP.calledPartyNumber equals AAC3:
(i) If SCF has received all required parameter within the IDP, the SCF
alters destination address to that of Test Announcement 1.
SCF sends CON.
(ii) If SCF has not received all required parameter within the IDP, the
SCF alters destination address to that of Test Announcement 2.
SCF sends CON.
Result: (i) Successful result if Test Announcement 1 is played to calling party.

parameter of the IDP is missing and the test is failed.
Comments: This test case confirms that in case of CFNRy an originating CAMEL
service is invoked for a subscriber with O-CSI subscription and all
required parameters are included in IDP.
The encountering of TDP12 because of the T-CSI subscription of

MS5(a) is not in the focus of this testcase.
Note: In some PLMNs the connection is released because of a timeout

on the ISUP interface. In this case none of the Test Announcements is
played to the calling subscriber and the test is failed.

GSM Association
Part 1
SCP Service Logic
Signals to/from the left o2_11

are to/from the SSP. The following Parameter are
included in IDP:
serviceKey
CalledPartyNumber
eventTypeBCSM
Yes
redirectingPartyID
redirectionInformation
IMSI
callReferenceNumber
MSCAddress
No TimeAndTimeZone
GMSC Address

CON CON
Idle

GSM Association
Part 1
2.2.10.3 Barring of outgoing international calls except to HPLMN country

(BOICexHC)
Overview:
MS4(a) attempts a call to TestNbr9. MS4(a) has activated Barring of outgoing
international calls except those directed to the HPLMN country. SCF alters the
destination address to a number located in country(c). It is checked that
BOICexHC is executed correctly after mobile originated CAMEL service
invocation.
Message-flow:
SSP(b) SCP(a)
CON(DN(c) )

"SS : BOICexHC : Active". [Set by MS]
located in country(c), DN(c).
SCF sends CON.

of mobile originated calls.
Note: For the destination number located in country(c) HPLMN(a) may

use an Automatic Answering Circuit or a Test SIM number of a country
where actually no CAMEL roaming tests are executed. It is in the
responsibility of HPLMN(a) to choose a proper number. A call attempt to
DN(c) occurs only if test case fails.

GSM Association
Part 1
SCP Service Logic

o2_12
DRA = DN(c)
CON
Idle

GSM Association
Part 1
2.2.10.4 ODB: Barring of outgoing international calls except to HPLMN

country (ODB-BOICexHC)
Overview:
MS5(a) attempts a call to TestNbr9. Operator Determined Barring - Barring of
outgoing international calls except those directed to the HPLMN country
applies to MS5(a). SCF alters the destination address to a number located in
country(c). It is checked that ODB-BOICexHC is executed correctly after
mobile originated CAMEL service invocation.
Message-flow:
SSP(b) SCP(a)
CON(DN(c) )

"ODB-BOICexHC : Active". [Set by HLR Admin]
located in country(c), DN(c).
SCF sends CON.

not violate the invocation of ODB-BOICexHC in case of mobile
originated calls.
SCP Service Logic
The service behaviour is already described in test case 2.2.10.3

GSM Association
Part 1
2.3 CAMEL Phase 3

2.3.1 MO SMS Control
General
For some of the test cases in this chapter the successful transmission of a SM
is required. It is the responsibility of the HPLMN to configure its SMSC to allow
the submission and delivery of SMs from and to the SIMs used for these tests.
The specified tests are valid for a GSM-CS- and a GPRS-environment. To
verify that the mentioned CAMEL Phase 3 information flows work in both
cases it is necessary to execute the tests for the MSC/VLR switching and
SGSN switching, as different elements are involved.
In some of the test cases in this chapter Test Numbers are used for SMSC-
addresses. These Test Numbers are short codes which will be translated to
valid SMSC-addresses by the service logic.

GSM Association
Part 1
Entry Service Logic
Idle
are to/from the gsmSSP/
gprsSSP.
IDP_SMS
Analyse SMSCAddress
SMSCAddress = TestNbr14
sm3_1
SMSCAddress = TestNbr16
sm3_5
SMSCAddress = HPLMN_SMSC
Analyse
DestinationSubscriberNumber
CC + NDC of DestSubscriberNbr
differs from CC + NDC of country (a)
sm3_4
CC + NDC of
DestSubscriberNbr equals
CC + NDC of country (a)
Analyse
CallingPartyNumber
equals CallingPartyNumber
sm3_3
differs from CallingPartyNumber
sm3_2
Figure 8: Entry process for SMS service logic: CAMEL Phase 3

GSM Association
Part 1
2.3.1.1 Location Update / GPRS attach
Message-flow:
VLR(b)/
HLR(a)
SGSN(b)
updateLocation
ISD(SMS-CSI)
updateLocation Res
2.3.1.1.1 Location Update by MS7(a) in VPLMN(b)
Overview:
example: SMS-CSI – in the VLR/SGSN is verified.

No VLR/SGSN record exists for MS7(a).
well as SMS-CSI.
Check VLR/SGSN record for the IMSI/MSISDN of MS7(a).
Service logic: -
Result: Successful result if at least the following entries are included in
VLR/SGSN record:
SMS Teleservice TS22 provisioned
SS: BOICexHC : Active for TS20
SMS-CSI
TriggerDetectionPoint: SMS_CollectedInfo
HPLMN(a)
HPLMN(a)
default SMS Handling: continue
Comments: This test case confirms the operation of Insert Subscriber Data
procedure including SMS-CSI and that the required subscriber profile
for MS7(a) is available. If the required subscriber profile is not included
in the VLR/SGSN, the error has to be sorted out before continuation of
tests.
SCP Service Logic


GSM Association
Part 1
2.3.1.1.2 Location Update by MS8(a) in VPLMN(b)
Overview:
MS8(a) registers in VPLMN(b). It is verified, that the required subscriber profile
for MS8(a) – e.g.: SMS-CSI – is available.

No VLR/SGSN record exists for MS8(a).
well as SMS-CSI.
Check VLR/SGSN record for the IMSI/MSISDN of MS8(a).
Service logic: -
Result: Successful result if the following entries are included in VLR/SGSN
record:
SMS Teleservice TS22 provisioned
SMS-CSI
TriggerDetectionPoint: SMS_CollectedInfo
HPLMN(a)
HPLMN(a)
defaultSMSHandling: release
Comments: This test case confirms that the required subscriber profile for MS8(a) is
available. If the required subscriber profile is not included in the
VLR/SGSN, the error has to be sorted out before continuation of tests.
SCP Service Logic


GSM Association
Part 1
2.3.1.2 Check operation of IDP_SMS and CON_SMS

Overview:
MS8(a) sends a SM to MS7(a). Depending on InitialDPSMS content, the SM is
forwarded to either MS7(a) or MS8(a), with a modified Calling Party and a
modified SMSC-Address. The content of InitialDPSMS is checked and the
operation of ConnectSMS is verified.
Message-flow:
gsmSSF(b)/ SCF(a)
gprsSSF(b)
IDP_SMS(ServiceKey, ClgPartyNbr=MS8(a), DestSubscriberNbr=MS7(a), SMSCAddress=TestNbr14)
(i)
CON_SMS(DestSubscriberNumber=MS8(a), CallingPartyNumber=TestNbr15, SMSCAddress=HPLMN_SMSC)
(ii)
CON_SMS(DestSubscriberNumber=MS7(a), CallingPartyNumber=TestNbr15, SMSCAddress=HPLMN_SMSC)

HLR entry for MS8(a) contains "SMS-CSI". [Set by HLR Admin]
SMSC Address of MS8(a) is set to TestNbr14.
Action: MS8(a) sends a SM to MS7(a) using TestNbr14 as SMSC Address.
Service logic: IDP_SMS.SMSCAddress equals TestNbr14:
(i) If SCF has received all required parameters within IDP_SMS, the
SCF alters the DestinationSubscriberNumber to be that of MS8(a), the
CallingPartyNumber to be TestNbr15 and the SMSCAddress to be the
one of the HPLMN SMSC.
SCF sends ConnectSMS.
(ii) If SCF does not receive all parameters within IDP_SMS, the SCF
alters the DestinationSubscriberNumber to be that of MS7(a), the
CallingPartyNumber to be TestNbr15 and the SMSCAddress to be the
one of the HPLMN SMSC.
SCF sends Connect.
Result: (i) Successful result if MS8(a) receives the SM sent previously from
MS8(a) and CallingPartyNumber equals TestNbr15.
(ii) If no SM is received the test has failed. If MS7(a) receives the SM, at
least one parameter of the IDP_SMS is missing and the test has failed.
Comments: This test case confirms the operation of InitialDPSMS and ConnectSMS
and ensures that all mandatory parameters are present in InitialDPSMS.
If no SM is received a fundamental error has occurred and it has to be
sorted out before continuation of tests.
Note: The SMSCAddress (TestNbr14) sent by MS8(a) is a short code
that is going to be translated by SCF to a valid SMSCAddress.

GSM Association
Part 1
SCP Service Logic
The following Parameter are included in

IDP_SMS:
are to/from the SSP. sm3_1 ServiceKey
CallingPartyNumber
SMSCAddress
EventType
yes IMSI
LocationInformation.VLR/SGSN-Number
TimeAndTimezone
TPShortMessageSubSpecInfo
DestSubNbr = IDP_SMS.ClgPNbr TPProtocolIdentifier
CallingPartyNumber = TestNbr15 no
SMSCAddress = HPLMN_SMSC
DestSubNbr = IDP_SMS.DestSubscrNbr
CallingPartyNumber = TestNbr15
CON_ CON_ SMSCAddress = HPLMN_SMSC
SMS SMS
Idle
Note: LocationInformation in SGSN and MSC are mutually exclusive. Location information
should always be available - at least the VLR number or SGSN number. Additional
parameter may be included in InitialDPSMS.

GSM Association
Part 1
2.3.1.3 Check operation of REL_SMS

Overview:
MS7(a), registered in VPLMN(b), sends a SM to MS8(a), using HPLMN_SMSC
as SMSC Address. The SCP should release the SM transmission.
Message-flow:
gsmSSF(b)/
SCF(a)
gprsSSF(b)
IDP_SMS(ServiceKey, ClgPartyNbr=MS7(a), DestSubscriberNbr=MS8(a), SMSCAddr=HPLMN_SMSC)
REL_SMS

SMSC Address of MS7(a) is set to HPLMN_SMSC.
Action: MS7(a) sends a SM to MS8(a) using HPLMN_SMSC as SMSC Address.
Service logic: IDP_SMS.SMSCAddress consists of HPLMN_SMSC and
IDP_SMS.DestSubscriberNumber starts with CC+NDC of country(a)
and
IDP_SMS.DestSubscriberNumber does not equal
IDP_SMS.CallingPartyNbr:
The SCF sends ReleaseSMS.
Result: Successful result if the SM is not sent.
If MS7(a) receives an indication that SM is successfully transmitted to

SMSC and/or MS8(a) receives the SM the test has failed
Comments: This test case checks the proper operation of ReleaseSMS.

GSM Association
Part 1
SCP Service Logic

are to/from the SSP. sm3_2
RPCause = ShortMessagTransferRejected
REL_
SMS
Idle

GSM Association
Part 1
2.3.1.4 Check Default SMS Handling
Message-flow:
gsmSSF(b)/ SCF(a)
gprsSSF(b)
IDP_SMS(ServiceKey, ClgPartyNbr=MSx(a), DestSubscriberNbr=MSx(a), SMSC=HPLMN_SMSC)
no answer to IDP
2.3.1.4.1 defaultSMSHandling set to continue

Overview:
MS7(a), roaming in VPLMN(b), sends a SM to itself. SCP does not answer to
InitialDPSMS. The Default SMS Handling of MS7(a) equals continue. The SM
is forwarded to MS7(a). The correct utilisation of the Default SMS Handling is
verified.

HLR record of MS7(a) contains SMS-CSI with parameter
defaultSMSHandling set to continue. [Set by HLR Admin]
SMSC Address of MS7(a) is set to HPLMN_SMSC.
Action: MS7(a) sends a SM to itself.
and IDP_SMS.DestSubscriberNumber equals
SCF does not answer to IDP_SMS. Alternatively SCF may send an
Abort message.
Result: Successful result if MS7(a) receives the SM previously sent from
MS7(a).
In any other cases the test has failed.

Comments: This test case checks the correct utilisation of the SMS-CSI parameter
defaultSMSHandling=continue.
IDP_SMS. In this case SCF should send an Abort message, which
triggers the defaultSMSHandling in the SSF.

GSM Association
Part 1
2.3.1.4.2 defaultSMSHandling set to release

Overview:
MS8(a), roaming in VPLMN(b), sends a SM to itself. SCP does not answer to
InitialDPSMS. The Default SMS Handling of MS8(a) equals release. The
correct utilisation of the Default SMS Handling is verified.

HLR record of MS8(a) contains SMS-CSI with parameter
defaultSMSHandling set to release. [Set by HLR Admin]
SMSC Address of MS8(a) is set to HPLMN_SMSC
Action: MS8(a) sends a SM to itself.
and IDP_SMS.DestSubscriberNumber equals
SCF does not answer to IDP_SMS. Alternatively SCF may send an
Abort message.
Result: Successful result if SM is NOT sent.

SMSC and/or MS8(a) receives the SM the test has failed.
Comments: This test case checks the correct utilisation of the SMS-CSI parameter
defaultSMSHandling=release.
IDP_SMS. In this case SCF should send an Abort message, which
triggers the defaultSMSHandling in the SSF.
SCP Service Logic
sm3_3
Idle
Note: In case SCF implementation does not allow to send no answer to IDP_SMS an Abort

GSM Association
Part 1
2.3.1.5 Check operation of RR_SMS_Event, CUE_SMS and ER_SMS

Overview:
MS8(a), registered in VPLMN(b), sends a SM to MS3(b), using HOME_SMSC
as SMSC Address. The SCF should request the SSF to continue SMS
processing without any changes. The operation of ContinueSMS is verified
Message-flow:
gsmSSF(b)/ SCF(a)
gprsSSF(b)
IDP_SMS(ServiceKey, ClgPartyNbr=MS8(a), DestSubscriberNbr=MS3(b), SMSCAddress=HPLMN_SMSC)
RR_SMS_Event([O_SMS_Submitted,notify], [O_SMS_Failure, notify]) +

CUE_SMS
ER_SMS(O_SMS_Submitted)
Preconditions: * Test case “2.3.1.4.2 defaultSMSHandling set to release” is passed.

* MS8(a) and MS3(b) have location updated successfully in VPLMN(b).
* SMSC Address of MS8(a) is set to HPLMN_SMSC.
Action: MS8(a) sends a SM to MS3(b) using HPLMN_SMSC as SMSC Address.
IDP_SMS.DestSubscriberNumber does not start with CC+NDC of
country(a):
SCF arms the detection points O_SMS_Submitted and O_SMS_Failure
using the information flow RequestReportSMSEvent and sends
ContinueSMS.
Optional: After reception of ER_SMS(O_SMS_Submitted) the SCF

initiates the transmission of a SM to MS8(a) with the following content:
“DP O_SMS_Submitted reported; the test is passed.”
Result: Successful result if
* MS3(b) received SM sent from MS8(a) and
* If HPLMN has indicated that SCF-initiated SMS is used: MS8(a)
received a SM with the following content: “DP O_SMS_Submitted
reported; the test is passed.”
If no SM is received the test has failed.

Comments: It is important that test case “2.3.1.4.2 defaultSMSHandling set to release”
has passed before to eliminate the possibility that the actual test case
passed because of the following two errors:
1. ContinueSMS leads to DefaultCallHandling in SSF and
2. DefaultCallHandling = release does not work
The correct reporting of the detection point O_SMS_Submitted to the

SCF can be checked in the following ways:
1. If HPLMN has indicated that SCF-initiated SMS is used: MS8(a) will
receive an appropriate SM.
2. The tester uses a protocol analyser and checks the transmission of
EventReportSMS(O_SMS_Submitted).

GSM Association
Part 1
SCP Service Logic

SMSEvents
SMSEvent
eventTypeSMS = o-smsSubmitted (3)
RR_SMS_ SMSEvent
Event eventTypeSMS = o-smsFailure (2)
CUE_ SMS
eventTypeSMS = o-smsSubmitted (3)

miscCallInfo
Wait for ER_SMS messageType = notification (1)
ERB_SMS
SCF-initiated SM is supported
NO
Receiver: IDPgprs.mSISDN
YES SM-content: "DP O_SMS_Submitted reported; the
test is passed."
Initiate SM
Idle

GSM Association
Part 1
2.3.1.6 Barring of outgoing international calls except to HPLMN country for SMS
(BOICexHC) (optional)
Overview:
MS7(a) sends a SM to TestNbr16. The Supplementary Service “Barring of
outgoing international calls except those directed to the HPLMN country”
applies to MS7(a) for SMS (Teleservice 20). SCF alters the SMSC address to
a SMSC located in country(c). It is checked that BOICexHC is executed
correctly after mobile originated CAMEL service invocation.
This test depends on the possibility to use a SMSC not belonging to the
VPLMN nor HPLMN, but which will correctly deliver the messages it receives.
Message-flow:
gsmSSF(b)/ SCF(a)
gprsSSF(b)
IDP_SMS(ServiceKey, ClgPartyNbr=MS7(a), DestSubscriberNbr=MS7(b), SMSCAddress=TestNbr16)
RR_SMS_Event(O_SMS_Failure, notify) + CON(SMSCAddress=country(c)_SMSC)
ER_SMS(O_SMS_Failure, notify)

HLR entry for MS7(a) contains:
“SMS-CSI”. [Set by HLR Admin]
“SS: BOICexHC : Active for TS20”. [Set by HLR Admin]
SMSC Address of MS7(a) is set to TestNbr16
Action: MS7(a) sends a SM to itself using TestNbr16 as SMSC Address.
Service logic: IDP_SMS.SMSCAddress consists of TestNbr16:
The SCF alters the SMSC Address to be a SMSC in country(c).
SCF arms the detection point O_SMS_Failure using the information flow
RequestReportSMSEvent and sends ConnectSMS.
Optional: After reception of ER_SMS(O_SMS_Failure) the SCF

initiates the transmission of a SM to MS7(a) with the following content:
“DP O_SMS_Failure reported; the test is passed.”
Result: Successful result
* if the SM transmission is barred and
* If HPLMN has indicated that SCF-initiated SMS is used: MS7(a)
received a SM with the following content: “DP O_SMS_Failure reported;
the test is passed.”

SMSC and/or MS7(a) receives the SM the test has failed.
of mobile originated SM.
Note1: For this test to be performed, a SMSC located in a country

different from the HPLMN and VPLMN must be used. Furthermore,

GSM Association
Part 1
MS7(a) must be in a range of number accepted both as origin and
destination by the SMSC if submitted. This is to make sure that in case
barring does not work the SMS is delivered. If such a SMSC is not
available a protocol analyser can be used to verify that the SMS is
properly barred at the VMSC.
Note2: The necessity to send ER_SMS(O_SMS_Failure) in case SMS

is barred because of ODB is part of a CR to 3GPP TS 23.078. This CR
is not included in TS 23.078 referred to in this document. If the
mentioned CR is not implemented in visited-gsmSSF/gprsSSF
ER_SMS(O_SMS_Failure) may not be sent.
Note3: The SMSCAddress (TestNbr16) sent by MS7(a) is a short code

that is going to be translated by SCF to a valid SMSC-address.

GSM Association
Part 1
SCP Service Logic

SMSEvents
SMSEvent
RR_SMS_ eventTypeSMS = o-smsFailure (2)
Event monitorMode = notifyAndContinue (1)
SMSCAddress = country(c)_SMSC
CON_ SMS
eventTypeSMS = o-smsFailure (2)

miscCallInfo
Wait for ER_SMS messageType = notification (1)
ERB_SMS
NO
YES SM-content: "DP O_SMS_Failure reported; the test is
passed."
Initiate SM
Idle

GSM Association
Part 1
2.3.2 GPRS Control

General
Most of the tests included in this chapter require to establish a PDP context to an application
located in HPLMN(a). HPLMN(a) should give VPLMN(b) information on how to access the
server/application to download data.
There is no requirement for the application to download a certain amount of data. In most of
the tests the SCF will release the PDP context as soon as a certain amount of data is
transmitted. To achieve this the application has to provide the possibility to transfer 50kByte
or more. It should easily be able for the tester to download such an amount of data.
In addition HPLMN(a) should take care to choose an application which does not require very
specific tools to be accessed because these tools have to be used by the tester during
testing. It is recommended to use an Internet access or FTP.
The message flow may marginally differ from the one included in the test cases. This
particularly applies to the TCAP handling.

GSM Association
Part 1
Entry Service Logic
Idle
are to/from the gprsSSP.
IDP_GPRS
Analyse gprsEventType
gprsEventType = attach
gp3_7
any other case
Analyse AccessPointName
APN = TestAPN1
gp3_1
APN = TestAPN2
gp3_2
APN = TestAPN3
gp3_3
APN = TestAPN4
gp3_4
APN = TestAPN5
gp3_5
APN = TestAPN6
gp3_6
1gprs
Figure 9: Entry process for GPRS service logic: CAMEL Phase 3 (part 1 of 2)

GSM Association
Part 1

1gprs are to/from the gprsSSP.
APN = TestServer1
gp3
_12
APN = TestAPN10
gp3
_13
APN = TestAPN9
gp3
_14
Figure 9: Entry process for GPRS service logic: CAMEL Phase 3 (part 2 of 2)

GSM Association
Part 1
2.3.2.1 GPRS-Attach
Message-flow:
SGSN(b) HLR(a)
updateLocation
ISD(GPRS-CSI)
updateLocation Res
2.3.2.1.1 GPRS-Attach by MS7(a) in VPLMN(b) (GPRS Attach only)

Overview:
MS7(a) performs a GPRS-Attach in VPLMN(b). The successful insertion of
subscriber data – e.g.: GPRS-CSI – in the SGSN is verified.
No SGSN record exists for MS7(a).
HLR record contains basic service information including GPRS
subscription data as well as GPRS-CSI.
Action: Power-up MS7(a) and perform GPRS-Attach only on VPLMN(b).
Check MM contexts in MS7(a) and SGSN(b) for the IMSI/P-TMSI
/MSISDN of MS7(a).
Service logic: -
If MS7(a) is in READY state,
If valid MM contexts are established in MS7(a) and SGSN(b) and
If at least the following entries are included in SGSN record:
* GPRS-CSI
gprs-CamelTDPDataList
GPRS-CamelTDPData
gprs-TriggerDetectionPoint pdp-ContextEstablishment (11)
serviceKey equal to info provided by HPLMN(a)
gsmSCF-Address equal to info provided by
HPLMN(a)
defaultSessionHandling releaseTransaction (1)
GPRS-CamelTDPData
gprs-TriggerDetectionPoint pdp-ContextChangeOfPosition
(14)
HPLMN(a)
defaultSessionHandling continueTransaction (0)
camelCapabilityHandling CAMEL Phase 3 (3)
including GPRS-CSI and that the required subscriber profile for MS7(a)
is available. If the required subscriber profile is not included in the
SGSN, the error has to be sorted out before continuation of tests.
SCF Service Logic


GSM Association
Part 1
2.3.2.1.2 GPRS-Attach by MS8(a) in VPLMN(b) (GPRS Attach only)
Overview:
MS8(a) performs a GPRS-Attach in VPLMN(b). The successful insertion of
subscriber data – example: GPRS-CSI – in the SGSN is verified.

No SGSN record exists for MS8(a).
HLR record contains basic service information including GPRS
subscription data as well as GPRS-CSI.
Action: Power-up MS8(a) and perform GPRS-Attach only on VPLMN(b).
Check MM contexts in MS8(a) and SGSN(b) for the IMSI/P-TMSI
/MSISDN of MS8(a).
Service logic: -
If MS8(a) is in READY state,
If valid MM contexts are established in MS8(a) and SGSN(b) and
If at least the following entries are included in SGSN record:
* GPRS-CSI
gprs-CamelTDPDataList
GPRS-CamelTDPData
gprs-TriggerDetectionPoint attach (1)
HPLMN(a)
defaultSessionHandling continueTransaction (0)
GPRS-CamelTDPData
gprs-TriggerDetectionPoint attachChangeOfPosition (2)
HPLMN(a)
defaultSessionHandling releaseTransaction (1)
camelCapabilityHandling CAMEL Phase 3 (3)
including GPRS-CSI and that the required subscriber profile for MS8(a)
is available. If the required subscriber profile is not included in the
SGSN, the error has to be sorted out before continuation of tests.
SCF Service Logic


GSM Association
Part 1
2.3.2.2 Check correct reporting of used Time and Volume using

ACgprs/ACRgprs
2.3.2.2.1 Check used Volume, 2 PDP context periods, tariffSwitch after PCD
Overview:
MS7(a), GPRS attached in VPLMN(b), sets up a PDP context to TestAPN1
and is connected to TestServer1. MS7(a) transfers data. If the transferred
volume in the PDP context periods is reported correctly and all mandatory
parameter are included in InitialDPGPRS SCF releases the PDP context after
transmission of 5 Kbytes. Otherwise PDP context is continued. The operation
of the CAP3-information flows FurnishChargingInformationGPRS,
RequestReportGPRSEvent, ConnectGPRS, EventReportGPRS,
ApplyChargingGPRS, ApplyChargingReportGPRS, ContinueGPRS and
ReleaseGPRS is verified.
Message-flow:
gprsSSF(b) SCF(a)
TC_Begin{IDPgprs(ServiceKey, GPRSEventType=PCE, APN=TestAPN1)}
TC_CUE{FCIgprs(10 byte FreeFormatData) +

RRgprsE([PCEack, interrupted], [PCD, interrupted]) + CONgprs(APN=TestServer1)}
TC_CUE{ERgprs(PCEack, interrupted)}
TC_CUE{ReturnResult(ERgprs) + ACgprs(MTVol=2500byte) + CUEgprs}
TC_END
TC_Begin{ACRgprs(VolINTS)}
TC_CUE{ReturnResult(ACRgprs) + ACgprs(MTVol=2500byte, TSI=3600sec)}
TC_END
TC_Begin{ACRgprs(VolINTS)}
(i)
TC_CUE{ReturnResult(ACRgprs) + FCIgprs(20 byte FreeFormatData) + Rgprs(GPRSCause)}
TC_END
(ii)
TC_CUE{ReturnResult(ACRgprs) + ACgprs(MTVol=1MByte)}
TC_END
...

GSM Association
Part 1
Preconditions: MS7(a) is GPRS-Attached in VPLMN(b). (MS in STANDBY or READY

state)
No valid PDP contexts are established in MS7(a).
MS7(a) is connected to a device (e.g. a laptop) providing an application
to use the data-transfer-services provided by HPLMN(a) (e.g.
WAP,ftp,WWW).
Action: MS7(a) performs “Activate PDP Context Request” to TestAPN1
MS7(a) transmits data using a service provided by HPLMN(a).
Service logic: IDPgprs.accessPointName consists of TestAPN1:
The SCF alters the APN to be that of Test Server 1 and sends
FCIgprs(10 byte FFD) + RRgprsE + CONgprs.
When ERgprs(PCE-ack) is received SCF sends
ACgprs(MTVol=2500byte) + CUEgprs.
When ACRgprs(VolINTS1) is received SCF sends
ACgprs(MTVol=2500byte,TSI=3600sec)
When ACRgprs(VolINTS2) is received SCF sends
(i) FCIgprs(20 byte FFD) + Rgprs if

VolINTS1 = 2500 ± 250 byte AND
VolINTS2 = 5000 ± 500 byte AND
all mandatory parameters are included in IDPgprs
(ii) ACgprs(MTVol=1.000.000byte) if
transferred volume values are not received correctly OR
mandatory parameter are missing in IDPgprs
Result: (i) Successful result if data transfer is released after 5000 ± 500 byte.
(ii) In any other case the test has failed.

Comments: This test case confirms the correct reporting of transferred volume of
two periods within a PDP context.
The proper inter-working of FCIgprs can be verified through post-
processing of TAP records in the HPLMN. The FreeFromatData sent in
the second FCIgprs should overwrite the FreeFormatData of first
FCIgprs. FreeFormatData are mapped to the parameter cseInformation
in the TAP record.

GSM Association
Part 1
SCF Service Logic
The following parameter are included in IDPgprs:

Signals to/from the left gp3_1
are to/from the SSP. GPRSReferenceNumber
ServiceKey
GPRSEventType
MSISDN
1 NO IMSI
TimeAndTimeZone
AccessPointName
YES LocationInformationInSGSN.SGSNNumber
FCIgprs + RRgprsE FCIgprs.FreeFormatData 10 byte

+ CONgprs
RRgprsE
gprsEvent
GPRSEventType = pdp-ContextEstablishmentAck (12)
MonitorMode = interrupted (0)
Wait for ERgprs
gprsEvent
GPRSEventType = disconnect (13)
ERgprs
CONgprs.AccessPointName = TestServer1
ERgprs.GPRSEventType =
pdp-ContextEstablishmentAcknowledgement (12)
1 NO
YES
ACgprs.ChargingCharacteristics.maxTransferredVolume =
ReturnResult(ERgprs) + 2500 [byte]
ACgprs + CUEgprs
Wait for ACRgprs
ACRgprs

GSM Association
Part 1
Signals to/from the left 2

ACRgprs.ChargingResult.TransferredVolume.
volumeIfNoTariffSwitch = 2500 ± 250 [byte]
1 NO
YES ACgprs
ChargingCharacteristics
ReturnResult(ACgprs) + maxTransferredVolume = 2500 [byte]
ACgprs tariffSwitchInterval = 3600 [sec]
Wait for ACRgprs
ACRgprs
ACRgprs.ChargingResult.TransferredVolume.
volumeIfNoTariffSwitch = 5000 ± 500 [byte]
1 NO
YES
ReturnResult(ACRgprs) + FCIgprs.FreeFormatData 20 byte

FCIgprs + Rgprs Rgprs.GPRSCause = Unspecified (0)
Idle
YES
ReturnResult(ACRgprs) + 1 000 000 [byte]
ACgprs
Wait for ACRgprs

+ ERgprs
Evaluation of ACRgprs and ERgprs is not necessary due to

ACRgprs + incorrect values received in previous ACRgprs.
ERgprs
Idle
Notes:
* Additional parameter may be included in IDPgprs. This still leads to exit “yes”.
* The 10 byte FreeFormatData of the first FCIgprs information flow should differ from the first
10 byte of the second FCIgprs to make clear that the FreeFormatData of first FCIgprs got
overwritten.

GSM Association
Part 1
2.3.2.2.2 Check used Volume, 3 PDP context periods, tariffSwitch in 2nd period
Overview:
and is connected to TestServer1. MS7(a) transfers data. A tariff switch occurs
in the second PDP context period. If the transferred volume in the PDP
context periods is reported correctly SCF releases the PDP context after
transmission of 30 Kbytes. Otherwise PDP context is continued.
Message-flow:
gprsSSF(b) SCF(a)
TC_CUE{RRgprsE([PCEack, interrupted], [PCD, interrupted]) + CONgprs(APN=TestServer1)}
TC_CUE{ReturnRes(ERgprs) + ACgprs(MTVol=5kByte) + ACgprs(METime=3600sec) + CUEgprs}
TC_END
TC_Begin{ACRgprs(VolINTS1) + ACRgprs(TgprsINTS1)}
TC_CUE{ReturnResult(ACRgprsVol) + ReturnResult(ACRgprsTime) +
ACgprs(MTVol=20kByte,TSI=2sec) + ACgprs(METime=3600sec,TSI=2sec)}
TC_END
TC_Begin{ACRgprs(VolSLTS2,VolTSI2) + ACRgprs(TgprsSLTS2,TgprsTSI)}
ACgprs(MTVol=5kByte) + ACgprs(METime=3600sec)}
TC_END
TC_Begin{ACRgprs(VolSLTS3) + ACRgprs(TgprsSLTS3)}
(i)
TC_CUE{ReturnResult(ACRgprsVol) + ReturnResult(ACRgprsTime) + Rgprs(GPRSCause)}
TC_END
(ii) TC_CUE{ReturnResult(ACRgprsVol) + ReturnResult(ACRgprsTime) +

ACgprs(MTVol=1MByte) + ACgprs(METime=3600sec)}
TC_END
...

GSM Association
Part 1
state)
WAP,ftp,WWW).
RRgprsE + CONgprs.
ACgprs(MTVol=5000byte) + ACgprs(METime=3600sec) + CUEgprs.
When ACRgprs(VolINTS1) + ACRgprs(TgprsINTS1) is received SCF
sends ACgprs(MTVol=20.000byte,TSI=2sec) +
ACgprs(METime=3600sec,TSI=2sec)
When ACRgprs(VolSLTS2,VolTSI2) +
ACRgprs(TgprsSLTS2,TgprsTSI2) is received SCF sends
ACgprs(MTVol=5.000byte) + ACgprs(METime=3600sec)
When ACRgprs(VolSLTS3) + ACRgprs(TgprsSLTS3) is received SCF
sends
(i) Rgprs if [VolINTS1 = 5000 ± 500 byte] AND

[VolSLTS2 + VolTSI2 = 25.000 ± 2.500 byte] AND
[VolTSI2 + VolSLTS3 = 30.000 ± 3.000 byte]
(ii) ACgprs(MTVol=1.000.000 byte) if transferred volume values are not

received correctly.
Result: (i) Successful result if data transfer is released after 30.000 ± 300 byte.

three periods within a PDP context. A tariff switch occurs in the second
PDP context period.

GSM Association
Part 1
SCF Service Logic
RRgprsE
Signals to/from the left gp3_2 gprsEvent
RRgprsE + gprsEvent
CONgprs GPRSEventType = disconnect (13)
Wait for ERgprs
ERgprs
ERgprs.GPRSEventType = pdp-ContextEstablishmentAck (12)

1 NO
YES ACgprs.ChargingCharacteristics.maxTransferredVolume =
5000 [byte]
ReturnResult(ERgprs) +
ACgprs(Vol) + ACgprs.ChargingCharacteristics.maxElapsedTime =
ACgprs(Time) 3600 [sec]
Wait for 2 ACRgprs
ACRgprs(Vol) +
ACRgprs(Time) ACRgprs.
chargingResult
TransferredVolume
volumeIfNoTariffSwitch1 = 5000 ± 500 [byte]
1 NO
ACgprs
YES ChargingCharacteristics.maxTransferredVol = 20000 [byte]
tariffSwitchInterval = 2 [sec]
ReturnRes(ACRgprs(Vol)) +
ReturnRes(ACRgprs(Time)) + ACgprs
ACgprs(Vol) +ACgprs(Time) + ChargingCharacteristics.maxElapsedTime = 3600 [sec]
CUEgprs tariffSwitchInterval = 2 [sec]
Wait for 2 ACRgprs
ACRgprs(Vol) +
ACRgprs(Time)
ACRgprs.TransferredVolume.volumeSinceLastTariffSwitch2 +
ACRgprs.TransferredVolume.volumeTariffSwitchInterval2 =
25000 ± 2500 [byte]
1 NO
YES

GSM Association
Part 1
Signals to/from the left 2

5000 [byte]
ReturnResult(ACRgprs(Vol)) +
ReturnResult(ACRgprs(Time)) ACgprs.ChargingCharacteristics.maxElapsedTime =
+ ACgprs(Vol) +ACgprs(Time) 3600 [sec]
Wait for 2 ACRgprs
ACRgprs(Vol) +
ACRgprs(Time)
ACRgprs.TransferredVolume.volumeSinceLastTariffSwitch3 +
ACRgprs.TransferredVolume.volumeTariffSwitchInterval2 =
30000 ± 3000 [byte]
1 NO
YES
ReturnResult(ACRgprs1) + Rgprs.gprsCause = unspecified (0)

ReturnResult(ACRgprs2) +
Rgprs
Idle
1 000 000 [byte]
ReturnResult(ACRgprs(Time)) ACgprs.ChargingCharacteristics.maxElapsedTime =
+ ACgprs(Vol) +ACgprs(Time) 3600 [sec]
Wait for 2 ACRgprs +

ERgprs

ACRgprs(Vol) + incorrect values received in previous ACRgprs.
ACRgprs(Time) +
ERgprs
Idle

GSM Association
Part 1
2.3.2.2.3 Check used Time, 2 PDP context periods, tariffSwitch in 1st period
Overview:
in the first PDP context period. If the elapsed time in the first and the second
PDP context period is reported correctly SCF releases the PDP context after
15 seconds. Otherwise PDP context is continued.
Message-flow:
gprsSSF(b) SCF(a)
TC_CUE{ FCIgprs(1 byte FreeFormatData) +

RRgprsE([PCEack, interrupted], [PCD, interrupted]) + CONgprs(APN=TestServer1)}
TC_CUE{ReturnRes(ERgprs) + ACgprs(METime=10sec,TSI=2sec) + CUEgprs}
TC_END
TC_Begin{ACRgprs(TgprsSLTS1,TgprsTSI1)}
TC_CUE{ReturnResult(ACRgprsTime) + FCIgprs(39 byte FFD,AppendFFD=append) +

ACgprs(METime=5sec)}
TC_END
TC_Begin{ACRgprs(TgprsSLTS2)}
(i)
TC_CUE{ReturnResult(ACRgprsTime) + Rgprs(GPRSCause)}
TC_END
TC_CUE{ReturnResult(ACRgprsTime) + ACgprs(METime=3600sec)}
(ii)
TC_END
...

GSM Association
Part 1

state)
WAP,ftp,WWW).
FCIgprs(1byte FreeFormatData) + RRgprsE + CONgprs.
FCIgprs(39 byte FreeFormatData,AppendFFD=append) +
ACgprs(METime=10sec,TSI=2sec) + CUEgprs.
When ACRgprs(TgprsSLTS1,TgprsTSI) is received SCF sends
ACgprs(METime=5sec)
When ACRgprs(TgprsSLTS2) is received SCF sends
(i) Rgprs if [TgprsTSI1 = 2 ± 1 sec] AND

[TgprsSLTS1 = 8 ± 1 sec] AND
[TgprsSLTS2 = 13 ± 1 sec]
(ii) ACgprs(METime=3600sec) if transferred volume values are not

received correctly.
Result: (i) Successful result if data transfer is released after 15± 2 seconds.

Comments: This test case confirms the correct reporting of elapsed time of two
periods within a PDP context. A tariff switch occurs in the first PDP
context period. The proper inter-working of FCIgprs can be verified
through post-processing of TAP records in the HPLMN. The
FreeFromatData sent in the second FCIgprs should be appended to the
FreeFormatData of first FCIgprs. FreeFormatData are mapped to the
parameter cseInformation in the TAP record.

GSM Association
Part 1
SCF Service Logic

are to/from the SSP. gp3_3
FCIgprs + RRgprsE FCIgprs.FreeFormatData 1 byte

+ CONgprs
RRgprsE
gprsEvent
Wait for ERgprs
gprsEvent
GPRSEventType = disconnect (13)
ERgprs
1 NO
YES ACgprs
ChargingCharacteristics.maxElapsedTime = 10 [sec]
ReturnResult(ERgprs) + tariffSwitchInterval = 2 [sec]
ACgprs + CUEgprs
Wait for ACRgprs
ACRgprs ACRgprs
chargingResult
elapsedTime
timeGPRSIfTariffSwitch
timeGPRSSinceLastTariffSwitch1 = 8 ± 1 [sec]
1 NO timeGPRSTariffSwitchInterval1 = 2 ± 1 [sec]
YES
FCIgprs
FreeFormatData 39 byte
appendFreeFormatData = append (1)
ReturnResult(ACRgprs) +
FCIgprs + ACgprs ACgprs.ChargingCharacteristics.maxElapsedTime = 5 [sec]
Wait for ACRgprs
ACRgprs

GSM Association
Part 1

2
ACRgprs
chargingResult
elapsedTime
timeGPRSSinceLastTariffSwitch2 = 13 ± 1 [sec]
1 NO
YES
Rgprs.gprsCause = unspecified (0)

Rgprs
Idle
ACgprs.ChargingCharacteristics.maxElapsedTime =
ReturnResult(ACRgprs) + 3600 [sec]
ACgprs
Wait for ACRgprs +

ERgprs

ACRgprs + incorrect values received in previous ACRgprs.
ERgprs
Idle

GSM Association
Part 1
2.3.2.2.4 Check used Time, 3 PDP context periods, tariffSwitch in 2nd period
Overview:
in the second PDP context period. If the elapsed time in the first and the
second PDP context periods is reported correctly SCF grants new time and
volume and continues the PDP context. MS7(a) initiates PDP context
disconnection.
Message-flow:
SGSN(b) SCP(a)
TC_CUE{RRgprsE([PCEack, interrupted], [PCD, interrupted]) + CONgprs(APN=TestServer1)}
TC_CUE{ReturnRes(ERgprs) + ACgprs(MTVol=4GByte) + ACgprs(METime=5sec) + CUEgprs}
TC_END
TC_Begin{ACRgprs(VolINTS1) + ACRgprs(TgprsINTS1)}
ACgprs(MTVol=100MByte,TSI=2sec) + ACgprs(METime=10sec,TSI=2sec)}
TC_END
TC_Begin{ACRgprs(VolSLTS2,VolTSI2) + ACRgprs(TgprsSLTS2,TgprsTSI2)}
(i) TC_CUE{ReturnResult(ACRgprsVol) + ReturnResult(ACRgprsTime) +

ACgprs(MTVol=10MByte) + ACgprs(METime=86.400sec)}
TC_END
TC_Begin{ACRgprs(VolSLTS3) + ACRgprs(TgprsSLTS3) + ERgprs(PCD,initiatingEntity=ms)}
TC_CUE{ReturnRes(ACRgprsVol) + ReturnRes(ACRgprsTime) + ReturnRes(ERgprs) + CUEgprs
TC_END
(ii)
TC_CUE{ReturnResult(ACRgprsVol) + ReturnResult(ACRgprsTime) + Rgprs(GPRSCause)}
TC_END

GSM Association
Part 1
state)
WAP,ftp,WWW).
MS7(a) disconnects the PDP context after 30 seconds.
RRgprsE + CONgprs.
ACgprs(MTVol=4GByte) + ACgprs(METime=5sec) + CUEgprs.
When ACRgprs(VolINTS1) + ACRgprs(TgprsINTS1) is received SCF
sends ACgprs(MTVol=100MByte,TSI=2sec) +
ACgprs(METime=10sec,TSI=2sec)
When ACRgprs(VolSLTS2,VolTSI2) +
ACRgprs(TgprsSLTS2,TgprsTSI2) is received SCF sends
(i) ACgprs(MTVol=10MByte) + ACgprs(METime=86400sec) if

[TgprsINTS1 = 5 ± 1 sec] AND
[TgprsTSI2 = 7 ± 1 sec] AND
[TgprsSLTS2 = 8 ± 1 sec]
(ii) Rgprs if the elapsed time values are not reported correctly.
Result: (i) Successful result if PDP context remains active for more than 20
seconds.
two periods within a PDP context. A tariff switch occurs in the second
PDP context period.
It is also possible for the tester to check whether the GPRSevent
Disconnect has been properly reported to the SCF by checking the
ERgprs message after MS7(a) has disconnected the PDP context. For
this it is necessary to use a Protocol Analyser. This part of the test case
is optional.

GSM Association
Part 1
SCF Service Logic
RRgprsE
are to/from the SSP. gp3_4 gprsEvent
RRgprsE + gprsEvent
Wait for ERgprs
ERgprs
1 NO
ACgprs
YES
maxTransferredVolume = 4 000 000 000 [byte]
ACgprs(Vol) + ACgprs
ACgprs(Time) + CUEgprs ChargingCharacteristics
maxElapsedTime = 5 [sec]
Wait for 2 ACRgprs
ACRgprs(Vol) +
ACRgprs(Time) ACRgprs
chargingResult
elapsedTime
timeGPRSIfNoTariffSwitch = 5 ± 1 [sec]
1 NO
YES
ACgprs
ReturnResult(ACRgprs(Vol)) + ChargingCharacteristics
ReturnResult(ACRgprs(Time)) + maxTransferredVolume = 100 000 000 [byte]
ACgprs(Vol) + ACgprs(Time) tariffSwitchInterval = 2 [sec]
ACgprs
Wait for 2 ACRgprs maxElapsedTime = 10 [sec]
tariffSwitchInterval = 2 [sec]
ACRgprs(Vol) +
ACRgprs(Time)

GSM Association
Part 1

2
are to/from the SSP. ACRgprs
chargingResult
elapsedTime
timeGPRSSinceLastTariffSwitch = 8 ± 1 [sec]
1 NO timeGPRSTariffSwitchInterval = 7 ± 1 [sec]
YES
ReturnResult(ACRgprs(Vol)) + ACgprs
ReturnResult(ACRgprs(Time)) + ChargingCharacteristics
ACgprs(Vol) + ACgprs(Time) maxTransferredVolume = 10 000 000 [byte]
ACgprs
Wait for 2 ACRgprs + maxElapsedTime = 86 400 [sec]
ERgprs
ACRgprs(Vol) +
ACRgprs(Time) +
ERgprs
ReturnResult(ACRgprs(Time)) +
CUEgprs
Idle
ReturnResult(ACRgprs(Vol)) + Rgprs.gprsCause = unspecified (0)

ReturnResult(ACRgprs(Time))
+ Rgprs
Idle

GSM Association
Part 1
2.3.2.2.5 Parallel GPRS dialogues using GPRS CAMEL Scenario 2 (optional)

Overview:
MS7(a), GPRS attached in VPLMN(b), sets up one GPRS dialogue to
TestAPN5 which is connected to TestServer1 and a second GPRS dialogue to
TestAPN6 which is connected to TestServer2. MS7(a) transfers data. If the
transferred volume for both PDP contexts is reported correctly SCF releases
the GPRS dialogues. Otherwise the PDP contexts are continued.
This scenario is difficult to realise because of MS restrictions. A scenario is

parallel use of WAP and Internet Access using Terminal Equipment. However,
means for calculating the number of packets for both PDP Contexts are
required.
Message-flow:

GSM Association
Part 1
gprsSSF(b) SCF(a)
TC_Begin1{IDPgprs(ServiceKey, GPRSEventType=PCE, APN=TestAPN5)}
TC_CUE1{RRgprsE([PCEack, interrupted], [PCD, interrupted]) + CONgprs(APN=TestServer1)}
TC_CUE1{ERgprs(PCEack, interrupted)}
TC_CUE1{ReturnResult(ERgprs) + ACgprs(MTVol=5000byte) + CUEgprs}
TC_END1
TC_Begin2{IDPgprs(ServiceKey, GPRSEventType=PCE, APN=TestAPN6)}
TC_CUE2{RRgprsE([PCEack, interrupted], [PCD, interrupted]) + CONgprs(APN=TestServer2)}
TC_CUE2{ERgprs(PCEack, interrupted)}
TC_CUE2{ReturnResult(ERgprs) + ACgprs(MTVol=10kByte) + CUEgprs}
TC_END2
TC_Begin1{ACRgprs(VolINTS)}
(i)
TC_CUE1{ReturnResult(ACRgprs) + Rgprs(GPRSCause)}
TC_END1
(ii)
TC_CUE1{ReturnResult(ACRgprs) + ACgprs(MTVol=1MByte)}
TC_END1
...

GSM Association
Part 1
gprsSSF(b) SCF(a)
TC_Begin2{ACRgprs(VolINTS)}
(i)
TC_CUE2{ReturnResult(ACRgprs) + Rgprs(GPRSCause)}
TC_END2
(ii)
TC_CUE2{ReturnResult(ACRgprs) + ACgprs(MTVol=1MByte)}
TC_END2
...
state)
WAP,ftp,WWW).
MS7(a) performs “Activate PDP Context Request” to TestAPN6
MS7(a) transmits data using a service provided by HPLMN(a) within
PDP Context 1.
PDP Context 2.
RRgprsE + CONgprs.
ACgprs(MTVol=5.000byte) + CUEgprs.
When ACRgprs(VolINTS) is received SCF sends
(i) Rgprs if VolINTS = 5.000 ± 500 byte
(ii) ACgprs(MTVol=1.000.000byte) if transferred volume value is not

received correctly.
IDPgprs.accessPointName consists of TestAPN6:

RRgprsE + CONgprs.
ACgprs(MTVol=10.000byte) + CUEgprs.
When ACRgprs(VolINTS) is received SCF sends
(i) Rgprs if VolINTS = 10.000 ± 1.000 byte

received correctly.
Result: (i) Successful result if both GPRS dialogues are released after
transmission of 15.000 ± 1.500 byte in total.

two parallel GPRS dialogues.

GSM Association
Part 1
It is difficult to execute this test. It is required that the tester is able to set
up two PDP contexts in parallel and to count the transmitted data for
each PDP context.

GSM Association
Part 1
SCF Service Logic

RRgprsE
RRgprsE + gprsEvent
Wait for ERgprs
ERgprs
1 NO
YES
ACgprs
ReturnResult(ERgprs) + maxTransferredVolume = 5 000 [byte]
ACgprs + CUEgprs
Wait for ACRgprs
ACRgprs
ACRgprs
chargingResult
transferredVolume
volumeIfNoTariffSwitch = 5 000 ± 500 byte
1 NO
YES
Rgprs.gprsCause = Unspecified (0)

Rgprs
Idle

GSM Association
Part 1
RRgprsE
RRgprsE + gprsEvent
Wait for ERgprs
ERgprs
1 NO
YES
ACgprs
ReturnResult(ERgprs) + maxTransferredVolume = 10 000 [byte]
ACgprs + CUEgprs
Wait for ACRgprs
ACRgprs
ACRgprs
chargingResult
transferredVolume
volumeIfNoTariffSwitch = 10 000 ± 1 000 byte
1 NO
YES
Rgprs.gprsCause = Unspecified (0)

Rgprs
Idle

GSM Association
Part 1

ACgprs
ReturnResult(ACRgprs) + maxTransferredVolume = 1 000 000 [byte]
ACgprs
Wait for ACRgprs +

ERgprs
ACRgprs +
ERgprs
CUEgprs
Idle

GSM Association
Part 1
2.3.2.3 CAMEL Scenario 1
Entry Service Logic
RRgprsE
Signals to/from the left gprsEvent
are to/from the SSP. gp3_7
gprsEvent
RRgprsE +ACgprs + GPRSEventType = detached (3)
CUEgprs MonitorMode = notifyAndContinue (1)
ACgprs
Wait for ERgprs maxElapsedTime = 3 600 [sec]
ERgprs
Analyse
AccessPointName and PDPID
[APN = TestAPN7] AND [PDPID = 1]
gp3_8
[APN = TestAPN8] AND [PDPID = 2]
gp3_9
[APN = TestServer1] AND [PDPID = 1]
gp3
any other case (Error exit) _10
Rgprs
Rgprs
gprsCause = Unspecified (0)
pDPID = ERgprs.pdpID
Idle
Figure 10: Entry process for CAMEL Phase 3 Scenario 1

GSM Association
Part 1
2.3.2.3.1 Parallel PDP contexts using GPRS CAMEL Scenario 1 (optional)

Overview:
MS8(a), GPRS attached in VPLMN(b), sets up one PDP context to TestAPN7
which is connected to TestServer1 and a second PDP context to TestAPN8
which is connected to TestServer2. MS8(a) transfers data. If the transferred
volume in the both PDP contexts is reported correctly SCF releases the PDP
contexts. Otherwise the PDP contexts are continued.
This scenario is difficult to realize because of MS restrictions. A scenario is

parallel use of WAP and Internet Access using Terminal Equipment. However,
means for calculating the number of packets for both PDP Contexts are
required.
Message-flow:
SGSN(b) SCF(a)
TC_Begin{IDPgprs(ServiceKey, GPRSEventType=attach)}
TC_CUE{RRgprsE([PCEack, interrupted],[detached, notifyAndContinue]) +

ACgprs(METime=3600sec) +CUEgprs}
TC_END
TC_Begin{ERgprs(gprsEventType = PCEack, PCESpecificInfo.APN = TestAPN7, PDPID = 1}
TC_CUE{ReturnResult(ERgprs) + ACgprs(MTVol=5kByte, PDPID=1) + CONgprs(APN=TestServer1)}
TC_END
TC_Begin{ERgprs(gprsEventType=PCEack, APN=TestAPN8, PDPID = 2}
TC_CUE{ReturnResult(ERgprs) + ACgprs(MTVol=10kByte, PDPID=2) + CONgprs(APN=TestServer2)}
TC_END
TC_Begin{ACRgprs(VolINTS, PDPID = 1)}
(i)
TC_CUE{ReturnResult(ACRgprs) + Rgprs(GPRSCause, PDPID = 1)}
TC_END
(ii)
TC_CUE{ReturnResult(ACRgprs) + ACgprs(MTVol=1MByte, PDPID = 1)}
TC_END
...

GSM Association
Part 1
SGSN(b) SCF(a)
TC_Begin{ACRgprs(VolINTS, PDPID = 2)}
(i)
TC_CUE{ReturnResult(ACRgprs) + Rgprs(GPRSCause, PDPID = 2)}
TC_END
(ii)
TC_CUE{ReturnResult(ACRgprs) + ACgprs(MTVol=1MByte, PDPID = 2)}
TC_END
...
TC_Begin{ACRgprs(TgprsINTS)}
TC_END{ReturnResult(ACRgprs)}
Preconditions: MS8(a) is switched off.

WAP,ftp,WWW).
Action: Switch on MS8(a) and perform GPRS-Attach.
PDP Context 1.
PDP Context 2.
Switch off MS8(a) to perform a GPRSdetach.
If HPLMN(a) has indicated that SCF-initiated SMS is supported: Switch
on MS8(a) to receive SM.
Service logic: IDPgprs.gprsEventType equals attach:
The SCF sends RRgprsE + ACgprs(METime=3600sec) + CUEgprs.
When ERgprs(PCE-ack, APN=TestAPN7, PDPID=1) is received SCF
alters the APN to be that of Test Server 1 and sends
ACgprs(MTVol=5.000byte, PDPID=1) + CONgprs.
When ACRgprs(VolINTS, PDPID=1) is received SCF sends
(i) Rgprs if VolINTS = 5.000 ± 500 byte

received correctly.
When ERgprs(PCE-ack, APN=TestAPN8, PDPID=2) is received SCF

alters the APN to be that of Test Server 2 and sends
ACgprs(MTVol=10.000byte, PDPID=2) + CONgprs.
When ACRgprs(VolINTS, PDPID=2) is received SCF sends
(i) Rgprs if VolINTS = 10.000 ± 1.000 byte

GSM Association
Part 1

received correctly.
Optional: After reception of ACRgprs(TgprsINTS) the SCF initiates the

transmission of a SM to MS8(a) with the following content: “ACgprs has
been sent to SCF. SGSN(b) reported that MS8(a) was attached for
<ACRgprs.TgprsINTS> seconds.”
Result: (i) Successful result if both PDP contexts are released after
transmission of 15.000 ± 1.500 byte.

two PDP contexts within one GPRS dialogue.
The correct reporting of the duration MS8(a) was attached can be

checked in the following way:
1. If HPLMN has indicated that SCF-initiated SMS is used: MS8(a) will
receive an appropriate SM. If possible HPLMN will include the duration
reported from SGSN(b).
2. HPLMN may compare this value with the duration the tester
measured.
This part of the test case is optional and the HPLMN may judge the
result.

GSM Association
Part 1
SCF Service Logic

gp3_8
ACgprs
maxTransferredVolume = 5 000 [byte]
ReturnResult(ERgprs) + pDPID =1
ACgprs + CONgprs
Wait for ACRgprs with

PDPID = 1
ACRgprs
ACRgprs
chargingResult
gp3 transferredVolume
NO
_e1 volumeIfNoTariffSwitch = 5 000 ± 500 [byte]
YES
Rgprs
pDPID =1
Rgprs
gp3
_11

GSM Association
Part 1

gp3_9
ACgprs
maxTransferredVolume = 10 000 [byte]
ReturnResult(ERgprs) + pDPID =2
ACgprs + CONgprs
Wait for ACRgprs with

PDPID = 2
ACRgprs
ACRgprs
chargingResult
gp3 transferredVolume
NO
_e1 volumeIfNoTariffSwitch = 10 000 ± 1 000 [byte]
YES
Rgprs
pDPID =2
Rgprs
gp3
_11

GSM Association
Part 1

are to/from the SSP. gp3
_e1
ACgprs
ReturnResult(ACRgprs) + maxTransferredVolume = 1 000 000 [byte]
ACgprs pDPID = ACRgprs.PDPID
Wait for ACRgprs
Evaluation of ACRgprs is not necessary due to incorrect

values received in previous ACRgprs.
ACRgprs
ReturnResult(ACRgprs)
gp3
_11

GSM Association
Part 1

_11
Wait for ACRgprs
ACRgprs for Time Supervision of GPRS dialogue

Optional:
Store ACRgprs.chargingResult.ElapsedTime.
ACRgprs
timeGPRSIfNoTariffSwitch for Short Message content.
ReturnResult(ACRgprs)
NO YES
SM content: "ACgprs received. SGSN(b) reported
that MS8(a) was attached for
Initiate SM <ACRgprs.TgprsINTS> seconds."
Idle

GSM Association
Part 1
2.3.2.3.2 Check Default GPRS handling set to continue

Overview:
MS8(a), GPRS attached in VPLMN(b), sets up a PDP context to TestServer1.
SCF responds to ERgprs(PCEack) with TCAP Abort. The
defaultGPRShandling of MS8(a) equals continue. If PDP context is established
the test is passed.
Message-flow:
SGSN(b) SCF(a)
TC_Begin{IDPgprs(ServiceKey, GPRSEventType=attach)}
TC_CUE{RRgprsE([PCEack, interrupted],[detached, notifyAndContinue]) +

ACgprs(METime=3600sec) +CUEgprs}
TC_END
TC_Begin{ERgprs(gprsEventType = PCEack, PCESpecificInfo.APN = TestServer1, PDPID = 1}
TC_Abort

state)
WAP,ftp,WWW).
Action: MS8(a) performs “Activate PDP Context Request” to TestServer1
Service logic: IDPgprs.gprsEventType equals attach:
The SCF sends RRgprsE + ACgprs(METime=3600sec) + CUEgprs.
When ERgprs(PCE-ack, APN=TestServer1, PDPID=1) is received SCF
sends TCAP Abort.
Result: (i) Successful result if the PDP context is established.

Comments: This test case confirms the correct utilization of the GPRS-CSI
parameter defaultGPRSHandling=continue.

GSM Association
Part 1
SCF Service Logic

_10
TC_Abort
Idle

GSM Association
Part 1
2.3.2.4 Check Default GPRS handling set to release within CAMEL Scenario 2
2.3.2.4.1 Abort during PDP context establishment

Overview:
MS7(a), GPRS attached in VPLMN(b), attempts to set up a PDP context to
TestServer1. SCF responds to ERB(PCEack) with TCAP Abort. The
defaultGPRShandling of MS7(a) equals release. If PDP context is NOT
established the test is passed.
Message-flow:
gprsSSF(b) SCF(a)
TC_Begin{IDPgprs(ServiceKey, GPRSEventType=PCE, APN=TestServer1)}
TC_Abort

state)
WAP,ftp,WWW).
Action: MS7(a) performs “Activate PDP Context Request” to TestServer1
Service logic: IDPgprs.accessPointName consists of TestServer1:
SCF sends TCAP Abort
Result: (i) Successful result if the PDP context is NOT established and MS7(a)
is NOT connected to TestServer1.

parameter defaultGPRSHandling=release in case PDP context
establishment is aborted.
SCF Service Logic
Signals to/from the left gp3

_12
TC_Abort
Idle

GSM Association
Part 1
2.3.2.4.2 Abort during active PDP context

Overview:
MS7(a), GPRS attached in VPLMN(b), attempts to set up a PDP context to
TestServer1. SCF sends TCAP Abort 10 seconds after PDP context is
established. The defaultGPRShandling of MS7(a) equals release. If PDP
context is NOT disconnected the test is passed.
In addition the ability to arm the Detection Point pdp-
ContextChangeOfPosition is verified.
Message-flow:
gprsSSF(b) SCF(a)
TC_CUE{ RRgprsE([PCEack, interrupted], [PCCoP, interrupted]) + CONgprs(APN=TestServer1)}
TC_CUE{ReturnRes(ERgprs) + CUEgprs}
TC_END
t = 10 sec
TC_Abort

state)
WAP,ftp,WWW).
The SCF alters the APN to be that of Test Server 1 and sends RRgprsE
+ CONgprs.
When ERgprs(PCE-ack) is received SCF waits for 10 seconds and
sends TCAP Abort afterwards.
Result: (i) Successful result if the PDP context is disconnected after 10 ± 2
seconds.

parameter defaultGPRSHandling=release in case an active PDP
context is aborted.

GSM Association
Part 1
SCF Service Logic
Signals to/from the left RRgprsE

Signals to/from the right _13
gprsEvent
are to/from SCF-internal GPRSEventType = pdp-ContextEstablishmentAck (12)
sub-processes.
RRgprsE + gprsEvent
CONgprs GPRSEventType = pdp-ContextChangeOfPosition (14)
Wait for ERgprs
ERgprs
CUEgprs
Start
Timer
Timer value = 10 sec
Wait for Timer

expiration
Timer
expired
TC_Abort
Idle

GSM Association
Part 1
2.3.2.5 Check correct operation of EntityReleasedGPRS procedure (Optional)

Overview:
and is connected to TestServer1. After the PDP context is established the
tester terminates the session. The operation of the CAP3 information flow
EntityReleasedGPRS is verified. If supported, the gprsSCF generates a SM in
order to inform the tester about the test result.
Message-flow:
gprsSSF(b) SCF(a)
TC_CUE{RRgprsE([PCCoP, notifyAndContinue]) + CONgprs(APN=TestServer1)}
TC_END
TC_Begin{ERELgprs(GPRScause)}
TC_CUE{ReturnResult(ERELgprs)}
TC_END

state)
WAP,ftp,WWW).
MS7(a) actively terminates the PDP context after 10 seconds.
SCF sends RRgprsE + CUEgprs
The SCF waits for ERELgprs(GPRScause).
Optional: After reception of ERELgprs(GPRScause) the SCF initiates

the transmission of a SM to MS7(a) with the following content:
“ERELgprs received. Test is passed.”
Result: (i) Successful result if gprsSSF has terminated the context by sending
EntityReleasedGPRS.

Comments: This test case confirms the correct operation of ERELgprs information
flow. ERELgprs is sent in case a CAMEL3 GPRS monitor relationship
exists and the user or SGSN disconnects the PDP context.

GSM Association
Part 1
SCF Service Logic
gp3
are to/from the SSP. _14
RRgprsE
gprsEvent
GPRSEventType = pdp-ContextChangeOfPosition (14)
RRgprsE + MonitorMode = notifyAndContinue (1)
CONgprs
Wait for
ERELgprs
ERELgprs
ReturnResult(ERELgprs)
NO YES Receiver: IDPgpr.mSISDN

SM content: "ERESgprs received. Test
Initiate SM is passed."
Idle

GSM Association
Part 1
2.3.3 Mobility Management

General
Mobility management features in CAMEL Phase 3 provide notification service from the VLR
to the IN server, based on MAP V3. Following events are used to trigger notification:
• IMSI Attach
• MS initiated IMSI detach (explicit detach)
• Location update in the same VLR service area
• Location update to another VLR service area
• Network initiated IMSI detach (implicit detach).
It is generally understood that the roaming tester is not expected to perform test requiring
change of area or wait for a network initiated IMSI detach. Nevertheless, Mobility
Management features based on physical mobility are proposed to be tested, on bilateral
understanding between HPLMN and VPLMN.
If supported by the gsmSCF, the test result will be sent to the test SIM card using a Short
Message.
Camel Phase 3 – Mobility Management service logic
Idle Following information is analysed:

- Event Met
are to/from the gsmSCF - Service Key
- IMSI/MSISDN
- LAI
- CAMEL Phase supported by the MSC/VLR
Receive "Note MM
event" message
Location update to another

IMSI Attach Analyse "event met"
VLR service area
MS initiated Location update in the

IMSI Detach same VLR service area
Send SM Send SM Send SM Send SM

("IMSI ("IMSI ("Update ("Update location
Attach: Detach: location same another VLR:test
test OK") test OK") VLR:test OK") OK")
Idle

GSM Association
Part 1
2.3.3.1 IMSI Attach, IMSI Detach and Location update in the same VLR area with
the same LAI
Overview:
MS7(a) registers in VPLMN(b). Afterwards the MS is switched off. The
presence of subscriber data (M-CSI) in the VLR is verified as well as
notification to gsmSCF due to events “IMSI Attach” and “MS initiated IMSI
detach”.
Message flow:
VLR(b) HLR(a) gsmSCF(a) SMS-C(a)
MS switched on
Updating Location Request (IMSI Attach)
InsertSubscriberData(M-CSI)
InsertSubscriberData ack
Updating Location Request accept
Note MM Event(event met=IMSI attach)
Note MM Event Ack

send SM("IMSI attach: test OK")
MS switched off
Note MM Event(event met=IMSI detach)
Note MM Event Ack

send SM("IMSI detach: test OK")

GSM Association
Part 1
Preconditions: MS7(a) contains SIM of HPLMN(a). HLR record contains M-CSI.

Action: Switch on MS7(a). Make sure MS is attached to VPLMN(b).
Switch off MS7(a).
Switch on MS7(a).
Service logic: Optional:
gsmSCF on receiving notification for IMSI Attach from VLR initiates SM
sending procedure to MS7(a)
gsmSCF on receiving notification for IMSI Detach from VLR initiates SM
sending procedure to MS7(a)
Result: Successful result if at least the following entries are included in VLR
record:
M-CSI
MobilityTriggers
Location update in the same VLR service area (0)
Location update to another VLR service area (1)
IMSI attach (2)
User initiated IMSI Detach (3)
Network initiated IMSI Detach (4)
HPLMN(a)
HPLMN(a)
At least the following SMs are received by MS7(a):

First SM with the text: ”IMSI attach: test OK”
Second SM with the text: ”IMSI detach: test OK”
including M-CSI.
Also tested are notification on IMSI Attach and IMSI Detach events.
Please note that after switching on the MS again, two SMs are received,
one for the last IMSI detach and the other for the IMSI attach.

GSM Association
Part 1
2.3.3.2 Location update by MS7(a) in the same VLR of VPLMN(b) with different
LAI (optional)
Overview:
MS7(a) registered in VPLMN(b) moves to another Location Area within the
same VLR service area, thus provoking a new update location. Notification to
SCP on update location in the same VLR service area is verified.
Message flow:
VLR(b) gsmSCF(a) SMS-C(a)
MS moves to another LA
within the same VLR
Note MM Event(event met=UpdateLocation in same

VLR service area)
Note MM Event Ack

send SM
("Location update in
the same VLR: test OK")
Preconditions: MS7(a) contains SIM of HPLMN(a) and is successfully registered in

VPLMN(b).
Tester is aware of geographical position of neighbouring Location
Areas.
Action: MS7(a) moves to another Location Area within the same VLR service
area.
- on receiving notification for Update location in the same VLR service
area from VLR the SCP initiates SM sending procedure to MS7(a).
Result: Test is passed if the MM notification Update location in the same VLR
service area is sent to the SCP. Optionally MS7(a) receives SM with
text : ”Update location in the same VLR: test OK”
Comments: Note that Mobility Management features based on physical mobility are
proposed to be tested on bilateral understanding between HPLMN and
VPLMN.

GSM Association
Part 1
Preconditions: MS7(a) contains SIM of HPLMN(a) and is successfully registered in
VPLMN(b) in VLR1(b) service area.
Tester is aware of geographical position of neighbouring MSC
coverage.
Action: MS7(a) moves to a different VLR(b) service area on VPLMN(b).
- gsmSCF on receiving notification for Update location in another VLR
service area from VLR initiates SM sending procedure to MS7(a).
Result: Test is passed if the MM notification Update location in another VLR
service area is sent to gsmSCF. Optionally MS7(a) receives SM with
text : ”Update location in another VLR: test OK”
Comments: Note that Mobility Management features based on physical mobility are
proposed to be tested on bilateral understanding between HPLMN and
VPLMN.
2.3.3.3 Location update by MS7(a) in another VLR area of VPLMN(b) (optional)
Overview:
MS7(a) registered in VPLMN(b) moves towards a new VLR service area.
Notification to gsmSCF on update location in the new VLR service area is
verified.
Message flow
VLR2(b) VLR1(b) HLR(a) gsmSCF(a) SMS-C(a)

MS moves from VLR1
to VLR2
Send Identification
Send Identification Ack
Updating Location Request
Cancel Location
Cancel Location Ack
InsertSubscriberData(M-CSI)
InsertSubscriberData ack
Updating Location Request accept
Note MM Event(event met=Update Location in another VLR)
Note MM Event Ack
send SM("Update location in

another VLR: test OK")

GSM Association
Part 1
3 Equipment Requirements
The Equipment described in this section is necessary for undertaking the test cases
described in section 2.
3.1 General
It is expected that manual selection will be used to select VPLMN(b) when using the SIM
cards supplied by HPLMN(a). To facilitate subsequent automatic selection it is required that
bits b6 and b5 of byte 2 of the SIM Service Table (Data-field 38) be set to “1”, and the
chosen VPLMN is in the PLMN Selector (Data-field 30).
In order to replicate the service that normal roamers will encounter, it is required that any SIM
used in the tests shall have one access class out of the classes 0-9 defined. No other access
class (e.g. 10 or 11-15) shall be defined.
It is recommended that on any new SIM the Location Update Status field is set to “Status not
updated” before the tests start (bit b2 set to “0” and bit b1 set to “1”, of byte 11 of Data-field
7E).
The supply of additional SIM cards may be agreed by the HPLMN(a) and VPLMN(b),
typically for the purposes of:
• Spare cards in case of failure
• Allocation from different HLRs
3.2 User Equipment for CAMEL phase 1 tests

• Two Mobile Equipment supplied by VPLMN(b)
• Two SIM cards supplied by HPLMN(a) with the following characteristics:
• HLR entry for MS1(a) contains at least:
o Provisioned Teleservices: TS11
o O-CSI
o o-BcsmTriggerDetectionPoint = collectedInfo (2)
o serviceKey: Service Key of the originating test service
o gsmSCF-Address
o defaultCallHandling = continueCall
o SS : BOICexHC : Provisioned
o SS : CFNRy : Provisioned
o HLR entry for MS2(a) contains at least:
o O-CSI
o serviceKey: Service Key of the originating test service for CAMEL
phase 1
o gsmSCF-Address
o defaultCallHandling = releaseCall
o T-CSI
o t-BcsmTriggerDetectionPoint = terminatingAttemptAuthorised (12)
o serviceKey: Service Key of the terminating test service of CAMEL
phase 1
o gsmSCF-Address
o ODB-BOICexHC : Active

GSM Association
Part 1
For the service key of the originating and the terminating test service different values have to
be chosen. These service keys have to differ from the service keys used for CAMEL phase 2
testing.
One SIM card supplied by VPLMN(b) (MS3(b)).

• Three SIM cards supplied by HPLMN(a) with the following characteristics:
o O-CSI
phase 2
o gsmSCF-Address
o camelCapabilityHandling = CAMEL phase 2 (2)
o O-BcsmCamelTDP-CriteriaList
o matchType = enabling
o destinationNumberLengthList: 4 digits (4)
o SS-CSI
o ssEventList = MultiPTY
o gsmSCF-Address
o SS : BOICexHC : Provisioned
o SS : AoCI : Provisioned
o SS : MultiPTY : Provisioned

o O-CSI
phase2
o gsmSCF-Address
o defaultCallHandling = continueCall
o T-CSI
o t-BcsmTriggerDetectionPoint = terminatingAttemptAuthorised (12)
o serviceKey: Service Key of the terminating test service
o gsmSCF-Address
o ODB-BOICexHC : Active
o SS : CFNRy : Provisioned

o O-CSI
phase2

GSM Association
Part 1
o gsmSCF-Address
For the service key of the originating and the terminating test service different values have to
be chosen. These service keys have to differ from the service keys used for CAMEL phase 1
testing.
The supply of additional SIM cards may be agreed by the HPLMN(a) and VPLMN(b),
typically for the purposes of:
• spare cards in case of failure
• allocation from different HLRs

• Two SIM cards supplied by HPLMN(a) with the following characteristics:
o Provisioned Teleservices: TS11, TS20
o subscribed APNs:
o “wild card” or
o TestAPN1 and
o TestAPN2 and
o TestAPN3 and
o TestAPN4 and
o TestAPN5 and
o TestAPN6 and
o TestAPN9 and
o TestAPN10 and
o TestServer1
o SMS-CSI
o o-TriggerDetectionPoint = SMS_collectedInfo (2)
o serviceKey: Service Key of the SMS test service logic for CAMEL
Phase 3
o gsmSCF-Address
o defaultSMSHandling = continue
o GPRS-CSI
o gprs-CamelTDPDataList
o GPRS-CamelTDPData
o gprs-TriggerDetectionPoint = pdp-ContextEstablishment
(11)
o serviceKey = equal to info provided by HPLMN(a)
o gsmSCF-Address = equal to info provided by
HPLMN(a)
o defaultSessionHandling = releaseTransaction (1)
o GPRS-CamelTDPData
o gprs-TriggerDetectionPoint = pdp-ContextChangeOfPosition
(14)
o gsmSCF-Address = equal to info provided by
HPLMN(a)

GSM Association
Part 1
o defaultSessionHandling = continueTransaction (0)
o camelCapabilityHandling = CAMEL Phase 3 (3)
o M-CSI
o MobilityTriggers
o Location update in the same VLR service area (0)
o Location update to another VLR service area (1)
o IMSI attach (2)
o User initiated IMSI Detach (3)
o Network initiated IMSI Detach (4)
o serviceKey: Service Key of the MM test service logic for CAMEL
Phase 3
o gsmSCF-Address

o Provisioned Teleservices: TS11, TS20
o Subscribed APNs:
“Wild card” or
TestAPN7 and
TestAPN8 and
TestServer1
o SMS-CSI
o o-TriggerDetectionPoint = SMS_collectedInfo (2)
o serviceKey: Service Key of the SMS test service logic for CAMEL
Phase 3
o gsmSCF-Address
o defaultSMSHandling = release
o GPRS-CSI
o gprs-CamelTDPDataList
o GPRS-CamelTDPData
o gprs-TriggerDetectionPoint = attach (1)
o gsmSCF-Address = equal to info provided by HPLMN(a)
o defaultSessionHandling = continueTransaction (0)
o GPRS-CamelTDPData
o gprs-TriggerDetectionPoint = attachChangeOfPosition (2)
o gsmSCF-Address = equal to info provided by HPLMN(a)
o defaultSessionHandling = releaseTransaction (1)
o camelCapabilityHandling = CAMEL Phase 3 (3)
The service keys used for SMS originating tests have to differ from the service keys used for
the other tests.
3.5 Test Equipment

The availability of a CCITT # 7 tester able to decode SCCP, TCAP, MAP and CAP is highly
advisable. Additionally, it is essential for any analysis of test case failures.
Clock capable of being used to allow testing personnel to record call start and chargeable
start (i.e.: answer) time of calls to an accuracy as defined in IREG PRD IR.24. If possible, the
clock shall be adjusted to be in alignment with the internal MSC clock which is used for the
Toll Ticketing function.

GSM Association
Part 1
Stopwatch capable of measuring perceived chargeable duration of calls to an accuracy as
defined in IREG PRD IR.24.

GSM Association
Part 1
4 Pre-Testing Data Exchange

It is necessary for the two PLMNs to have exchanged the Pre-Testing data defined in this
section prior to the commencement of testing.
4.1 Testing Contact Information
The following information should be exchanged by both PLMNs:
Test co-ordination contact names, telephone numbers, fax numbers and e-mail addresses.
4.2 PLMN addressing, numbering and routing data
Confirmation of the PLMN addressing numbering and routing data as referenced in the Stage
3 [IREG PRD IR23], is regarded as advisable. Such information includes:
• E212-E214 translation
• MSC/VLR and HLR E164 addresses
• MSRN number ranges
• International Signalling Point Codes (if applicable)
These data are provided by IREG PRD IR21.
Additionally, the exchange of SCP-GT ranges is regarded as advisable.

4.3 SIM associated data
The following information as stored in the SIM and/or HLR is required individually for each of
the SIM cards:
• N, PUK/(SUPER PIN).
• IMSI
• MSISDN
• Basic Service Subscription Information
• Initial Supplementary Service Configuration Information
O/T-CAMEL Subscription Information (triggerDetectionPoint, serviceKey, gsmSCF-Address
and defaultCallHandling)
4.4 Test Service associated data
The following information is required:
The destination numbers of the Test Announcements: AAC1, AAC2, AAC3, AAC4 and AAC5
The service keys used for the originating and the terminating test service for CAMEL phase 1
and 2
CAMEL phase 1 CAMEL phase 2 CAMEL phase 3

Originating test service logic ServiceKey1 ServiceKey3 ServiceKey5
Terminating test service logic ServiceKey2 ServiceKey4 ServiceKey6
SMS test service logic ServiceKey7
MM test service logic ServiceKey8
The GT of the SCP used for testing
Additionally required information for CAMEL Phase 3 tests:

SMSC Address of HPLMN
SCF-initiated SM is used to indicate the test-result if required in test-case
[Yes/No]..............

GSM Association
Part 1
Note: The Test Numbers – TestNbr1, TestNbr2, ... – are predefined numbers specified in the
Annex.
END OF SPECIFICATION

GSM Association
Part 1

GSM Association
Part 1
Appendix A
A.1 Protocol information flows and features reference list
Protocol Information flows in CAMEL (ASEs)

CAMEL phase 1 CAMEL phase 2 CAMEL phase 3
applic testcase applic testcase applic testcase

ability ability ability
1 InitialDP gsmSSF X 2.1.2 X 2.2.2. X Not
ÆgsmSCF 1 tested
2 AssistRequestInstructions gsmSRF X used X not
ÆgsmSCF tested
3 establishTemporaryConnection gsmSCFÆ X 0 X not
gsmSSF tested
4 disconnectForwardConnection gsmSCFÆ X 0 X not
gsmSSF tested
5 connectToResource gsmSCFÆ X used X not
gsmSSF tested
6 connect gsmSCFÆ X 2.1.2 X 2.2.2. X not
gsmSSF 1 tested
7 releaseCall gsmSCFÆ X 2.1.4 X 0 X not
gsmSSF tested
8 eventReportBCSM gsmSSF X 2.1.4 X 0 X not
ÆgsmSCF tested
9 requestReportBCSMEvent gsmSCFÆ X 2.1.4 X 0 X not
gsmSSF tested
10 eventNotificationCharging
11 requestNotificationChargingEv
ent
12 collectInformation
13 continue gsmSCFÆ X 2.1.5 X 0 X not
gsmSSF tested
14 initiateCallAttempt
15 resetTimer gsmSCFÆ X not X not
gsmSSF tested tested
16 furnishChargingInformation gsmSCFÆ X 0 X not
gsmSSF tested
17 applyChargingReport gsmSSF X 2.2.6 X not
ÆgsmSCF tested
18 applyCharging gsmSCFÆ X 2.2.6 X not
gsmSSF tested
19 callGap gsmSCFÆ X not
gsmSSF tested
20 serviceFilteringResponse
21 activateServiceFiltering
22 callInformationReport gsmSSF X 2.2.6 X not
ÆgsmSCF tested
23 callInformationRequest gsmSCFÆ X 2.2.6 X not
gsmSSF tested

GSM Association
Part 1
24 sendChargingInformation gsmSCFÆ X 2.2.6 X not
gsmSSF tested
25 specializedResourceReport gsmSRF – X used X not
gsmSCF tested
26 playAnnouncement gsmSCFÆ X used X not
gsmSRF tested
27 promptAndCollectUserInformat gsmSCFÆ X not X not
ion gsmSRF tested tested
28 cancel gsmSCFÆ X not X not
gsmSSF tested tested
29 activityTest gsmSCFÆ X not X not X not
gsmSSF tested tested tested
30 continueWithArgument gsmSCFÆ X not
gsmSSF tested
GPRS CAP operation
1 ApplyChargingReportGPRS gprsSSF X 2.3.2.2.
ÆgsmSCF x
2 EventReportGPRS gprsSSF X 2.3.2.2.
ÆgsmSCF 1
3 InitialDPGPRS gprsSSF X 2.3.2.2.
ÆgsmSCF 1
4 ApplyChargingGPRS gsmSCFÆ X 2.3.2.2.
gprsSSF x
5 CancelGPRS gsmSCFÆ X not
gprsSSF tested
6 ConnectGPRS gsmSCFÆ X 2.3.2.2.
gprsSSF 1
7 ContinueGPRS gsmSCFÆ X 2.3.2.2.
gprsSSF 1
8 furnishChargingInformationGPRS gsmSCFÆ X 2.3.2.2.
gprsSSF 1
9 ReleaseGPRS gsmSCFÆ X 2.3.2.2.
gprsSSF 1
10 requestReportGPRSEvent gsmSCFÆ X 2.3.2.2.
gprsSSF 1
11 resetTimerGPRS gsmSCFÆ X not
gprsSSF tested
12 activityTestGPRS gsmSCFÆ X not
gprsSSF tested
13 entityReleasedGPRS gprsSSF X 2.3.2.5
ÆgsmSCF
14 sendChargingInformationGPR gsmSCFÆ X not
S gprsSSF tested
SMS CAP operation
1 EventReportSMS gprsSSF X 2.3.1.5
ÆgsmSCF
gsmSSF
ÆgsmSCF
2 initialDPSMS gprsSSF X 2.3.1.2
ÆgsmSCF
gsmSSF
ÆgsmSCF

GSM Association
Part 1
3 ConnectSMS gsmSCFÆ X 2.3.1.2
gprsSSF
gsmSCFÆ
gsmSSF
4 ContinueSMS gsmSCFÆ X 2.3.1.5
gprsSSF
gsmSCFÆ
gsmSSF
5 FurnishChargingInformationSMS gsmSCFÆ X not
gprsSSF tested
gsmSCFÆ
gsmSSF
6 ReleaseSMS gsmSCFÆ X 2.3.1.3
gprsSSF
gsmSCFÆ
gsmSSF
7 RequestReportSMSEvent gsmSCFÆ X 2.3.1.5
gprsSSF
gsmSCFÆ
gsmSSF
8 ResetTimerSMS gsmSCFÆ X not
gprsSSF tested
gsmSCFÆ
gsmSSF
GSM MAP operation
1 AnyTimeInterrogation gsmSCFÆ HLR X used X used X not
tested
2 ProvideSubscriberInformation HLRÆ VLR X 2.1.3 X 0 X not
tested
3 Unstructured SS Request gsmSCFÆ HLR X not X not
tested tested
4 Unstructured SS Notify gsmSCFÆ HLR X not X not
tested tested
5 Process Unstructured SS Data HLRÆ gsmSCF X not X not
tested tested
6 processUnstructuredSS- HLRÆ gsmSCF X not X not
Request tested tested
7 SSinvocationNotification MSCÆ gsmSCF X 2.2.10 X not
HLRÆ gsmSCF .1 tested
(Ph3)
8 BeginSubscriberActivity HLRÆ gsmSCF X X not
tested
Mobility Management MAP
operation
1 MobilityManagementEventNotif VLRÆ gsmSCF X 2.3.3.1
ication
Control of subscription Data
1 AnyTimeSubscriptionInterrogat gsmSCFÆ HLR X not
ion tested
2 AnyTimeModification gsmSCFÆ HLR X not
tested

GSM Association
Part 1
3 NotifySubscriberDataChange HLRÆ gsmSCF X not
tested
Note: “used” means, that the information flow is used inside HPLMN(a) during execution of a
test case but is not tested across the international interface.
A.2 Overview of CAMEL phase 1 Features
CAMEL phase 1 Test case Comments

Trigger Detection 2 T-CSI triggering is only
points: tested in connection
Subscriber information O-CSI, T-CSI 2.1.2 with suppression of
Trigger criteria One CSE per CSI announcement. Further
scenarios are not
relevant in the roaming
environment as long as
optimal routing is not
supported.
Call related Detection MO: 3 MT: 3 Only arming, not
Points + Collected_Info 2.1.2, 2.1.4 encountering of EDP9
+ O_Answer 2.1.4 is tested. DPs in T-
+ O_Disconnect Not tested BCSM are not tested
+ Not tested (see comment above).
Terminating_Attempt_Aut Not tested
horised
+ T_Answer
+ T_Disconnect
Call unrelated CSE + Any time interrogation Not tested
interaction + Reporting of 2.1.3 The existence of
Geographical data location Information is
2.1.3 tested.
+ Reporting of Subscriber Reporting of Subscriber
state (idle, busy, Nreach) state is tested
exemplary for
camelBusy.
Call related CSE + Call Set-up 2.1.2
interaction + Suppression of 2.1.7
Announcements and
tones for MT calls 2.1.2
+Support of 2.1.3 See comment above
CalledPartyBCD number
+Geographical data
Charging Features +Call reference number 2.1.2
Interworking with other + Support of CLIP for Not tested
GSM services SPNP

GSM Association
Part 1
A.3 Overview of CAMEL phase 2 Features

Trigger Detection 2
points:
Subscriber information +U-CSI, UG-CSI Not tested
+SS-CSI 2.2.10.1
+TIF-CSI not tested
Trigger criteria +Trigger criteria MO 0, 2.2.10.2 Trigger on length of dialled
(dialled number, basic MT not number is tested
service group, call tested Trigger criteria for MTC are
forwarded) and MT not relevant in the roaming
(Basic service group) environment as long as
optimal routing is not
supported
Call related Detection MO: 7 MT: 6
Points +Calling party abandon Not tested
+no answer 2.2.5.1
+busy.not reachable 2.2.5.3
+busy.busy 2.2.5.2
+routeSelectFailure 0
Call unrelated - Not tested
Detection Points
Specialized Resources + some Assist 0 CAP-ETC and CAP-CTR
procedures: Access to tested
SRFs on another entity
(e.g. in HPLMN), Access
to facilities on another
SSP
+ support of Special Used / not CAP-Cancel, CAP-
Resource Function: tested ResetTimer, CAP-
Announcement insertion PromptAndCollectUserInfo:
and in-band audio signal not tested
injection, optionally via CAP-ConnectToResource,
another SSP, HPLMN CAP-PlayAnnouncement and
controlled CAP-
announcements SpecializedResourceReport:
used
Fraud control + SS Invocation 2.2.10.1 MPTY notification tested
notification (MPTY, ECT,
CD): Monitoring of
subscriber initiation.
Call unrelated CSE + Support of USSD Not tested Not in scope of this test
interaction communication between specification
MS and gsmSCF. Not tested
+Cell Id in geographical
data: Gives VLR the
option to return a stored
cell ID in response to a
request for location
information.

GSM Association
Part 1
Call related CSE + Follow-on call 0

interaction + Support of alerting Not tested
categories downloaded
from SCF: SSF relays
the alerting pattern from
the CSE to the HLR
Charging Features + Support of online 2.2.6 CAP-SCI tested

charging using AoC for
Mobile originated calls. 0 CAP-FCI tested
+ Inclusion of free format
information received
from the CSE into 2.2.6 CAP-CIReq/-CIRep tested
CAMEL specific
charging records. 2.2.6 CAP-AC/-ACR tested
+ Support of additional
call related information
sent to the gsmSCF
+ Application of charge 0 CAP-IDP parameter tested
limits by downloading of
maximum call duration
timers, tariff switch
timers to MSC. Playing
of tone 30s before call
duration expiry.
Provision of precise
timestamps and
timezone information.
Interworking with other + Support for forwarded- Not tested Not in scope of this test
GSM services to-numbers in SPNP or specification
other short number
format by CAMEL
supporting VLRs. (TIF-
CSI)
CAMEL capability + VLR indication of 2.2.1
handling supported CAMEL
capability

GSM Association
Part 1
A.4 Overview of CAMEL phase 3 Features (in addition to CAMEL phase 2)

Trigger Detection +4,12,13,14
points:
Subscriber +GPRS-CSI, 2.3.2.1
information +SMS-CSI 2.3.1.1
+M-SCI, 2.3.3.1
+D-CSI, N-CSI Not tested Subscribed dialled Services

+VT-CSI Not tested CSI & Network dialled
Services CSI
Fraud control + SS Invocation notification Not tested
enhancement for CCBS
CSE Control of + control of Subscription Not tested Not tested because the
subscription data data at HLR: related operations are
- CF-SS, CB-SS, ODB assumed to be used by a
SS data; CSI-data HPLMN internal interface
CSE Notification of + notification of change of Not tested
change of subscription data
subscription data - CF-SS, CB-SS, ODB SS data;
CSI-data
Support of GPRS + GPRS attach trigger 2.3.2.3.12.

(terminal initiated) + PDP context 3.2.2.1
establishment and PDP
context establishment
acknowledgement triggers Used
+ Change of position Not tested
trigger 2.3.2.2.1
+ Change of QoS, Position 2.3.2.3.1
EventReport 2.3.2.2.1
+ Time & Volume based Not tested CAMEL support is there, but
Charging per PDP AoC for GPRS is not
+ Time based Charging 2.3.2.3.22. currently defined
per session 3.2.4.x
+ Inclusion of FreeFormat
data in CDR
+ Support of AoC for
GPRS
+ GPRS default handling

Support of SMS_MO + Control of SMS-MO 2.3.1.x.y
(CS/PS) Not tested
+ SMS Charging
operations incl. Free-
format data in CDR
Enhancements to + CUE with argument Not tested
circuit switched call + AoC for MT Not tested
control + DPs in VMSC, V_T-CSI Not tested
+ Support of Localised Not tested
Service Area Not tested

GSM Association
Part 1
+ Support of Optimal Not tested
Routing Not tested
+ DP in VMSC Not tested
+ Control of invocation of
Supplementary Services
(using SII2 parameter)
Support of Mobility Mobility management 2.3.3.x
Management event notifications (CS/PS)
7. + Location
area
update/MS
Attach
+
MS/network-
initiated
detach
+ Routeing
area update
/MS Attach
Dialled service + Network dialled Service Not tested
triggers Triggers
+ Subscribed dialled
Service Triggers
CSE Load Control + Call Gapping (HPLMN Not tested
only)

GSM Association
Part 1
A.5 Test Announcements

The structure of the test announcements is detailed below:
• Start announcement after traffic channel is connected (ISUP-
ANM(charge))
• After one second send two DTMF tones (announcement ratio for
automatic testing)
• Start spoken text in English language
• Repeat text (see table below)
• Disconnect call (ISUP-REL(Cause: normalCallClearing))
Ann. DTMF
Text of announcement Duration Dialled in test case
Number tones
1 01 “Test is passed” Repeat for at least 2.1.6.1
two times
2 02 “Test is failed” Repeat for at least 2.1.6.2, 2.2.8.2
two times
3 03 “Test is proceeding” Repeat for a 2.1.8.1 (CF-Number)
minimum duration
of 1 minute
4 04 “Test is passed” Repeat for at least 2.2.2.2
two times
5 05 “Test is proceeding. The Repeat for a -- (Not dialled)
announcement will be duration of exactly
disconnected after 30 30 seconds
seconds.”
A.6 Test Numbers

Name Digits Used in test case
TestNbr1 5001*456#789 2.1.2
TestNbr2 5002 2.1.4
TestNbr3 0503 2.1.8.2, 2.1.8.3
TestNbr4 5004 2.2.2.1
TestNbr5 5005 2.2.6.1
TestNbr6 5006 0
TestNbr7 5007 2.2.6.2
TestNbr8 0508 0
TestNbr9 0509 2.2.10.3, 2.2.10.4
TestNbr10 5010 0
TestNbr11 5011*456#789 0
TestNbr12 5012 2.2.10.1
TestNbr13 5013 2.2.10.1
TestNbr14 5014 2.3.1.2
TestNbr15 5015 2.3.1.2
TestNbr16 5016 2.3.1.6

GSM Association
Part 1
A.7 Test APNs

Name APN Used in test case
TestAPN1 ireg.test-APN.1 2.3.2.2.1
TestAPN9 ireg.test-APN.9 2.3.2.5
End of Appendix A

GSM Association Ir32 - pt1

Uploaded by

Copyright:

Available Formats

GSM Association Ir32 - pt1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

GSM Association Ir32 - pt1

Uploaded by

Copyright:

Available Formats

GSM Association

Official Document: IR.32 UNRESTRICTED

End-to-End Functional Capability Specification for

Security Classification Category (see next page):

UNRESTRICTED Version 3.3.3 Page 1 of 165

Security Classification: Unrestricted

Version Date Brief Description

"Customised Applications for Mobile network Enhanced

UNRESTRICTED Version 3.3.3 Page 2 of 165

GSM CAMEL CAMEL

“Customised Applications for Mobile network Enhanced

UNRESTRICTED Version 3.3.3 Page 3 of 165

UNRESTRICTED Version 3.3.3 Page 4 of 165

UNRESTRICTED Version 3.3.3 Page 5 of 165

This document does not cover:

UNRESTRICTED Version 3.3.3 Page 6 of 165

CAMEL Customised Applications for Mobile networks using Enhanced Logic

DFC CAP-Disconnect Forward Connection

EDP Event Detection Point

FCI CAP-Furnish Charging Info

GMSC Gateway Mobile Services Switching Centre

HLR Home Location Register

IAM ISUP-Initial Address Message

NDC Network Destination Code

O-CSI Originating CAMEL Subscription Information

UNRESTRICTED Version 3.3.3 Page 7 of 165

SCF Service Control Function

TAP Transferred Account Procedure

UNRESTRICTED Version 3.3.3 Page 8 of 165

1.3 Objective of tests

The specific objectives:

Specific objectives for CAMEL Phase 2

The following topics are not tested:

UNRESTRICTED Version 3.3.3 Page 9 of 165

Topics related to CAMEL Phase 1

Topics related to CAMEL Phase 2

Topics related to CAMEL Phase 3: Circuit Switched Call Control

Topics related to CAMEL Phase 3: MO SMS control

UNRESTRICTED Version 3.3.3 Page 10 of 165

Topics related to CAMEL Phase 3: GPRS control

Topics related to CAMEL Phase 3: general

1.4 Strategy for Testing

UNRESTRICTED Version 3.3.3 Page 11 of 165

Within CAMEL Ph3 SMS Control the combination of SMSC address,

The test programme consists of three distinct components:

1.5 Service logic

UNRESTRICTED Version 3.3.3 Page 12 of 165

The following shows the entries in the destination list:

Originating Service Terminating Originating Service Terminating

UNRESTRICTED Version 3.3.3 Page 13 of 165

UNRESTRICTED Version 3.3.3 Page 14 of 165

1.6 Prerequisites for testing

• Basic Roaming capability with several PLMNs, as specified in PRD IR24.

UNRESTRICTED Version 3.3.3 Page 15 of 165

The description of the test cases are built up as detailed below:

Figure 2: Test case Configuration

UNRESTRICTED Version 3.3.3 Page 16 of 165

2.1 Camel Phase 1

calledPartyBCDNumber consists of CC + NDC of country(a)