GSM Association Official Document TD.

41

Confidential Confidential

Testing the Transferred Account Procedure 4.1 15 December 2011

This is a Binding Permanent Reference Document of the GSMA

Security Classification: This document contains GSMA Confidential Information

Access to and distribution of this document is restricted to the persons listed under the heading Security Classification Category. This document is confidential to the Association and is subject to copyright protection. This document is to be used only for the purposes for which it has been supplied and information contained in it must not be disclosed or in any other way made available, in whole or in part, to persons other than those listed under Security Classification Category without the prior written approval of the Association. 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.

Security Classification CONFIDENTIAL GSMA Material

Confidential Confidential Confidential Confidential GSMA Full Members GSMA Associate Members GSMA Rapporteur Members GSMA Parent Company Members

Can be distributed to:

X X X X

Copyright Notice
Copyright 2012 GSM Association

Antitrust Notice
The information contain herein is in full compliance with the GSM Associations antitrust compliance policy.

V4.1

Page 1 of 22

GSM Association Official Document TD.41

Confidential Confidential

Table of Contents
1Introduction 3 1.1Overview ......................................................................................................................3 1.2Structure of the Document...........................................................................................3 1.3Scope of Testing the TAP............................................................................................3 1.4Changes Forecast........................................................................................................4 1.5The TAP Testing Toolkit (TTT)....................................................................................4 1.6Definition of Terms.......................................................................................................4 1.7Document Cross-References.......................................................................................4 2Identifying the General Framework to Test the TAP 5 2.1The Bilateral Roaming Model.......................................................................................5 2.2The Roaming Hubbing Model......................................................................................6 2.3Testing the TAP in a Roaming Hubbing Scenario.......................................................8 2.3.1Connecting a new PMN: the first intra-hub connection 8 2.3.2Implementing additional intra-hub connections 9 2.3.3Connecting two Roaming Hubs: the first inter-hub connection 9 2.3.4Implementing additional inter-hub connections 10 2.3.5Inter-hub connections-one Roaming Hub not in the TAP/RAP Flow 10 2.3.6Inter-hub connections-both Roaming Hubs not in the TAP/RAP Flow 10 2.4The VPMNs TAP Test Environment and TAP Test Files.........................................11 2.5Defining a TAP Testing Strategy...............................................................................11 3Different Scenarios to Test the TAP 12 3.1The Implementation of a new Roaming Agreement..................................................12 3.2The Implementation of a new TAP Release..............................................................12 3.3The Introduction of additional Services ....................................................................13 4TAP Test Cases (TTC) 13 4.1Generating Roaming Traffic Test Data in the VPMNs Environment........................13 4.2Organisation of the TAP Test Cases.........................................................................14 4.3Structure of the TADIG PRDs defining the TAP Test Cases....................................14 5Optimising the TAP Test Activities: the Cloning Procedure 15 6TAP Testing Process 15 6.1Process Definition......................................................................................................15 6.2Success Criteria.........................................................................................................16 6.3 Supporting the TAP Testing Process by means of the TTT.....................................17 7TAP Testing Procedures 18 7.1TAP Test Procedure for the Implementation of a new Roaming Agreement............18 7.2TAP Test Procedure for the Implementation of a new TAP Release........................18 7.3TAP Test Procedure for the Introduction of additional Services ..............................19 8Administrative Documents used during Testing the TAP 19 8.1 TAP Testing Completion Certificate..........................................................................20 Document Management 22 Document History............................................................................................................22 Other Information............................................................................................................22

V4.1

Page 2 of 22

GSM Association Official Document TD.41

Confidential Confidential

1 Introduction
1.1 Overview
This document is concerned with the definition of the Testing Process and the related Testing Procedure to be executed by any two Testing Partners willing to exchange roaming traffic data by means of the Transferred Account Procedure (TAP) in accordance with the applicable roaming agreement and the related business model, including Roaming Hubbing scenarios. This documents refers to the Testing Partners as TAP Sender and TAP Recipient (for example the VPMN and the HPMN in a bilateral roaming scenario), in accordance to their role in the TAP exchange process. Note: Each Party could use the services of a Service Provider (for example a Data Clearing House) to conduct the required tests on their behalf. Should this be the case, the Service Provider must be considered as part of the environment of that specific Testing Party.

1.2 Structure of the Document

The document is divided into seven sections, the purpose of each being as follows. Section
1 2

Title
Introduction Identifying the general framework to test the TAP Different Scenarios to test the TAP The TAP Test Cases (TTC) Optimising the TAP Test Activities: the Cloning Procedure The TAP Testing Process The TAP Testing Procedures Administrative Documents

Description
It places the document in context and explains the purpose of each section of the document. This section identifies the general framework to test the TAP by analysing the Roaming Environment of the TAP Sender and defines the testing strategy. This section defines the different scenarios to test/retest the TAP. This section defines the TAP Test Cases to be used in the TAP Testing Process, as applicable. This section describes how the use of the Cloning Procedure can optimise TAP Test Activities. The section defines the TAP Testing Process and the related Success Criteria. This section describes the procedural steps of the TAP Testing Procedures. The section contains the administrative documents that are recommended during the execution of the procedural steps.

3 4 5 6 7 8

1.3 Scope of Testing the TAP

The scope of testing the TAP is to demonstrate the ability of the TAP Sender (for example the VPMN), to make call event details available in syntactically correct TAP Files in accordance with the standards defined by TADIG and applicable to the Roaming Scenario implied by the Roaming Agreement in place between the Testing Parties. Note: Testing the validation carried out by the TAP Recipient (for example the HPMN), including any type of revenue assurance tests (e.g. IOT Checking, Inter-PMNs Invoice Production, etc.) is out of the scope of the TAP Testing. It is expected that the Roaming Partners test their own applications/processes internally. Neither is any longer there a requirement for the definition of a procedure to test the File Transfer Method (i.e. Data Interchange Testing) chosen by the Roaming Partners in order to exchange TAP Files. The TAP Sender is responsible to implement and operate the

V4.1

Page 3 of 22

GSM Association Official Document TD.41

Confidential Confidential

applicable File Transfer Method in accordance with TADIG standards and the Roaming Agreement in place between the Roaming Partners. This is mainly due to the following reasons: The number of possible transfer methods and related options makes the definition of a detailed testing procedure impractical; An initial successful test of the chosen transfer method will not grant the smooth operation of the TAP File Exchange activities. This can only be achieved by means of IT Operation & Maintenance procedures (e.g. links monitoring, alarms management, troubleshooting, etc.); Evidence is given in the GSM Industry that over 90% of the live TAP Files are exchanged on the TAP Public Interface between the Roaming Partners by using the infrastructures of Data Clearing Houses, in their quality of Agents of the Roaming Partners as applicable. Any testing requirements on per Roaming Relationship basis would therefore imply the re-testing of a well-established activity in almost 90% of the cases. As a consequence, this document is focused only on Data Format Testing.

1.4 Changes Forecast

In accordance with the TAP Release Management Process defined by TADIG, the TAP Testing Process, the related TAP Testing Procedures and the applicable TAP Test Cases will be only maintained against two TAP releases: The current TAP Release to be used on the TAP Public Interface between the Roaming Partners as defined by TADIG standards; The forthcoming TAP Release to be used on the TAP Public Interface between the Roaming Partners as defined by TADIG standards. With reference to testing, TAP Releases older than the current one will not be any longer maintained (i.e. backwards compatibility with this document and other related ones will not be granted).

1.5 The TAP Testing Toolkit (TTT)

The TTT is a user-friendly interactive windows application developed and continuously maintained by the GSM Association to support the execution of the applicable TAP and RAP Testing Procedures as defined in the relevant TADIG PRDs. The TTT should make TAP and RAP Testing easier, more efficient and cost effective. For further information about the TTT, please contact directly the GSM Association Headquarters or visit the TTT page on the GSM Infocentre.

1.6 Definition of Terms

Term
RAP TAP TTT

Description
Returned Account Procedure Transferred Account Procedure TAP Testing Toolkit

1.7 Document Cross-References

Ref
1 2 3 4 5

Document Number
GSMA PRD TD.32 GSMA PRD TD.42 GSMA PRD TD.43 GSMA PRD TD.44 GSMA PRD TD.45

Title
Rejects and Returns Process Testing the Returned Account Procedure (RAP) TAP Test Cases (TTC) for GSM Phase 1 Services TAP Test Cases (TTC) for GSM Phase 2 Supplementary Services TAP Test Cases (TTC) for GSM Phase 1 Fax and Data Services

V4.1

Page 4 of 22

GSM Association Official Document TD.41

Confidential Confidential

Ref
6 7 8 9

Document Number
GSMA PRD TD.46 GSMA PRD TD.47 GSMA PRD TD.57 GSMA PRD TD.92

Title
TAP Test Cases (TTC) for CAMEL Phase 1 and Phase 2 Services TAP Test Cases (TTC) for GPRS Services TAP3 Format Specification Roaming Hubbing TAP, RAP and NRTRDE Flow

2 Identifying the General Framework to Test the TAP

This section identifies the general framework to test the TAP and defines the testing strategy by analysing the possible Roaming Models.

2.1 The Bilateral Roaming Model

The bilateral roaming model requires a single TAP/RAP interface between the VPMN (TAP Sender) and the HPMN (TAP Recipient). The functional blocks of the VPMNs Roaming Environment and the related interfaces are described hereafter:

Figure 2-1: VPMNs Roaming Environment

where: The Visited Network consists of all required network infrastructures (e.g. MSCs, VLRs, etc.) where HPMNs Customers can request and obtain the applicable services in accordance with the Roaming Agreement between the Roaming Partners. The usage of such services is recorded and made available (i.e. Roaming Traffic Data) to the VPMNs TAP/RAP Environment by means of specific interfaces and procedures that are VPMN specific. Note that the definition of the network End-to-end Functional Capability Testing Procedures is out of the scope of this document as such procedures are defined by other GSM Association PRDs (i.e. IREG PRDs). The VPMNs TAP/RAP Environment is the macro functional block within the VPMN that is meant to process the incoming Roaming Traffic Data and to produce the outgoing TAP Files, as appropriate. It is also meant to operate the TAP and RAP Procedures in accordance with the relevant TADIG PRDs and the Roaming Agreement between the Roaming Partners. Note that the internal organisation in terms of functional blocks within such environment is VPMN specific. Therefore, the structure shown above is only an example, derived from the most common implementation in the GSM Industry. It consists of: A VPMNs Billing System functional block, where the incoming Roaming Traffic Data are processed (e.g. checked, grouped, rated, formatted, etc.) and subsequently forwarded to the next functional block by means of a private interface. Note that this private interface may also be used to exchange data related to the RAP.

V4.1

Page 5 of 22

GSM Association Official Document TD.41

Confidential Confidential

A Data Clearing House functional block, where the TAP and RAP Procedures are operated (e.g. TAP Files creation/conversion, TAP File transfer, etc.) via the TAP and RAP Public Interfaces between the VPMNs TAP/RAP Environment and the respective HPMNs one, in accordance with TADIG standards and the Roaming Agreement between the Roaming Partners.

With reference to the private interface between these two functional blocks and depending on the VPMNs specific policy, this could be the interface between two VPMNs systems, or the interface between the VPMN and a third Party (a real Data Clearing House) who acts as an Agent on behalf of the VPMN, or could even not exist at all. Furthermore, should the VPMN decide to make use of the services of a Data Clearing House, the level of outsourcing in terms of activities is a matter of the Service Agreement between the VPMN and the Agent. Finally, it should be noted that all testing matters related to the RAP are dealt by another TADIG PRD (i.e. TD.42) and therefore are out of the scope of this document. The HPMNs TAP/RAP Environment macro functional block within the HPMN that is meant to receive and process the incoming TAP Files and to operate the RAP Procedure in accordance with the relevant TADIG PRDs and the Roaming Agreement between the Roaming Partners. Note that the same considerations given above for the equivalent VPMNs macro functional block could be extended to this one, as applicable.

2.2 The Roaming Hubbing Model

The general scenario where the Roaming Hubs are part of the TAP/RAP Flow can be summarised as follows:
VPMN X-4

VPMN Y-1 Roaming Hub Y VPMN Y-2 Roaming Hub X

HPMN X-1

HPMN X-2

VPMN Z-1 Roaming Hub Z VPMN Z-2 TAP/RA P Public Interfac e

Figure 2-2: Roaming Hubs as part of the TAP/RAP Flow

Note that for each VPMN-HPMN connection, there are up to three TAP/RAP public interfaces involved. The number TAP/RAP public interfaces may be reduced to two in case

V4.1

Page 6 of 22

GSM Association Official Document TD.41

Confidential Confidential

a single Roaming Hub is involved in the VPMN-HPMN connection (as for example in the connection VPMN X-4 HPMN X-1 above). Like in the bilateral roaming model, each of these TAP/RAP public interfaces clearly identifies the TAP Sender and the TAP Recipient by means of specific TADIG codes, whose combination is used only on a particular TAP/RAP public interface. In the TAP/RAP public interface between the VPMN and the Roaming Hub, the VPMN (TAP Sender) will provide the Roaming Hub (TAP Recipient) with all TAP Files required by the VPMN-HPMN connections implemented by the VPMN through that Roaming Hub.

Figure 2-3: VPMN-Roaming Hub TAP/RAP Interface

Note: The same TAP interface is used for all connections implemented by the VPMN through that Roaming Hub and should therefore be tested only once. It should also be noted that when a Roaming Hub plays the role of the TAP Recipient, from a functional point of view its TAP/RAP Environment is identical to the one of an HPMN. In the TAP/RAP public interface between the Roaming Hub and the HPMN, the Roaming Hub plays the TAP Sender Role and its Roaming Environment can be summarised as follows:

Figure 2-4: VPMNs Roaming Environment (Roaming Hub)

V4.1

Page 7 of 22

GSM Association Official Document TD.41

Confidential Confidential

where: Opposite to the previous figure, the functional blocks (i.e. VPMNs Roaming Environment 1, N) where the HPMNs Customers are roaming, are now representing PMNs (or even other Roaming Hubs) and have to be considered as fully integrated within the VPMNs Roaming Environment of the Roaming Hub. Note that the interfaces between these functional blocks and the Roaming Hub TAP/RAP Environment macro functional block must be in accordance with the standard TAP and RAP Procedures defined by TADIG and the Roaming Agreements between the Roaming Hub and the various VPMNs (and/or other Roaming Hubs). The Roaming Hubs TAP/RAP Environment is equivalent from a functional point of view to the VPMNs TAP/RAP Environment shown in the previous section: therefore, the same considerations apply. The only differences are the additional Data Clearing House functional blocks interfaced with the various VPMNs Roaming Environment ones. This has been done for the sake of clearness, as the interfaces are now according to the TAP and RAP Procedures, rather than generic ones. As a consequence of the above considerations, it becomes evident that the TAP/RAP Environment of a Roaming Hub, when playing both roles of TAP Sender and TAP Recipient as applicable, is equivalent to the TAP/RAP Environment of a PMN. Therefore, the same TAP Testing Process and Procedures should apply when testing the TAP with a Roaming Hub. The efficiency gain when testing the TAP in a Roaming Hubbing scenario consists of the significant reduction in terms of public TAP interfaces to be tested compared to the equivalent bilateral roaming scenario when implementing the same number of VPMNHPMN connections, as the same TAP interface is used to support all the connections to be implemented between the testing parties (VPMN-Hub-HPMN or Hub-Hub) and therefore can be tested only once. Note: For other Roaming Hubbing scenarios, where no Roaming Hubs are in the TAP/RAP Flow, the TAP Testing environment is exactly the same as the one defined for the Bilateral Roaming Model.

2.3 Testing the TAP in a Roaming Hubbing Scenario

2.3.1 Connecting a new PMN: the first intra-hub connection When a new PMN connects to a Roaming Hub that is in the TAP/RAP Flow, the public TAP interface between the Roaming Hub and the new PMN must be tested. This can be achieved by executing the end-to-end testing of the first roaming connection between the new PMN and one of the selected PMNs already connected to the Roaming Hub.
Existing RH X Environment

PMN X-1 PMN X-2 PMN X-3 Roaming Hub X

TAP Interface under test

New PMN X-4

V4.1

Page 8 of 22

GSM Association

Confidential

Confidential Official Document TD.41 Figure 2-5: Public TAP Interface between the Roaming Hub and the new PMN

Note: Although there are two TAP interfaces involved in the end-to-end transfer of the roaming traffic, only the TAP interface between the new PMN and the Roaming Hub needs to be tested, as the other one has been already tested and certified. For example, the roaming connection between X-4 and X-2 can be used. 2.3.2 Implementing additional intra-hub connections The implementation of additional connections to other selected PMNs already connected to the Roaming Hub does not require in principle to test any additional TAP interface, as all the existing TAP interfaces have been already tested at least once. This represents a significant efficiency gain in terms of required implementation efforts. However, the connected PMNs shall have the right to request the Roaming Hub the execution of specific end-to-end TAP test scenarios with selected VPMNs, for example to test specific services when supported on both networks. For example, the roaming connection between X-4 and X-1 can be tested.
Existing RH X Environment

VPMN X-1 VPMN X-2 VPMN X-3 Roaming Hub X

TAP Interface under test

HPMN X-4

Figure 2-6: Execution of specific end-to-end TAP test scenarios with a selected VPMN

2.3.3 Connecting two Roaming Hubs: the first inter-hub connection When two Roaming Hubs that are in the TAP/RAP Flow interconnect, the public TAP interface between these Roaming Hubs must be tested. This can be achieved by executing the end-to-end testing of the first roaming connection between one selected PMN of the first Roaming Hub and one of the corresponding selected PMNs of the second Roaming Hub.

V4.1

Page 9 of 22

GSM Association Official Document TD.41

Confidential
Existing RH Y Environment

Confidential

Existing RH X Environment

PMN X-1 Roaming PMN X-2 PMN X-3 Roaming Hub X Hub Y

New PMN Y-1 New PMN Y-2 New PMN Y-3

TAP Interface under test

2.3.4 Implementing additional inter-hub connections The implementation of additional inter-hub connections between selected PMNs already connected to the Roaming Hub does not require in principle to test any additional TAP interface, as all the existing TAP interfaces have been already tested at least once. However, the PMNs connected to one of the Roaming Hubs, as well as the Roaming Hubs themselves, shall have the right to request the connected Party the execution of specific end-to-end TAP test scenarios with selected VPMNs connected to the other Roaming Hub. 2.3.5 Inter-hub connections-one Roaming Hub not in the TAP/RAP Flow From a TAP testing point of view, this scenario is equivalent to the first intra-hub connection described above. The same consideration can be applied here.
Existing RH X Environment TAP Interface under test

PMN X-1 PMN X-2 PMN X-3 Roaming Hub X

PMN Y-1 Roaming Hub Y

Figure 2-7: Inter-hub connection where one Roaming Hub is not in the TAP/RAP Flow

2.3.6 Inter-hub connections-both Roaming Hubs not in the TAP/RAP Flow From a TAP testing point of view, this scenario is equivalent to the bilateral roaming scenario described above. The same consideration can be applied here.

V4.1

Page 10 of 22

GSM Association Official Document TD.41

TAP Interface under test

Confidential Confidential

PMN X-2 Roaming Roaming Hub X Hub Y PMN Y-1

Figure 2-8: Inter-hub connection where both Roaming Hubs are not in the TAP/RAP Flow

2.4 The VPMNs TAP Test Environment and TAP Test Files
The VPMNs TAP Test Environment of the Roaming Partner under test to be used is clearly the VPMNs TAP/RAP Environment described in the bilateral roaming scenario or in the roaming hubbing scenario, as applicable. The VPMNs TAP Test Files to be considered for testing purpose are only the ones exchanged on the TAP Public Interface under test between the involved Parties (i.e. regardless possible Data Record Format Conversions performed within the VPMNs and/or HPMNs TAP/RAP Environments, if any).

2.5 Defining a TAP Testing Strategy

For the definition of a TAP Testing Strategy, it is important to consider the time and the operational effort required to perform any testing activities. Accordingly, the TAP Testing Process and the related Procedures should be defined in order to optimise the highest possible quality level against the minimum reasonable effort to obtain it. Having this in mind, the following considerations can be done: Due to the large number of Roaming Relationships in place in the GSM Industry, the number of scenarios to test/retest the TAP should be reduced to the minimum. The capacity to generate Roaming Traffic Test Data is a prerequisite for the generation of TAP Test Files in the VPMNs TAP Test Environment, when applicable. Possible synergies with other testing processes (i.e. network end-to-end functional tests) have to be considered. Due to the complexity of the Data Record Format of TAP Files, the definition of a complete set of TAP Test Cases that can cover all possible combinations of detailed items and related values is impractical or even impossible. Moreover, specific validation rules, mainly those defined on the value of detailed items (e.g. call too old), are irrelevant from a testing point of view and should not be considered for the successful completion of the TAP Testing Process. This should not be a problem, as during live operation of the TAP other processes are meant to cater for error conditions and to return erroneous data to the VPMN, according to the Returned Account Procedure defined by TADIG. Each Party, in its quality of VPMN, has the responsibility to provide the Roaming Partner with TAP Test Files that are syntactically equivalent to the TAP Files exchanged during live operations. Each Party, in its quality of VPMN, should also provide the Roaming Partner with a TAP Test Report. This report shall identify the relevant testing parameters (e.g. used IMSI and MSISDN numbers) as well as the list of TAP Test Cases that have been executed and therefore the submitted TAP Test File refers to. This will minimise the

V4.1

Page 11 of 22

GSM Association Official Document TD.41

Confidential Confidential

efforts spent by the Roaming Partners during the verification of the incoming TAP Test File. Each Party, in its quality of VPMN, should inform the Roaming Partner about any deviation from TAP standards in advance. This will minimise the request for clarifications and therefore the time and effort spent during execution of the TAP Testing Procedure. Each Party, in its quality of HPMN, should verify that the incoming TAP Test File is syntactically correct in accordance with the TADIG standards and the Roaming Agreement between the Roaming Partners. As the HPMN could make use of a more relaxed set of validation rules than the standard ones, rather than the use of specific data item is subject to an agreement between the Roaming Partners, it is important that this activity is reflected in the TAP Testing Process. In principle, the VPMNs TAP Test Environment should actually be independent from the specific Roaming Scenario (i.e. the specific Roaming Partner in its quality of HPMN). In other words, when one TAP File produced by this environment generates syntactical errors against the applicable validation rules (e.g. missing mandatory items), all TAP Files produced by the same environment will be affected by the same syntactical errors. According to this statement, the Cloning Procedure defined hereafter can optimise the required testing activities, when applicable.

These considerations have been used as general requirements for the definition of all matters related to Testing the TAP.

3 Different Scenarios to Test the TAP

Ideally speaking, the TAP should be tested/re-tested upon any possible changes to the VPMNs TAP/RAP Environment that may affect the TAP Data Record Format used on the TAP Public Interface. This is impractical and therefore the scenarios to test/retest the TAP are limited to the following ones: The implementation of a new Roaming Agreement The implementation of a new TAP Release The Introduction of additional Services (when supported by the VPMNs TAP/RAP Environment) Furthermore, the Roaming Partners can decide on a bilateral basis to re-test the TAP in other scenarios, as required.

3.1 The Implementation of a new Roaming Agreement

In the Bilateral Roaming Model, this scenario applies when a Roaming Agreement is signed by the Roaming Partners, thus originating a new Roaming Relationship between each other. Both Roaming Partners, in their quality of VPMN and HPMN respectively, should then execute the applicable TAP Testing Procedure (i.e. the TAP Testing Procedure is executed twice). In the Roaming Hubbing Model, this scenario applies when a Roaming Hubbing Agreement with specific options (Roaming Hubbing presence in the TAP/RAP Flow) is signed by a PMN and the Roaming Hub, thus originating a new Roaming Relationship between the parties. Accordingly, the same considerations given above for the Bilateral Roaming Scenario can apply here to test the new TAP/RAP interface between the two parties.

3.2 The Implementation of a new TAP Release

The TAP Release Management Process defined by TADIG identifies the maximum number of new TAP Releases per year. It is recommended to re-test the TAP in case of implementing a new TAP Release.

V4.1

Page 12 of 22

GSM Association Official Document TD.41

Confidential Confidential

It should be noted that this scenario theoretically implies the execution of the TAP Process by each Party and all its Roaming Partners, in their quality of TAP Sender and TAP Recipient respectively (for example, in the bilateral roaming model: Number of executions of the TAP Testing Procedure = Number of existing Roaming Relationships x 2). As the number of executions can be quite relevant, this is the scenario where the Cloning Procedure can optimise the required testing activities. The Operator moving to the new TAP Release shall perform a scenario for the following basic tests where the services are supported: Chargeable MOC Voice & Data MTC Call forwarding scenario SMS MO & MT CAMEL (where the destination number has been changed) GPRS (packet switched data) WLAN Voice over LTE (originated and terminated) SMS over LTE (originated and terminated) These tests are performed for Quality Assurance purposes on Outbound Files. It is then necessary to perform these tests with one or two chosen Roaming Partners and where required your Data Clearing House.

3.3 The Introduction of additional Services

This scenario applies when a Roaming Partner, in its quality of VPMN, is going to introduce additional services in its VPMNs Roaming Environment that are already supported by its TAP/RAP Environment (e.g. Introduction of CAMEL Services, GPRS Services, etc.) but have not been tested before. Note: In terms of number of test executions, the considerations given in the previous scenario can be extended to this one.

4 TAP Test Cases (TTC)

4.1 Generating Roaming Traffic Test Data in the VPMNs Environment
The capacity to generate Roaming Traffic Test Data in the VPMNs Roaming Environment is a prerequisite for the creation of TAP Test Files in the VPMNs TAP Test Environment (when the Roaming Partner under test is not making use of the Cloning Procedure defined hereafter, as applicable). This can be achieved through the execution of specific test cases in the VPMNs Roaming Environment. Furthermore, these Roaming Traffic Test Data shall be supported by the description of each executed test case, including the used test data (e.g. IMSI numbers, called numbers, dates and timestamps, location information, etc.). A significant number of test cases have already been specified by IREG (including the related test reports) in the relevant IREG PRDs that define the End-to-end Functional Capability Tests Specification (commonly known as IREG Tests) for each GSM Service Group. In order to use existing synergies between TAP Testing and other testing activities to be executed for the implementation and maintenance of the Roaming Relationship between the Roaming Partners, the definition of TAP Test Cases has been based on and inter-linked with the test cases defined by IREG, where applicable.

V4.1

Page 13 of 22

GSM Association Official Document TD.41

Confidential Confidential

4.2 Organisation of the TAP Test Cases

To simplify the maintenance of the TAP Test Cases, specific TADIG PRDs have been defined in order to map the corresponding IREG PRDs (i.e. Service Grouping). As the GSM standard evolves, new services will be introduced and will have to be supported on the TAP by means of new TAP Releases as defined by the TAP Release Management Process. As a consequence, the definition of TAP Test Cases will have to be maintained against the current and the forthcoming TAP Releases (i.e. TAP Release Grouping). New TADIG PRDs will be created when required. The organisation of TAP Test Cases in terms of the related TADIG PRDs is shown hereafter, assuming that the current TAP Release is TAP 3.11 and the forthcoming one TAP 3.12:

Services Grouping IR.24 TAP 3.12 IR.26 IR.27 IR.32 IR.35

TAP Release Grouping

TAP 3.11

TADIG Prd. 43

TADIG Prd. 44

TADIG Prd. 45

TADIG Prd. 46

TADIG Prd. 47

Figure 4-9: Organisation of the TAP Test Cases

Note that the mentioned one-to-one mapping of IREG PRDs vs. TADIG PRDs is only applicable to those IREG PRDs that effectively define test cases. Should a new IREG PRD only refer to test cases already defined in another existing IREG PRD, the new IREG PRD will not be mapped into a new corresponding TADIG PRD.

4.3 Structure of the TADIG PRDs defining the TAP Test Cases
In contrast to the IREG PRDs, where End-to-end Functional Capability Tests ranging from the location updates up to specific test call scenarios are defined, the corresponding TADIG PRDs give the focus on the call event details to be raised on TAP Test Files, when applicable and upon successful completion of the corresponding IREG Test Case. For this reason, each of these TADIG PRDs contains a section where the TAP Test Cases are described in accordance with the corresponding IREG ones. This means that the used terminology (e.g. numbering of test cases, abbreviations, etc.) will be the same. Note that all IREG Test Cases have been mapped, even though some may not be relevant from a TAP Testing point of view (i.e. no Call Event Detail to be raised on TAP). To simplify the maintenance of these TADIG PRDs and to differentiate between the TAP Release specific information, separate sections for each TAP Release will be made available, where applicable. TAP Test Reports are also defined and are recommended to be compiled and provided together with the TAP Test File by each Party, in its quality of VPMN, to the Roaming Partners during the execution of the applicable TAP Testing Procedures.

V4.1

Page 14 of 22

GSM Association Official Document TD.41

Confidential Confidential

The relevant TTC Testing Parameters (e.g. used IMSI numbers, MSISDN, etc.), the indication of which TTCs have been executed as well as possible deviation from standards (e.g. Emergency Calls not transferred on TAP), if any, should be listed here.

5 Optimising the TAP Test Activities: the Cloning Procedure

Re-testing the TAP due to the implementation of a new TAP Release is definitively the most expensive scenario in terms of the time and operational efforts to be spent during the execution of the required testing activities. Opposite to the implementation of a new Roaming Relationship, the generation of the Roaming Traffic Test Data in the VPMNs Roaming Environment may become an issue, due to the fact that the introduction of a new TAP Release does not necessarily imply the execution of End-to-end Functional Capability Tests (i.e. IREG Tests) for all Roaming Relationships between each Party and the Roaming Partners. Moreover, this may become impractical (or even impossible) according to the given timeframe. Due to these reasons, a more practical and efficient solution to generate TAP Test Files has to be sought. As already mentioned above, the VPMNs TAP Test Environment should actually be independent from the specific Roaming Scenario (i.e. the specific Roaming Partner in its quality of HPMN). In other words, when one TAP Test File produced by this environment generates syntactical errors against the applicable validation rules (e.g. missing mandatory items) all TAP Test Files produced by the same environment will be affected by the same syntactical errors. Therefore, all TAP Test Files produced by the same environment are equivalent from a syntactical point of view. They only differ because of the values (e.g. IMSI values, TAP Code of the Recipient, etc.) stored in specific data items. It is then possible to generate a cloned TAP Test File from an original one created by the VPMNs Testing Environment by substituting the values of those specific data items with other valid ones that are applicable to the Roaming Relationship under test. The specific data items that should be subject to value changes can be identified by the element description given in the relevant versions of TD.57 that define the applicable TAP Data Record Format. This procedure is known as the Cloning Procedure and its use is recommended when a significant amount of TAP Test Files have to be produced. This is clearly the scenario where a new TAP Release has to be implemented. Finally, it should be noted that the Cloning Procedure has been already implemented and made available by the GSM Association as a function of the TAP Testing Toolkit (TTT) and will be continuously maintained against new TAP Releases.

6 TAP Testing Process

6.1 Process Definition
The general TAP Testing Process is shown hereafter:

V4.1

Page 15 of 22

GSM Association Official Document TD.41

A
No Cloning Procedure applicable? Yes

Confidential Confidential

VPMN
B

HPMN

TAP Public Interface 2-Validate TAP Test File 4-Make TAP Test File available 6-Validate TAP Test File

Roaming Traffic Test Data

1.A-Create TAP Test File

TAP Test Files

1.B-Clone TAP Test File

Validation O.K. ? Yes

No

IREG Test Reports

3.A-Create TAP Test Reports

TAP Test Reports

5-Make TAP Test Reports available

7-Check TAP Test File vs. TAP Test Reports

Contact VPMN

3.B-Clone TAP Test Reports

Check successful? Yes

No

8-Send TAP Testing Completion Certificate

Figure 6-10: The TAP Testing Process

Depending on the applicability of the Cloning Procedure, the process described above includes: The creation of a new original TAP Test File (1.A) based on the Roaming Traffic Test Data or the creation of a clone from an existing valid one (1.B). The validation of the TAP Test File (2) according the applicable validation rules. This should avoid the submission of syntactically wrong TAP Test Files, in which case the process should restart. The creation of applicable TAP Test Reports (3.A) based on the reports of IREG Tests executed in the VPMNs Roaming Environment or the creation of cloned TAP Test Reports (3.B) from the existing ones. The submission of the TAP Test File (4) by the VPMN to the HPMN via the TAP Public Interface. The submission of the TAP Test Reports related to the TAP Test File (5) by the VPMN to the HPMN. The validation of the TAP Test File received by the HPMN (6) according to the applicable validation rules (e.g. for testing purpose, certain validation rules are irrelevant and should not apply). In case the TAP Test File does not pass the validation process, the HPMN should contact the VPMN and ask for clarifications. The verification of the TAP Test File at a Call Event Detail level against the received TAP Test Reports (7) with specific reference to the performed TAP Test Cases. In case of any problem, the HPMN should contact the VPMN and ask for clarifications. The submission of the TAP Testing Completion Certificate (8) by the HPMN to the VPMN in case of successful completion of the Testing Process.

6.2 Success Criteria

In general, the TAP Testing Process has to be considered as successfully completed when the TAP Test File submitted by the VPMN to the HPMN passed the validation performed in the HPMNs TAP/RAP Environment according to the applicable validation rules and it contains all the call event details that have to be raised on TAP due to the executed TAP

V4.1

Page 16 of 22

GSM Association Official Document TD.41

Confidential Confidential

Test Cases, according to TAP Standards and the Roaming Agreement between the Roaming Partners. Any deviation from the applicable standard should be bilaterally agreed between the Roaming Partners.

6.3 Supporting the TAP Testing Process by means of the TTT

All activities defined in the TAP Testing Process (with the exception of the creation of the original TAP Test File) are supported by the TAP Testing Toolkit (TTT) e.g. TAP File Validation, TAP File Cloning, TAP Test Reports generation, etc. These and other additional TTT tools, like TAP File Viewer or Cross-Referencing between TAP Test Cases and Call Events are meant to make TAP Testing easier and to move the first steps towards a general standardisation of test execution. The support given by the TTT to the TAP Testing Process can be summarised as follows:
VPMNs Roaming Environment

VPMNs TAP Testing Environment

HPMNs TAP/RAP Environment TAP Public Interface Data Clearing House HPMNs Billing System

Roaming Traffic Test Data

VPMNs Billing System Private Interface Cloned TAP Test Files

Data Clearing House

Private Interface

Original TAP Test Files

Incoming TAP Test Files HPMNs TTT TTT Objects

IREG Test Reports

VPMNs TTT

Figure 6-11: Supporting the TAP Testing Process by means of the TTT

where: Original TAP Test Files can be easily imported into the TTT, as well as cloned ones can be created by means of the TTT. TAP Test Files can be browsed by means of the TTT File viewer. TAP Test Files can be validated by means of the TTT File Validation Tool. Complete TAP Test Reports, including cross-references between the TAP Test Cases and the related Call Event Details, can be generated and stored in standardised TTT Objects, together with the TAP Test File. TTT Objects can be exchanged between the VPMNs and the HPMNs TTT besides the TAP Public Interfaces, thus allowing the provision of more detailed information to the HPMN than those made available by means of the TAP Test Report forms defined in the relevant TADIG PRDs For more detailed information about the use of the TTT, please refer to the TTT User Manual. Nevertheless, it is important to make the following considerations: The TTT is an application that can only support the TAP Testing Process but can not replace the VPMNs or the HPMNs TAP/RAP Environments. Similar to all software applications, the TTT has to go through a life cycle in terms of specifications, developments, maintenance, and release management according to

V4.1

Page 17 of 22

GSM Association Official Document TD.41

Confidential Confidential

the policy defined by the GSM Association Headquarters (and therefore out of the scope of this document). Consequently, the compliance of the TTT against the latest approved TADIG standards is also subject to that policy.

7 TAP Testing Procedures

The relevant TAP Testing Procedure should be executed in accordance with the applicable scenario to test/retest the TAP. According to each scenario, different procedures will apply.

7.1 TAP Test Procedure for the Implementation of a new Roaming Agreement
This is the scenario where the following TAP Testing Procedure has to be normally executed by both Roaming Partners, in their quality of VPMN and HPMN that are going to establish a new Roaming Relationship.

Procedural Steps
The following procedural steps shall be executed in sequential order: Step 1: The Roaming Partner under test, in its quality of VPMN, has to configure its TAP Test Environment according to the Roaming Relationship under test. All relevant information (e.g. contact points, TAP3 release to be used on the public interface, involved DCHs, etc.) should be available at this point in time. Exceptions to this procedure shall also be bilaterally agreed at this point in time. Step 2: The Roaming Partner under test, in its quality of VPMN, shall initiate the TAP Testing Process. Note that the Cloning Procedure is not applicable to this scenario (i.e. not recommended by TADIG), unless bilaterally agreed between the Roaming Partners. The Roaming Partners, in their quality as VPMN and HPMN respectively, shall then execute the functional steps defined by the TAP Testing Process as appropriate, to successful completion according to the defined Success Criteria. In case the TAP Testing Process cannot be executed to successful completion, the Roaming Partners should contact each other, resolve any pending issues and/or eventually re-start the process from the beginning, if required. Step 3: Having successfully completed all the functional steps defined by the TAP Testing Process, the Party acting as the HPMN has to provide the Roaming Partner, acting as the VPMN, with the TAP Test Completion Certificate. Note: For each bilateral roaming relationship, this procedure shall be executed twice, as each Roaming Partner has to play both roles (VPMN and HPMN).

7.2 TAP Test Procedure for the Implementation of a new TAP Release
In principle, this is the scenario where the following TAP Testing Procedure has to be normally executed by the Party that is going to implement the new TAP Release and all its Roaming Partners, in their quality of VPMN and HPMN, as appropriate. Moreover, this is the scenario where the Roaming Partner under test, in its quality of VPMN, can make use of the Cloning Procedure to minimise its required testing activities.

Procedural Steps
The following procedural steps shall be executed in sequential order: Step 1: The Roaming Partner under test, in its quality of VPMN, has to configure its TAP Test Environment according to all the Roaming Relationships under test. All relevant information (e.g. contact points, TAP3 Releases to be used on the public

V4.1

Page 18 of 22

GSM Association Official Document TD.41

Confidential Confidential

interface, involved DCHs, etc.) should be available at this point in time. Exceptions to this procedure shall also be bilaterally agreed at this point in time. Step 2: The Roaming Partner under test, in its quality of VPMN, should select one of the Roaming Partners and re-execute the End-to-end Functional Capability Tests (i.e. IREG Tests) in order to generate the required Roaming Traffic Test Data as well as the related IREG Test Reports. It is recommended to select the Roaming Partner that supports the largest set of Services also supported by the Roaming Partner under test. This will grant the execution of the largest possible number of TAP Test Cases. Step 3: The Roaming Partner under test, in its quality of VPMN, and the selected Roaming Partner, in its quality of HPMN, shall then execute the functional steps defined by the TAP Testing Process as appropriate, to successful completion according to the defined Success Criteria. In case the TAP Testing Process cannot be executed to successful completion, the Roaming Partners should contact each other, resolve any pending issues and/or eventually re-start the process from the beginning, if required. Note that the Cloning Procedure is not applicable at this stage, as the original TAP Test File according to the new TAP Release has not been created yet. Step 4: Having successfully completed all the functional steps defined by the TAP Testing Process, the Party acting as the HPMN has to provide the Roaming Partner, acting as the VPMN, with the TAP Test Completion Certificate. Step 5: For all the other Roaming Relationships, the Roaming Partner under test, in its quality of VPMN, and each of the Roaming Partners, in their quality of HPMN, shall then execute the functional steps defined by the TAP Testing Process as appropriate, to successful completion according to the defined Success Criteria. In case the TAP Testing Process cannot be executed to successful completion, the Roaming Partners should contact each other, resolve any pending issues and/or eventually re-start the process from the beginning, if required. Having successfully completed all the functional steps defined by the TAP Testing Process, the Party acting as the HPMN has to provide the Roaming Partner under test, acting as the VPMN, with the TAP Test Completion Certificate. Note that the Cloning Procedure is now applicable at this stage, as the original TAP Test File according to the new TAP Release has already been created during Step 3 of this procedure. It should be also noted that the execution of each required TAP Testing Process (i.e. where different Roaming Partners are involved) can run in parallel.

Finally, it should be noted that the Roaming Partner under test, in its quality of VPMN, may decide not to make use of the Cloning Procedure. Should this be the case, the same procedural steps as defined for the previous scenario shall be executed in sequential order by the Roaming Partner under test as many time as the existing Roaming Relationships with its Roaming Partners.

7.3 TAP Test Procedure for the Introduction of additional Services

This is the scenario where the TAP Testing Procedure has to be normally executed by the Party that is going to introduce the additional services and the Roaming Partners supporting these services, in their quality of VPMN and HPMN, as appropriate. The TAP Testing Procedure applicable to this scenario is the same as for the previous one (i.e. Implementation of a new TAP Release). Note: Only the applicable TAP Test Cases related to the additional services shall be executed.

8 Administrative Documents used during Testing the TAP

This section contains the general administrative documents that are recommended to be used during the execution of the applicable TAP Testing Procedure.

V4.1

Page 19 of 22

GSM Association Official Document TD.41

Confidential Confidential

Note that other specific documents (i.e. TAP Test Reports) are given in each TADIG PRDs defining the TAP Test Cases (see the Document Cross Reference section in the Introduction).

8.1 TAP Testing Completion Certificate

The TAP Testing Completion Certificate shall be exchanged to certify the successful execution of the applicable TAP Testing Procedure. It shall be provided by the each Testing Party, in its quality of TAP Recipient (for example the HPMN), to the Roaming Partner under test, in its quality of TAP Sender (for example the VPMN). The recommended form is given hereafter.

V4.1

Page 20 of 22

GSM Association Official Document TD.41

Confidential Confidential

TAP Testing Completion Certificate

This certificate confirms the successful completion of the TAP Testing Procedure Between < Party (a) Name>, <Country>, in its quality as TAP Sender and <Party (b) Name>, <Country>, in its quality as TAP Recipient

The tests were completed on <dd / mm / yyyy>. Comments: ________________________________________________________________ ________________________________________________________________ ________________________________________________________________

On behalf of <Party (b) Name>: Date Name Signature _____________________

___________ _____________________

V4.1

Page 21 of 22

GSM Association Official Document TD.41

Confidential Confidential

Document Management
Document History
Version
1.0.0 2.0.0 3.0.0 3.0.1 3.0.2 3.0.3 3.4 4.0 4.1

Date
12 June 2001 13 July 2001 27 July 2001 6 December 2001 31 May 2001 25 May 2004 28 June 2011 04 February 2009 15 December 2011

Brief Description of Change

New PRD. Version sent by Weekly Bulletin to Membership for Approval Membership Approved Version NSCR 1 (TADIG Doc 207/01) NSCR 2 (TADIG Doc 060/02) NSCR 3 (TADIG Doc 57/063 Rev1) Minor CR 4 (TADIG Doc 59/040) and Minor CR 5 (TADIG Doc 59/041). Major CR 6 (TADIG Doc 66_070). Minor CR 007 (TADIG Doc 72_031). Inclusion of VoLTE testing.

Approval Authority
TADIG #51 General Assembly TADIG #52 TADIG #53 TADIG #57 TADIG #59 TADIG #66 EMC TADIG #72

Editor / Company
Mauro Mele / Comfone AG Mauro Mele / Comfone AG Mauro Mele / Comfone AG Mauro Mele / Comfone AG Mauro Mele / Comfone AG Mauro Mele / Comfone AG Mauro Mele / Comfone AG Mauro Mele / Comfone AG Mauro Mele / Comfone AG

Other Information
Type
Document Owner Editor / Company

Description
TADIG Mauro Mele / Comfone AG

V4.1

Page 22 of 22