US20110143754A1

US20110143754A1 - Predictive intelligence based automated camel testing

Info

Publication number: US20110143754A1
Application number: US12/962,317
Authority: US
Inventors: John Yue Jun Jiang
Original assignee: Roamware Inc
Current assignee: Roamware Inc
Priority date: 2008-07-24
Filing date: 2010-12-07
Publication date: 2011-06-16
Also published as: ES2432668A2; BR112012033631B1; ES2430947R1; WO2012003514A1; US9002320B2; BR112012033631A2; WO2012002985A1; ES2432668B1; ES2432668R1; WO2012003514A9; ES2430947A2; BR112012033631B8; US20120021720A1; SG186890A1

Abstract

The present invention is directed towards a method for facilitating roaming tests for a club network. The method includes simulating a roamer's profile by a signaling gateway and associating with either a club network or a roaming partner network of the club network. The club network and the roaming partner network correspond to a Home Public Mobile Network (HPMN) and a Visited PMN, respectively, in case the roamer is an outbound roamer. In case the roamer is an inbound roamer, the club network corresponds to the VPMN and roaming partner network corresponds to the HPMN. The method further includes performing by the signaling gateway, one or more CAMEL capability tests on the roamer. The roaming subscriber is associated with either the club network or the roaming partner network.

Description

RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Patent Application No. 61/267,169 titled “Predictive Intelligence as the Basis of Automated CAMEL Testing for Voice Roaming” filed on Dec. 7, 2009, and the benefit of U.S. Provisional Patent Application No. 61/361,136 titled “Advanced Predictive Intelligence” filed on Sep. 30, 2010. This application is also a continuation in part of U.S. patent application Ser. No. 12/219,622 titled “Predictive Intelligence” filed on Jul. 24, 2008. Each of the preceding applications is incorporated by reference in its entirety herein.

FIELD OF THE INVENTION

The present invention generally relates to mobile communication. More specifically, the invention relates to proactive roaming tests for CAMEL voice roaming.

BACKGROUND OF THE INVENTION

Roaming traffic contributes a significant percentage of an operator's revenue and even a better percentage of the operator's margin. With increasing competition and regulatory control, operators are being more pressured to increase their roaming revenue and reduce roaming margin losses. They need keep a check on roaming quality and fraud control at both, own networks to serve inbound roamers and roaming partner networks to serve outbound roamers, that can directly impact an operator's roaming revenue and margin.
Establishing roaming relationships is essential for operators to achieve roaming revenue in the first place. Such process involves both inbound and outbound roaming tests. These tests are usually only performed prior to the launch of these roaming relationships. However, roaming partners may constantly change network configuration, upgrade new software, add new number ranges, introduce new inter-connection routing or add new network elements. These changes or incomplete or incorrect execution of changes could affect roaming services. Constantly maintaining roaming quality of the services thus will help increase roaming revenue. Also, while roaming represents a substantial revenue source for the operators, it is also subjected to frauds like Subscriber identity module (SIM) box and interconnection frauds.
Camel roaming is essential for prepaid roaming these days. Camel roaming is also becoming more valuable for many advanced value services such as short code, fraud control, misdialed call correction, real-time billing, CLI delivery, home call routing etc for outbound roamers. However, establishing camel roaming is very difficult for operators. Although there does not exist a formal agreement per se, but there are extensive tests that are required to be carried out. This causes significant delays for many operators. Another alternative is where manual testing is done. However, this takes a lot of times although it's a cheaper alternative for some countries.
Automated testing is preferred but generally expensive and even more problematic for continued testing. Such a testing involves remote probes (real or virtual mobile stations) around the world. When a remote probe behaves like a virtual mobile station, a virtual SIM is dynamically slotted in from a central multiplexer of real SIMs to test different types of subscribers for different types of services under some kinds of schedules. However, there are several issues with the remote probes approach. First is coverage issue, as despite increasing coverage in multiple countries and major cities, this approach does not assure covering of home operator's roamer's services in the part that are not covered by these remote probes. The coverage problem also applies to a visiting operator for inbound roamers when the country's expanse is huge such as China, India etc.
Moreover, the operator often cannot afford to continuously test its inbound roaming service availability to accommodate constant changes of network infrastructures including network elements (e.g. VLR/VMSCs) and routing. Another drawback is cost as remote probe vendors need ways to recuperate the cost (e.g. remote probe hardware cost, data center collocation cost including bandwidth and maintenance etc.) for the vast amount of investment for extended coverage. Further, even testing any kind of subscriber (e.g. prepaid, postpaid, Virtual Private Network (VPN), machine-to-machine etc.) is done by providing the corresponding SIM card to the test vendor. It is unlikely that the number of test scenarios is multiplied by the number of profiles because of the costs of these tests, thus making it is hard for the operator to control the quality of service offered to any of the subscribers.
Further, due to its lack of network signaling, remote probe approach is also not quite effective in detecting various revenue affecting services like mentioned above. Further, in terms of providing revenue assurance, owing to the constant changes in IOT tariffs and constant upgrades of billing systems, constant regression tests can help reduce these revenue leaks. However, since remote probes are bottlenecked by their coverage area, unfortunately many countries that are out of the coverage cannot gain benefit of these tests. Further, remote probe approach cannot perform integrated camel testing with operator/network initiated services such as on-demand Operator Determined Barring (ODB), Cancel Location, InsertSusbcriberData (ISD), Immediate Service Termination (IST) and on-demand profile changes.
In accordance with the foregoing, there is a need in the art of a system, a method, and a computer product for creating a solution that gives an operator the ways to deal with above mentioned problems using automated testing mechanisms. The solution can be deployed for one single operator or in a central manner for multiple operators. When solution is used for multiple operators, the deployment can be hub based, where each of these operators can be considered as a club member.

SUMMARY

The present invention is directed towards a method for facilitating roaming tests for a club network. The method includes simulating a roamer's profile by a signaling gateway and associating with either a club network or a roaming partner network of the club network. The club network and the roaming partner network correspond to a Home Public Mobile Network (HPMN) and a Visited PMN, respectively, in case the roamer is an outbound roamer. In case the roamer is an inbound roamer, the club network corresponds to the VPMN and roaming partner network corresponds to the HPMN. The method further includes performing by the signaling gateway, one or more CAMEL capability tests on the roamer. The roaming subscriber is associated with either the club network or the roaming partner network.
Another aspect of the invention presents a system for facilitating roaming tests for a club network. The system includes a gateway associated with the club network for simulating a roamer's profile by a signaling gateway and associating with either a club network or a roaming partner network of the club network. The club network and the roaming partner network correspond to a Home Public Mobile Network (HPMN) and a Visited PMN, respectively, in case the roamer is an outbound roamer. In case the roamer is an inbound roamer, the club network corresponds to the VPMN and roaming partner network corresponds to the HPMN. The signaling gateway further performs one or more CAMEL capability tests on the roamer. The roaming subscriber is associated with either the club network or the roaming partner network.
Yet another aspect of the present invention provides a computer program product including a computer usable program code for facilitating roaming tests for a club network. The computer program product includes a signaling gateway that simulates a roamer's profile and associates it with either a club network or a roaming partner network of the club network. The club network and the roaming partner network correspond to a Home Public Mobile Network (HPMN) and a Visited PMN, respectively, in case the roamer is an outbound roamer. In case the roamer is an inbound roamer, the club network corresponds to the VPMN and roaming partner network corresponds to the HPMN. The computer program product further performs by the signaling gateway, one or more CAMEL capability tests on the roamer. The roaming subscriber is associated with either the club network or the roaming partner network.

BRIEF DESCRIPTION OF DRAWINGS

In the drawings, the same or similar reference numbers identify similar elements or acts.

FIG. 1 illustrates a system for facilitating roaming tests for simulated inbound and outbound roamers of a club Public Mobile Network (PMN), in accordance with an embodiment of the present invention;

FIG. 2 represents a flowchart for facilitating roaming tests for the simulated inbound and outbound roamers, in accordance with an embodiment of the present invention;

FIG. 3 represents a flow diagram for creating and validating profile, using a Predictive Intelligence based CAMEL Automated Testing (CAT) module, for the simulated outbound roamer of the club PMN, at a Mobile Switching Center (MSC)/Visiting Location Register (VLR) in a roaming partner PMN, in accordance with an embodiment of the present invention;

FIG. 4 represents a flow diagram for validating the IDP parameters in the CAMEL trigger for the simulated outbound roamer at the roaming partner PMN MSC/VLR, in accordance with an embodiment of the present invention;

FIG. 5 represents a flow diagram for testing CAMEL CONTINUE/CONNECT operations for the simulated outbound roamer at the roaming partner PMN MSC/VLR, in accordance with an embodiment of the present invention;

FIG. 6 represents a flow diagram for testing CAMEL Default Call Handling (DCH) Continue/Release operation for the simulated outbound roamer at the roaming partner PMN MSC/VLR, in accordance with an embodiment of the present invention;

FIG. 7 represents a flow diagram for testing CAMEL Release Call operation for the simulated outbound roamer at the roaming partner PMN MSC/VLR, in accordance with an embodiment of the present invention;

FIG. 8 represents a flow diagram for testing CAMEL Event Reports on ANSWER and DISCONNECT for the simulated outbound roamer at the roaming partner PMN MSC/VLR, in accordance with an embodiment of the present invention;

FIG. 9 represents a flow diagram for testing CAMEL Event Reports on BUSY, No-ANSWER and Not-REACHABLE for the simulated outbound roamer at the roaming partner PMN MSC/VLR, in accordance with an embodiment of the present invention;

FIG. 10 represents a flow diagram for testing CAMEL Call Information Request and Report operation for the simulated outbound roamer at the roaming partner PMN MSC/VLR, in accordance with an embodiment of the present invention;

FIG. 11 represents a flow diagram for testing CAMEL Apply Charging operation for the simulated outbound roamer at the roaming partner PMN MSC/VLR, in accordance with an embodiment of the present invention;

FIG. 12 represents a flow diagram for testing CAMEL Furnish Charge Information (FCI) on Event Reports on ANSWER and DISCONNECT operation for the simulated outbound roamer at the roaming partner PMN MSC/VLR, in accordance with an embodiment of the present invention;

FIG. 13 represents a flow diagram for testing interaction of MAP PSI location and subscriber state with CAMEL operation for the simulated outbound roamer at the roaming partner PMN MSC/VLR, in accordance with an embodiment of the present invention;

FIG. 14 represents a flow diagram for testing interaction of MAP barring all calls and messages (including international calls messages) with CAMEL operation for the simulated outbound roamer at the roaming partner PMN MSC/VLR, in accordance with an embodiment of the present invention;

FIG. 15 represents a flow diagram for testing interaction of MAP PRN with Suppression of Announcement (SoA) with CAMEL operation for the simulated outbound roamer at the roaming partner PMN MSC/VLR, in accordance with an embodiment of the present invention;

FIG. 16 represents a flow diagram for creating profile for a simulated inbound roamer from a roaming partner network PMN, at a Mobile Switching Center (MSC)/Visiting Location Register (VLR) in club PMN, using the CAT module, in accordance with an embodiment of the present invention;

FIG. 17 represents a flow diagram for validating IDP parameters in CAMEL trigger of the simulated inbound roamer, in accordance with an embodiment of the present invention;

FIG. 18 represents a flow diagram for testing CAMEL CONNECT/CONTINUE operations for the simulated inbound roamer, in accordance with an embodiment of the present invention;

FIG. 19 represents a flow diagram for testing CAMEL DCH CONTINUE/RELEASE operations for the simulated inbound roamer, in accordance with an embodiment of the present invention;

FIG. 20 represents a flow diagram for testing interaction of MAP PSI subscriber Unreachable/Busy operation for the simulated inbound roamer, in accordance with an embodiment of the present invention;

FIG. 21 represents a flow diagram for testing Event ANSWER/DISCONNECT operation for the simulated inbound roamer, in accordance with an embodiment of the present invention;

FIG. 22 represents a flow diagram for testing Call Forwarding on Unreachable/No-answer operation for the simulated inbound roamer, in accordance with an embodiment of the present invention;

FIG. 23 represents a flow diagram for testing SS/ODB call barring operation for the simulated inbound roamer, in accordance with an embodiment of the present invention;

FIG. 24 represents a flow diagram for testing IDP Phase 2 operation for the simulated inbound roamer, in accordance with an embodiment of the present invention;

FIG. 25 represents a flow diagram of testing FCI on No-Answer, Unreachable, Busy and Route-Select-Failure operation for the simulated inbound roamer, in accordance with an embodiment of the present invention;

FIG. 26 represents a flow diagram of testing reporting accuracy, credit balance accuracy and tariff switching for Call Information (CI) request and report, Send Charging Information (SCI) and Apply Charging request and report, operations for the simulated inbound roamer, in accordance with an embodiment of the present invention; and

FIG. 27 represents a flow diagram of testing interaction of ETC (Establish Temporary Connection), ARI (Assist Resource Instruction), CTR (ConnectToResource) and PA (Prompt Announcement) operations for the simulated inbound roamer, in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION

In the following description, for purposes of explanation, specific numbers, materials and configurations are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one having ordinary skill in the art that the present invention may be practiced without these specific details. In some instances, well-known features may be omitted or simplified, so as not to obscure the present invention. Furthermore, reference in the specification to “one embodiment” or “an embodiment” means that a particular feature, structure or characteristic, described in connection with the embodiment, is included in at least one embodiment of the present invention. The appearance of the phrase “in an embodiment”, in various places in the specification, does not necessarily refer to the same embodiment.
The present invention provides a system, a method, and a computer program product for facilitating CAMEL roaming tests for both outbound and inbound roamers of a club operator or a club/group of operators using SS7-based signaling and voice processing system at the network side. The method derives from earlier patent application titled “Predictive Intelligence”, by John Jiang, and the primary module (signaling gateway) of the present invention focuses on automated procedure for IREG 32 CAMEL testing on voice part, hence it is hereinafter, interchangeably referred to Predictive Intelligence based Camel Automated Testing module (PI-CAT or CAT) module. The method does not involve any mobile handset, physical SIMs or probes etc. The method also does not require dispatch of a real roamer at a roaming location. Instead, the method involves simulating a camel roamer via signaling at a roaming location in a roaming partner network, using the signaling gateway/CAT module.
A roaming partner network corresponds to a network that has at least one roaming agreement such as, but not limited to, Global System for Mobile communication (GSM), General Packet Radio Services (GPRS), Customized Application for Mobile Enhanced Logic (CAMEL) and Third Generation of mobile (3G) agreement with the club network. It will be apparent to a person skilled in the art that roaming services include standard call and non-call related activities such as, but not limited to, Mobile Originated (MO) call, Mobile Terminated (MT) call, Short Message Service (SMS), Packet Data Network (PDN), and other Value Added Services (VASs) such as call forwarding, call barring etc.
CAMEL is an Intelligent Network (IN) based standard that has a framework to help a network operator to provide the subscribers with the operator specific services even when roaming outside the home network. The primary use of CAMEL is prepaid (outbound) roaming. Unlike a USSD based prepaid roaming solution which is call-back based, CAMEL based prepaid roaming provides a seamless user experience just like normal mobile originated activities (calls, SMS etc). Since signaling control of an outbound roamer's call is passed by the VPMN gsmSSF to the HPMN gsmSCF, the gsmSCF is able to deduce the prepaid roamer's balance appropriately.
Another use of CAMEL is to enable Virtual Home Environment (VHE). Some implementation of VHE services can be like outbound roamers' calls based on home dialing experience (e.g. calls without country codes or home international access prefix, short code calls etc) can be correctly translated to the ones corresponding to the visitor network environment to complete the calls to provide a home-like user experience.
CAMEL is also useful for real-time billing. TAP records between roaming partners can come in as late as a month. Since it is just a wholesale Inter Operator Tariff (IOT) from the TAP exchange that doesn't affect retail IOT, the HPMN can produce retail billing in real-time. CAMEL can be used as well to implement fraud control measures. Operator Determined Barring (ODB) works well on all calls or international call barring while roaming at a VPMN but not well on premium numbers barring at the VPMN since these numbers can change dynamically. By using CAMEL control on an outbound roamer, all the roamer's calls can be restricted according to HPMN application logic.
Other services like selective home routing, least cost routing or CLI delivery or third party partner carrier routing from an outbound roamer can also be implemented using the CAMEL capabilities. In this case, an outbound roamer's call can be selectively routed back to the home network or a partner network based on the called number and the calling network. The selection logic employed by the HPMN gsmSCF can be based on least cost routing or just quality service control (e.g. roaming quality monitoring or for better delivery of caller ID via home or partner network) or lawful interception at home or just simply collect termination charges at home without incurring extra charges to the roamer.
In accordance with various embodiments of the present invention, the method further involves the signaling gateway to perform various CAMEL capability tests via signaling and determines the success or failure of these tests via signaling and intercepting voice circuits to hear “success” or “failure” announcements. Since, the roamer's profile is simulated it can also be changed through signaling. Moreover, all interactions with various components in the club network and the roaming partner network like VLR, HLR and SCP are also simulated.
The club network operator performs the proactive roaming tests by deploying the signaling gateway, either in the club network or outside the club network (at a centralized location, in a hub architecture) having a signaling connection to reach the club network for facilitating roaming tests for different club networks. In this manner, the signaling gateway is able to serve either one club network or multiple club networks (in multi-tenant support) for the CAMEL testing. Each of these different networks for which these tests can be conducted become a part of the club, and are hereinafter interchangeably referred to as club members. Each of these club members may appear as HPMN or VPMN to their respective roaming partners depending on whether the tests are done for outbound roamers or inbound roamers of the club network.
FIG. 1 illustrates a system 100 that tests roaming services for all inbound and outbound roamers of the club network, in accordance with an embodiment of the present invention. System 100 includes a Predictive Intelligence based CAMEL Automated Testing (CAT) module 102 (i.e., the signaling gateway) in a club Public Mobile Network (PMN) 104 (i.e., the club network). Club PMN 104 operator uses CAT module 102 to conduct one or more CAMEL capability tests for its outbound roamers that may roam in any of the roaming partner networks, and its inbound roamers that may be coming from any of these roaming partner networks. Thus, club PMN 104 acts as a Home PMN (HPMN) of the outbound roamers, whereas roaming partner networks in which these outbound roamers may roam act as Visited PMNs (VPMNs). Accordingly, club PMN 104 acts as a VPMN for the inbound roamers, whereas roaming partner networks to which these inbound roamers belong, act as HPMNs.
Club PMN 104 further includes a Mobile Switching Center (MSC)/Visiting Location Register (VLR) 106, a Serving GPRS Support Node (SGSN) 108, a Gateway GPRS Support Node (GGSN) 110, a Gateway MSC (GMSC) 112, a roaming Signal Control Point (SCP) 114, a Home Location Register (HLR) 116 and a Short Message Service Center (SMSC) 118. Since network elements MSC/VLR 106, SGSN 108, GGSN 110, GMSC 112, SCP 114, HLR 116 and SMSC 118 reside in Club PMN 104, they are hereinafter referred to as MSC-C/VLR-C 106, SGSN-C 108, GGSN-C 110, GMSC-C 112, SCP-C 114, HLR-C 116 and SMSC-C 118, respectively. These network elements communicate with each other over a Signaling System 7 (SS7) link (represented by dashed lines in FIG. 1), except that SGSN-C 108 communicates with GGSN-C 110 via an Internet Protocol (IP) link (represented by solid lines in FIG. 1).
System 100 further includes a roaming partner PMN 120 (i.e., the roaming partner network) that is associated with club PMN 104. It will be apparent to a person skilled in the art that system 100 may include various other roaming partner networks. However, for the sake of convenience, this embodiment considers only one roaming partner network (i.e., roaming partner PMN 120). Roaming partner PMN 120 includes a MSC/VLR 122, a SGSN 124, a GGSN 126, a GMSC 128, an SCP 130, an HLR 132 and an SMSC 134. Since network elements MSC/VLR 122, SGSN 124, GGSN 126, GMSC 128, SCP 130, HLR 132 and SMSC 134 reside in roaming partner PMN 120, they are hereinafter referred to as MSC-R/VLR-R 122, SGSN-R 124, GGSN-R 126, GMSC-R 128, SCP-R 130, HLR-R 132 and SMSC-R 134, respectively. All these network elements of roaming partner PMN 120 communicate with each other over the SS7 link, except that SGSN-R 124 communicates with GGSN-R 126 via the IP link. Further, as shown in FIG. 1, the network elements of roaming partner PMN 120 also communicate with the network elements of club PMN 104. For example, GMSC-R 128 communicates with GMSC-C 112 over an ISDN User Part Protocol (ISUP) link, whereas SGSN-R 124 and GGSN-R 126 communicate with GGSN-C 110 and SGSN-C 108, respectively via the IP link.
Other network elements of roaming partner PMN 120 (e.g., MSC-R/VLR-R 122) communicate with various other network elements of club PMN 104 (e.g., HLR-C 116) via the SS7 link. It will also be apparent to a person skilled in the art that various components of club PMN 104 communicate with roaming partner PMN 120 using various signaling techniques including, but not limited to, SS7, SIP, IP, ISUP etc.
It will also be apparent to a person skilled in the art that club PMN 104 and roaming partner PMN 120 may also include various other network components (not shown in FIG. 1), depending on the architecture under consideration. In an embodiment of the present invention, various network elements of club PMN 104 and roaming partner PMN 120 are located in an IR.21 database (not shown in FIG. 1) such as RAEX IR.21. In an embodiment of the present invention, the IR.21 database is coupled to CAT module 102.
The most important CAMEL architecture network elements consist of a GSM Service Control Function (gsmSCF) in club PMN and a GSM Service Switch Function (gsmSSF) in roaming partner PMN. The gsmSCF and gsmSSF communicates with each other using the CAMEL Application Part (CAP). When a CAMEL outbound roamer is registering at a CAMEL partner VPMN VLR, the HPMN HLR of the roamer provides CAMEL Subscription Information (CSI) to the VPMN VLR for the roamer via MAP Insert Subscriber Data (ISD) message.
GSM Association has defined a, IREG specification (IR.32) that defines end-to-end functional capability tests relating to the international roaming of a mobile subscriber to CAMEL services, belonging to an HPMN, to and within a roaming/visited PMN. The fundamental objective of these tests is to confirm the capability of CAMEL services which the subscribers should receive while roaming from their Home network to Visited networks. The overall objective of these tests is to confirm that the CAMEL features, which are known to operate correctly within each separate home network, will also operate correctly while inter-PMN roaming.
There are various types of tests that are defined as per IR.32 standard. Some of them are:

- “Location updating” and the associated ISD including O-CSI can be successfully completed for MS roaming in PMN.
- ProvideSubscriberInfo (PSI) successfully executed.
- Outgoing speech calls by MS are handled for:
  - Calls to VPMN country (i.e. local calls)
  - International calls
- Correct reporting for various Event Detection Points.
- SCF is able to terminate calls.
- The default call handling in the O-CSI is correctly executed.
- Suppression of announcements in VMSC is successfully executed.
- SS and ODB operations are correctly executed.

In accordance with various embodiments of the present invention, CAT module 102 addresses all the scenarios listed above from a VPMN-HPMN perspective (not based on mobile station and VPMN VLR perspective).
Furthermore, specific types of tests defined for CAMEL Phase 2 are defined as per the IR.32 standard:

- 1. IDP Trigger Criteria are correctly executed.
- 2. Encountered Event Detection Points lead to successful Follow-On calls and reconnections, respectively.
- 3. Control of call duration, transmission of AdviceOfCharge parameters and the report of specific information about a single call party are successfully executed.
- 4. The assist procedure to connect a roaming subscriber to an IN-Announcement located in his HPMN is successfully executed.
- 5. The operation of SS-CSI is correctly executed.

In accordance with various embodiments of the present invention, CAT module 102 also addresses all the scenarios listed above from a VPMN-HPMN perspective (not based on mobile station and VPMN VLR perspective).
In order to test CAMEL roaming services for the inbound and outbound roamers, CAT module 102 simulates the roamer's profile at roaming partner PMN 120. CAT module 102 taps SS7 and IP roaming links between network elements of club PMN 104 and roaming partner PMN 120 in order to monitor roaming signaling traffic and packet data traffic at club PMN 104. Thereafter, CAT module 102 performs various CAMEL capability tests on the roamer. The roaming signaling traffic includes both Signaling Connection Control Part (SCCP) and ISUP traffic. In an embodiment of the present invention, the SCCP and ISUP traffic is transported over an IP interface such as, but not limited to, Signaling Transport (SIGTRAN) protocol, Voice over IP (VoIP) and Real-Time Transport Protocol (RTP). The SCCP traffic includes Mobile Application Part (MAP) traffic, CAMEL Application Part (CAP) traffic and Transaction Capabilities Application Part (TCAP) traffic. CAT module 102 further taps the SS7 link between SCP-C 114 and SCP-R 130 and the ISUP link between GMSC-C 112 and GMSC-R 128, in accordance with another embodiment of the present invention. In one embodiment of the present invention, CAT module 102 passively taps signaling path between the network elements of club PMN 104 and roaming partner PMN 120. In another embodiment of the present invention, CAT module 102 intercepts the signaling path with an address such as a Global Title (GT), a point code or an IP address.
Furthermore, in an embodiment of the present invention, CAT module 102 performs roaming signaling traffic and packet data traffic exchange between club PMN 104 and roaming partner PMN 120 for club PMN 104's outbound and inbound roamers. Additionally, in another embodiment of the present invention, CAT module 102 is connected with the network elements of club PMN 104 internally (e.g., communicates with GMSC-C 112 via the ISUP link and communicates with MSC-C/VLR-C 106 via the SS7 link).
Now, in order to facilitate various roaming tests for club PMN 104 operator, CAT module 102 needs to create test profile at a MSC/VLR location of the roaming subscriber and then conduct various CAMEL capability tests on the roaming subscriber. FIG. 2 represents a flowchart for facilitating these roaming tests for the simulated inbound and outbound roamers, in accordance with an embodiment of the present invention. At step 202, CAT module 102 simulates the roamer's profile by associating it with either the club PMN 104 or roaming partner PMN 120. CAT module 102 (i.e., signaling gateway 102) simulates the roamer's profile by faking the roaming subscriber's location at a MSC/VLR of roaming subscriber. In one embodiment of the present invention, in case of outbound roaming, CAT module 102 creates fake profile for the simulated outbound roamer at MSC-R/VLR-R 122. In another embodiment of the present invention, in case of inbound roaming, CAT module 102 creates fake profile for the simulated inbound roamer at MSC-C/VLR-C 106. Details of the profile creation for simulated inbound and outbound roamers are explained later in various embodiments of the present invention. Thereafter at step 204, CAT module 102 performs one or more CAMEL capability tests for the roaming subscriber by simulating transactions between various elements of club PMN 104 and roaming partner PMN 120. These simulated transactions include, but not limited to, TCAP traffic, packet data traffic and ISUP traffic. All the CAMEL capability tests are explained later in various embodiments of the present invention.

CAT Test Procedures for Outbound Roamers

FIG. 3 represents a flow diagram for creating and validating profile, using CAT module 102, for the simulated outbound roamer of club PMN 104, at MSC-R/VLR-R 122 in roaming partner PMN 120, in accordance with an embodiment of the present invention. Since CAT module 102 is conducting all these tests on behalf of the club member, there is no imminent need to involve of SCP of club member (SCP-C 114), unless explicitly requested by the club member, in which case all CAMEL signaling between SCP-C and roaming partner's VLR-R/VMSC-R 122 will be relayed through CAT module 102. Hence, for all subsequent call flows we are not involving SCP-C 112, but it will be apparent to a person skilled in the art that SCP-C 114 can be involved based on club member's request.
CAT module 102, first creates fake roamer's (IMSI) location and validates the same with club PMN 104, using Location Update (LUP) and Insert Subscriber's Data (ISD) messages between steps 302 and 308. The LUP is done using the IMSI exchanged between the club networks and roaming partner network. CAT module 102 then validates if the roamer has the right camel profile to be tested by sending signaling messages such as a MAP Provide_Roaming_Number (PRN), a MAP Insert Subscriber Data (ISD) and a MAP_RESTORE_DATA (RSD)-ACK on the test IMSIs to any MSC/VLR of roaming partner PMN 120 (e.g., MSC-R/VLR-R 122). Hence, at step 310, CAT module 102 sends MAP Providing Roaming Number (PRN) message to the roaming partner PMN's VLR-R 122. Thereafter, at step 312, VLR-R 122 then triggers MAP RestoreData (RSD) to CAT module 102 which then relays the request to the HLR-C 116. CAT module 102 can modify profile messages as it relays from HLR-C 116 to VPMN VLR-R 122. Finally, at step 314, CAT module 102 also obtains the MSRN (Mobile Station Roaming Number) for subsequent call tests in response to the PRN message to VLR-R 122.
FIG. 4 represents a flow diagram for validating the IDP parameters in the CAMEL trigger for the simulated outbound roamer at the roaming partner PMN's 120 MSC/VLR-R 122, in accordance with an embodiment of the present invention. CAT module 102 uses steps in FIG. 3 to create CAMEL outbound roamer's profile at VLR-R 122. At step 402, CAT module 102 sets a call Forward-To-Number (FTN) and then issues a call via ISUP signaling message (IAM), at step 404, to the MSRN obtained from steps in FIG. 3, which triggers call forwarding. However, before call forwarding takes place, the VPMN VMSC-R 122 uses the camel profile of the outbound roamer at the VLR-R 122 to trigger IDP message at step 406. All parameters of the IDP message are then validated by CAT module 102. This validation can also be relayed to SCP-C 114, if requested by club PMN 104.
FIG. 5 represents a flow diagram for testing CAMEL CONTINUE/CONNECT operations for the simulated outbound roamer at the roaming partner's VLR-R 122, in accordance with an embodiment of the present invention. In order to test the Continue operation, CAT module 102 follows on from the steps of FIG. 4, when CAT module 102 receives the IDP (at step 406), CAT module 102 issues a CONTINUE message at step 502. At step 504, CAT module 102 receives an ISUP IAM (CAT#) message when the FTN was set to CAT#, which is a number that can be routed to CAT module 102 via ISUP signaling.
Similarly, to test the Connect operation, CAT module follows on from steps of FIG. 4, when CAT module 102, receives the IDP (at step 406), CAT module 102 issues the CONNECT (CAT#) message at step 502. At step 504, CAT module 102 receives ISUP (CAT#), where the original FTN was different from CAT#, which is a number that can be routed to CAT module 102 via ISUP signaling.
FIG. 6 represents a flow diagram for testing CAMEL Default Call Handling (DCH) Continue/Release operation for the simulated outbound roamer at the roaming partner PMN's VLR-R 122, in accordance with an embodiment of the present invention. In order to test the DCH-Continue operation, CAT module 102 follows on from the steps of FIG. 4, when CAT module 102 receives the IDP (at step 406), CAT module 102 issues a TCAP ABORT message at step 602. At step 604, CAT module 102 receives an ISUP (CAT#) message, when the FTN was set to CAT#, which is a number that can be routed to CAT module 102 via ISUP signaling. Similarly, in order to test the DCH-Release operation, CAT module 102 follows on from the steps of FIG. 4, when CAT module 102 receives the IDP (at step 406), CAT module 102 issues a TCAP ABORT message at step 602. However, at step 604, CAT module 102 receives a RELEASE message.
FIG. 7 represents a flow diagram for testing CAMEL Release Call operation for the simulated outbound roamer at the roaming partner PMN's VLR-R 122, in accordance with an embodiment of the present invention. To test the CAMEL Release Call operation, CAT module 102 follows on from the steps of FIG. 4, when CAT module 102 receives the IDP (at step 406), CAT module 102 issues a Release Call message at step 702. At step 704, CAT module 102 receives an ISUP release message and should not expect to receive ISUP IAM (CAT#) message, when the FTN was set to the CAT#.
FIG. 8 represents a flow diagram for testing CAMEL Event Reports on ANSWER and DISCONNECT for the simulated outbound roamer at the roaming partner PMN's VLR-R 122, in accordance with an embodiment of the present invention. In order to test the CAMEL Event Reports on ANSWER and DISCONNECT operations, CAT module 102 follows on from the steps of FIG. 4, when CAT module 102 receives the IDP (at step 406), CAT module 102, at step 802, requests Event reports (RRB) on ANSWER and DISCONNECT and then CONTINUE. At step 804, CAT module 102 receives an ISUP (CAT#) message, when the FTN was set to CAT#. Thereafter, at step 806, CAT module 102 responds to JAM with an ISUP ANM message. This triggers a CAMEL ANSWER event ERB from VMSC 122 to CAT module 102. After certain time period, at step 808, CAT module 102 then issues an ISUP REL message, which triggers a CAMEL DISCONNECT event ERB from VMSC 122 to CAT module 102.
FIG. 9 represents a flow diagram for testing CAMEL Event Reports on BUSY, No-ANSWER and Not-REACHABLE for the simulated outbound roamer at the roaming partner PMN's MSC/VLR-R 122, in accordance with an embodiment of the present invention. In order to test the CAMEL Event Reports on BUSY, No-ANSWER and Not-REACHABLE operations, CAT module 102 follows on from the steps of FIG. 4, when CAT module 102 receives the IDP (at step 406), CAT module 102, at step 902, requests event reports (RRB) on BUSY, NO-ANSWER and NOT-REACHABLE and then CONTINUE. At step 904, CAT module 102 receives an ISUP IAM (CAT#) message, when the FTN was set to CAT#. Thereafter, at step 906, CAT module 102 releases the call via ISUP REL message with various release causes (busy, no answer, non-reachable etc). This triggers the corresponding CAMEL events (ERB) from VMSC 122 to CAT module 102.
FIG. 10 represents a flow diagram for testing CAMEL Call Information Request and Report operation for the simulated outbound roamer at the roaming partner PMN's MSC-RNLR-R 122, in accordance with an embodiment of the present invention. In order to test the CAMEL Call Information Request and Report operation, CAT module 102 follows on from the steps of FIG. 4, when CAT module 102 receives the IDP (at step 406), CAT module 102, at step 1002, requests Call Information Report (CIR) and then Continue. At step 1004, CAT module 102 receives an ISUP (CAT#) with FTN being set to CAT#. Thereafter, at step 1006, CAT module 102 answers it via ISUP ANM. After certain time period, at step 1008, CAT module 102 then issues an ISUP REL message that triggers a CAMEL Call Information Report from VMSC-122 to CAT module 102. CAT module then verifies its report parameters against its expectation (e.g. duration matching etc.) to confirm this CAMEL capability test.
FIG. 11 represents a flow diagram for testing CAMEL Apply Charging operation for the simulated outbound roamer at the roaming partner PMN MSC-R/VLR-R 122, in accordance with an embodiment of the present invention. In order to test the CAMEL Apply Charging operation, CAT module 102 follows on from the steps of FIG. 4, when CAT module 102 receives the IDP (at step 406), CAT module 102, at step 1102, requests Apply Charging (AC) with report interval and maximum duration release option and then Continue. At step 1104, CAT module 102 receives an ISUP (CAT#) message with the FTN set to as CAT#, routable to CAT module 102 via ISUP signaling. Thereafter, at step 1106, CAT module 102 responds to this message via an ISUP ANM message. At step 1108, after each interval (as set in the Apply Charging Request message), CAT module 102 receives Apply Charging Report and is able to validate the details. Finally, at step 1110, when the total maximum duration (as set in the AC Request) is reached, CAT module 102 receives an ISUP REL message to release the call.
FIG. 12 represents a flow diagram for testing CAMEL Furnish Charge Information (FCI) on Event Reports on ANSWER and DISCONNECT operation for the simulated outbound roamer at the roaming partner PMN MSC-R/VLR-R 122, in accordance with an embodiment of the present invention. In order to test the CAMEL Furnish Charge Information (FCI) on Event Reports on ANSWER and DISCONNECT operation, CAT module 102 follows on from the steps of FIG. 4, when CAT module 102 receives the IDP (at step 406), CAT module 102, at step 1202, requests the Event reports (RRB) on ANSWER and DISCONNECT and then CONTINUE. At step 1204, CAT module 102 receives an ISUP (CAT#) message with FTN as CAT#. Thereafter, at step 1206, CAT module 102 answers it via an ISUP ANM message, which triggers a CAMEL ANSWER event ERB from VMSC-R 122 to CAT module 102. Subsequently, at step 1208, CAT module 102 issues an FCI message to register initial accounting at VLR-R 122. After certain duration is passed, at step 1210, CAT module 102 issues an ISUP REL message, which triggers a CAMEL DISCONNECT event ERB from VMSC-R 122 to CAT module 102. Finally, at step 1212, CAT module 102 again issues an FCI message to register the final accounting at VLR-R 122. The formats and details are checked when club PMN 104 (i.e., HPMN 104) receives TAP files from VPMN 120.
FIG. 13 represents a flow diagram for testing interaction of MAP PSI location and subscriber state with CAMEL operation for the simulated outbound roamer at the roaming partner PMN MSC-R/VLR-R 122, in accordance with an embodiment of the present invention. In order to test interaction of MAP PSI location with CAMEL operation, CAT module 102 follows on from the steps of FIG. 4, when CAT module 102 receives the IDP (at step 406). Thereafter, CAT module 102, at step 1302, issues a MAP PSI message on the outbound roamer's IMSI on location. If at step 1304, the PSI returns the same VLR location as that of the IDP, then CAT module 102, at step 1306, issues a CAP Continue message in response to the IDP message. Then at step 1308, CAT module 102 receives an ISUP IAM (CAT#) message with FTN as CAT#. Otherwise, at step 1310, CAT module 102 issues a CAP Release Call message in response to the IDP message; then CAT module 102 receives an ISUP REL message at step 1312.
Similarly, in order to test interaction of MAP PSI subscriber state with CAMEL operation, CAT module 102, at step 1302, issues a MAP PSI on the outbound roamer's IMSI on state. If at step 1304, the PSI returns the same subscriber state (i.e. unreachable) as that of the IDP for the trigger reason, then CAT module 102 at step 1306, issues a CAP Continue message in response to the IDP message. Then at step 1308, CAT module 102 receives an ISUP (CAT#) with FTN as CAT#. Otherwise, at step 1310, CAT module 102 issues a CAP Release Call message in response to the IDP message; then CAT module 102 receives an ISUP REL message at step 1312.
FIG. 14 represents a flow diagram for testing interaction of MAP barring all calls and messages (including international calls messages) with CAMEL operation for the simulated outbound roamer at the roaming partner PMN MSC-RNLR-R 122, in accordance with an embodiment of the present invention. In this figure three embodiments are covered.
In first embodiment, CAT module 102 tests interactions of MAP Barring All
Outgoing Calls messages (BAOC) with CAMEL operation. CAT module 102 follows on from the steps of FIG. 4, at step 1402 CAT module 102 sends an ISD message to modify the outbound roamer's profile of BAOC either with Supplementary Service or Call Barring (SS or CB) or ODB (Operator Determined Barring). At step 1404, CAT module 102 receives an IDP message. Thereafter, at step 1406, it issues a CAP Connect (local#) message, where local# is a local number in VPMN 120. Finally, at step 1408, CAT module 102 receives and ISUP REL message.
In second embodiment, CAT module 102 tests interactions of MAP Barring All International Calls messages (BAIC) with CAMEL operation. In this embodiment, steps 1402 and 1404 remain same as the first embodiment, where CAT module 102 receives the IDP message. Thereafter, at step 1406, CAT module 102 can either issue CAP Connect (local#) message, where local# is a local known answerable number in VPMN 120 country. In that case, CAT module 102 receives an ISUP ANM message at step 1408. In an alternative case, at step 1406, CAT module 102 issues a CAP Connect (CAT#) message, where CAT# is an international number from VPMN 120 country. In that case, at step 1408, CAT 102 receives and ISUP REL message.
In third embodiment, CAT module 102 tests interactions of MAP Barring All International Calls except home message (BAIC-Ex Home) with CAMEL operation. In this embodiment again, steps 1402 and 1404 remain same as the first and second embodiment, where CAT module 102 receives the IDP message. Thereafter, at step 1406, CAT module 102 can either issue a CAP Connect (home#) message, where home# is a home known answerable number in HPMN 104 country. In that case, CAT module 102 receives an ISUP ANM message. In an alternative case, at step 1406, CAT module 102 issues a CAP Connect (3^rdCountry#) message, where 3^rdCountry# is an answerable non-HPMN country international number from VPMN 120 country. In that case, at step 1408, CAT module 102 receives an ISUP REL message.
FIG. 15 represents a flow diagram for testing interaction of MAP PRN with Suppression of Announcement (SoA) with CAMEL operation for the simulated outbound roamer at the roaming partner PMN MSC-R/VLR-R 122, in accordance with an embodiment of the present invention. In order to test MAP PRN with Suppression of Announcement (SoA) with CAMEL operation, CAT module 102 follows on from the steps of FIG. 4, where at step 1502, CAT module 102 sends PRN message contains SoA, and receives the IDP message, at step 1504. This implies that call forwarding is about to take place. CAT module 102 does not expect any announcement before receiving IDP. At step 1506, CAT module 102 can also issue Connect/Continue/Release Call and should not expect any announcement (whether it is connecting to a new number, continuing on the original FTN or releasing the call). In order to carry out this test case, CAT module 102 needs a voice detection element to hear the announcements.

CAT Test Procedures for Inbound Roamers

It will be apparent to a person skilled in the art that inbound testing with club member is same as outbound testing and in the present invention only inbound testing with roaming partners is considered. Since HPMN has the liability, HPMN can dictate the set of tests required. In case of inbound testing, HPMN is roaming partner PMN 120, while club member, i.e., club PMN 104 becomes the VPMN. This means roaming partners will control the service logic and acceptable results. However, CAT module 102 can still create the preconditions and actions of many IR. 32 test cases for roaming partner's service logics. CAT module 102 will additionally include a voice recognition capability to determine success or failure of the tests.
In various implementations of the inbound testing cases, the present invention does not require physical SIMs, or service logics from roaming partners. However it uses the various IMSI profiles from the roaming partners. The roaming partners are required to only do the IR. 21 configurations and routing.
FIG. 16 represents a flow diagram for creating profile for a simulated inbound roamer from a roaming partner PMN 120, at MSC-C/VLR-C 106 in a club PMN 104, using CAT module 102, in accordance with an embodiment of the present invention. In this embodiment, the standard procedure for creating a virtual inbound roamer is used, except that such a roamer will have various camel profiles based on the SIMs or IMSIs provided by the HPMN to the VPMN (i.e., the club member in this case). CAT module 102, first creates fake roamer's (IMSI-x) location and validates the same with HLR-R 132 of roaming PMN 120, using LUP, ISD and LUP-ACK messages between steps 1602 and 1608. CAT module 102 also validates if the inbound roamer has the right camel profile to be tested by sending signaling messages such as a MAP Provide_Roaming_Number (PRN), a MAP Insert Subscriber Data (ISD) and a MAP_RESTORE_DATA (RSD)-ACK on the test IMSIs to the MSC/VLR of club PMN 104 (e.g., MSC-CIVLR-C 106). Hence, at step 1610, CAT module 102 sends MAP PRN message to VLR-C 106. Thereafter, at step 1612, VLR-C 106 triggers a MAP RestoreData (RSD) to CAT module 102 which then relays the request to the HLR-R 132. CAT module 102 can modify profile messages as it relays from HLR-R 132 to VPMN VLR-C 106. Finally, at step 1614, CAT module 102 also obtains the MSRN (Mobile Station Roaming Number) for subsequent call tests in response to the PRN message to VLR-C 106.
Once the inbound roamer's profile is created and validated at club PMN 104, in order to test various CAMEL capability tests, service logics etc. of IR. 32 specification is followed. CAT module 102 automates the requirements laid out in IR. 32 specification on behalf of the club member networks.
In order to validate IDP parameters in CAMEL trigger of the simulated inbound roamer, following table provides the IDP test case as per IR. 32 with pre-condition, action, service logic and expected results and some comments.


Preconditions:	MS₁(a) has location updated successfully in VPLMN(b). HLR
	entry for MS₁(a) contains “O-CSI”. [Set by HLR Admin]
Action:	MS₁(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.

FIG. 17 represents a flow diagram for validating IDP parameters in CAMEL trigger of the simulated inbound roamer, in accordance with an embodiment of the present invention. In this embodiment, CAT module 102 first simulates the effects of an inbound roamer ‘a’ making a test call to testNr1, through ISD and IAM messages as shown by steps 1702 to 1706. Although CAT module 102 is not involved with CAP signaling as the service logic is defined by roaming partner network 120, CAT module 102 still examines whether tests are successful or not based on whether it hears “success” or “failure” in the test result, since CAT module 102 simulates a calling device and contains a voice recognition unit. Hence, at step 1708, when the VLR-C 106 sends the IDP message with all parameters, then according to IR.32 IDP service logic, the SCP-R 130 when intercepts all these parameters, alters the destination address to Test Announcement 1. Thereafter, at step 1710, if CAT module 102 hears success in the Answer message, the IDP parameters in CAMEL trigger are validated.
In order to test CAMEL CONNECT operations for the simulated inbound roamer, following table provides the test case as per IR. 32 with pre-condition, action, service logic and expected results and some comments.

In order to test CAMEL CONTINUE operation for the simulated inbound roamer, following table provides the test case as per IR. 32 with pre-condition, action, service logic and expected results and some comments.


Preconditions:	MS₁(a) and MS₃(b) have location updated successfully in
	VPLMN(b). HLR entry for MS₁(a) contains “O-CSI”. [Set by HLR Admin]
Action:	MS₁(a) attempts a call to MS₃(b). MS₃(b) accepts the call
	and the call is established. Later MS₃(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 MS₃(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 MS₃(b) has
	disconnected the call. For this it is necessary to use a Protocol Analyser.
	This part of the test case is optional.

FIG. 18 represents a flow diagram for testing CAMEL CONNECT/CONTINUE operations for the simulated inbound roamer, in accordance with an embodiment of the present invention. In order to test CAMEL CONNECT operation, CAT module 102 first simulates the effects of an inbound roamer ‘a’ making a test call to testNr1, through ISD and IAM messages as shown by steps 1802 to 1806. Although CAT module 102 is not involved with CAP signaling as the service logic is defined by roaming partner network 120, CAT module 102 still examines whether tests are successful or not based on whether it hears “success” or “failure” in the test result, since CAT module 102 simulates a calling device and contains a voice recognition unit. Hence, at step 1808, when the VLR-C 106 sends the IDP message with all parameters, then according to IR.32 CONNECT service logic, the SCP-R 130 intercepts all these parameters and alters the destination address to Test Announcement 1. Thereafter, at step 1810, if CAT module 102 hears “success” in the Answer message, the CAMEL CONNECT operation is validated.
In order to test CAMEL CONTINUE operation, CAT module 102 first simulates the effect of an inbound roamer ‘a’ making a test call to a local # (say b) or CAT#. Although CAT module 102 is not involved with CAP signaling as the service logic is defined by roaming partner network 120, CAT module 102 still examines whether tests are successful or not based on whether it hears “success” or “failure” of the test result, as CAT module 102 simulates a calling device and contains a voice recognition unit. Hence in this case, at step 1808, when the VLR-C 106 sends the IDP message with all parameters, then according to IR.32 CONTINUE service logic, CAT module 102 creates an effect that called party (i.e. b) answered the call and then CAT module 102 sends a RELEASE message to disconnect the call. Hence, the CAMEL CONNECT operation is validated.
In order to test CAMEL DCH-CONTINUE/RELEASE operations for the simulated inbound roamer, following tables provide the test case as per IR. 32 with pre-condition, action, service logic and expected results and some comments.

IR.32 DCH Continue Operation


Preconditions:	MS₁(a) has location updated successfully in VPLMN(b).
	HLR record of MS₁(a) contains O-CSI with parameter
	defaultCallHandling set to continueCall. [Set by HLR Admin]
Action:	MS₁(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.
Result:	Successful result if Test Announcement 1 is played to calling party.
Comments:	This test case 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.

IR.32 DCH RELEASE Operation


Preconditions:	MS₂(a) has location updated successfully in VPLMN(b).
	HLR record of MS₂(a) contains O-CSI with parameter
	defaultCallHandling set to releaseCall.
	[Set by HLR Admin]
Action:	MS₂(a) attempts a call to AAC2.
Service logic:	IDP.calledPartyBCDNumber equals AAC2:
	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.

FIG. 19 represents a flow diagram for testing CAMEL DCH CONTINUE/RELEASE operations for the simulated inbound roamer, in accordance with an embodiment of the present invention. In order to test CAMEL DCH CONTINUE operation, CAT module 102 first simulates the effects of an inbound roamer ‘a’ making a test call to expected answer number AAC1, through ISD and IAM messages as shown by steps 1902 to 1906. Although CAT module 102 is not involved with CAP signaling as the service logic is defined by roaming partner network 120, CAT module 102 still examines whether tests are successful or not based on whether it hears “success” or “failure” of the test result, as CAT module 102 simulates a calling device and contains a voice recognition unit. Hence in this case, at step 1908, when the VLR-C 106 sends the IDP message with all parameters, then according to IR.32 DCH-CONTINUE service logic, the SCP-R 130 when intercepts all these parameters alters the destination address to Test Announcement 1. Thereafter, at step 1910, if CAT module 102 hears “success” in the Answer message, the CAMEL DCH-CONTINUE operation is validated.
Likewise, in order to test CAMEL DCH RELEASE operation, CAT module 102 first simulates the effects of an inbound roamer making a test call to expected answer number AAC2. In this case, according to IR.32 service logic for DCH RELEASE operation, if CAT module 102 receives a RELEASE message without hearing “success” for Test Announcement 2, then DCH RELEASE operation is considered validated. Else if CAT module 102 receives an Answer, then the test operated is considered to be failed.
In order to test MAP PSI subscriber unreachable/busy operations for the simulated inbound roamer, following tables provide the test case as per IR. 32 with pre-condition, action, service logic and expected results and some comments.

IR.32 PSI Unreachable Test


Preconditions:	MS₁(a) and MS₂(a) have location updated successfully in
	VPLMN(b). HLR entry for MS₁(a) contains “O-CSI”.
	[Set by HLR Admin]
	MS₂(a) is unreachable.
Action:	MS₁(a) attempts a call to MS₂(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 MS₂(a).
	(i) If subscriber state in Any Time Interrogation Result
	equals unreachable, 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.

IR.32 PSI Busy Test


Preconditions:	MS₁(a) and MS₂(a) have location updated successfully in
	VPLMN(b). HLR entry for MS₁(a) contains “O-CSI”.
	[Set by HLR Admin]
	MS₂(a) is busy.
Action:	MS₁(a) attempts a call to MS₂(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 MS₂(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.

FIG. 20 represents a flow diagram for testing interaction of MAP PSI subscriber Unreachable/Busy operation for the simulated inbound roamer, in accordance with an embodiment of the present invention. In order to test interaction of MAP PSI subscriber Unreachable operation, CAT module 102 first simulates the effects of an inbound roamer (say a) making a test call to another inbound roamer (say b), wherein one roamer's FTN points to the other roamer. In other words, FTN of roamer b points to MSRN of roamer a. This is represented in FIG. 20 through ISD and IAM messages as shown at steps 2002 to 2010. Now, when SCP-R 130 is checking the subscriber state of the second inbound roamer b, the roamer b is in unreachable state. SCP-R 130 answers the call based on the subscriber state. Although CAT module 102 is not involved with CAP signaling as the service logic is defined by roaming partner network 120, CAT module 102 still examines whether it hears “success” or “failure” of the test result. Hence, in this case, at step 2012, when the VLR-C 106 sends the IDP message with all parameters, then according to IR.32 MAP PSI Unreachable test logic, if the subscriber state in ATI result equals unreachable, then SCP-R 130 alters the destination address to Test Announcement 1. Thereafter, at step 2014, if CAT module 102 hears “success” in the Answer message, the CAMEL MAP PSI Unreachable operation is validated.
Likewise, in order to test interaction of MAP PSI subscriber BUSY operation, CAT module 102 first simulates the effects of an inbound roamer ‘a’ making a test call to another inbound roamer ‘b’, such that the roamer ‘b’ is shown busy by creating the roamer's FTN point to the other number. As this other number is determined by roaming partner network 120, it can arrange to have the other number always busy. When SCP-R 130 is checking the subscriber state of the second number, the number comes as busy. SCP-R 130 is expected to answer the call based on the subscriber state. Although CAT module 102 is not involved with CAP signaling, CAT module 102 still examines whether it hears “success” or “failure” of the test result. Hence in this case, at step 2012, when the VLR-C 106 sends the IDP message with all parameters, then according to IR.32 MAP PSI Busy test logic, if the subscriber state in ATI result equals busy, then SCP-R 130 alters the destination address to Test Announcement 1. Thereafter, at step 2014, if CAT module 102 hears “success” in the Answer message, the CAMEL MAP PSI busy operation is validated.
In accordance with an embodiment of the present invention, if HPMN can change the PSI testing on busy to PSI testing on network unreachable, then this test or mobile usage can be eliminated. Just like call forwarding on busy is optional, the PSI testing on busy can be optional too and just PSI testing on network unreachable state should be sufficient. Otherwise, the usage of mobile can just be set up once for all club members' PSI busy test at any place while CAT module 102 can still test against all switches and VLRs of club members. If there is an automated tool such as “Sigos” or “Datamat” to set up such a busy call on roamer ‘b,’, then it is simpler.
In order to test Event ANSWER/DISCONNECT operation for the simulated inbound roamer, following table provides the test case as per IR. 32 with pre-condition, action, service logic and expected results and some comments.


Preconditions:	MS₁(a) has location updated successfully in VPLMN(b).
	HLR entry for MS₁(a) contains “O-CSI”. [Set by HLR Admin]
Action:	MS₁(a) attempts a call to TestNbr2 and waits until the call is disconnected.
Service logic:	IDP.calledPartyBCDNumber consists of TestNbr2:
	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.
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.

FIG. 21 represents a flow diagram for testing Event ANSWER/DISCONNECT operation for the simulated inbound roamer, in accordance with an embodiment of the present invention. In order to test Event ANSWER/DISCONNECT operation, CAT module 102 first simulates the effects of an inbound roamer (say a) making a test call to test Nr2, through ISD and IAM messages as shown at steps 2102 to 2106. Although CAT module 102 is not involved with CAP signaling as the service logic is defined by roaming partner network 120, CAT module 102 still examines whether it hears “success” or “failure” of the test result. Hence in this case, at step 2108, when the VLR-C 106 sends the IDP message with all parameters, then according to IR.32 MAP RELEASE Call logic, SCP-R 130 alters the destination address to Test Announcement 1. Thereafter, at step 2110, if CAT module 102 hears “success” in the Answer message, and the call is released after 10 seconds, then CAMEL Event ANSWER/DISCONNECT operation is validated.
In order to test Call Forwarding on Unreachable/No-answer operation for the simulated inbound roamer, following table provides the test case as per IR. 32 with pre-condition, action, service logic and expected results and some comments.


Preconditions:	MS₁(a) and MS₃(b) have location updated successfully in
	VPLMN(b). HLR entry for MS₁(a) contains “O-CSI”. [Set by HLR Admin]
	MS₁(a) has activated CFNRy to destination number of Test Announcement 3.
Action:	MS₃(b) attempts a call to MS₁(a). MS₁(a) does NOT
	answer the call and MS₃(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.
	(ii) If Test Announcement 2 is played to calling party, at
	least one 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.

FIG. 22 represents a flow diagram for testing Call Forwarding on Unreachable/No-answer operation for the simulated inbound roamer, in accordance with an embodiment of the present invention. CAT module 102 first simulates the effects of roamer ‘b’ making a call to the inbound roamer ‘a’ which is then forwarded to AAC3 based on conditions of unreachable or no-answer, through ISD and IAM messages as shown at steps 2202 to 2206. Although CAT module 102 is not involved with CAP signaling, CAT module 102 still examines whether it hears “success” or “failure” of the test result. Hence in this case, at step 2208, when the VLR-C 106 sends the IDP message with all parameters, then according to IR.32 Call forwarding logic, SCP-R 130 alters the destination address to Test Announcement 1. Thereafter, at step 2210, if CAT module 102 hears “success” in the Answer message, then Call Forwarding on Unreachable/No-answer operation is validated.
In order to test SS/ODB call barring operation for the simulated inbound roamer, following tables provide the test case as per IR. 32 with pre-condition, action, service logic and expected results and some comments.

IR.32 Test Case for Call Baring Operation


Preconditions:	MS₁(a) has location updated successfully in VPLMN(b).
	HLR entry for MS₁(a) contains
	“O-CSI”. [Set by HLR Admin]
	“SS:BOICexHC:Active”. [Set by MS]
Action:	MS₁(a) attempts a call to TestNbr3.
Service logic:	IDP.calledPartyBCDNumber consists of TestNbr3:
	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.

IR.32 Test Case for ODB Operation


Preconditions:	MS₂(a) has location updated successfully
	in VPLMN(b).
	HLR entry for MS₂(a) contains
	“O-CSI”. [Set by HLR Admin]
	“ODB-BOICexHC: Active”. [Set by HLR Admin]
Action:	MS₂(a) attempts a call to TestNbr3.
Service logic:	IDP.calledPartyBCDNumber consists of TestNbr3:
	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
	ODB-BOICexHC in case of mobile originated calls.

FIG. 23 represents a flow diagram for testing SS/ODB call barring operation for the simulated inbound roamer, in accordance with an embodiment of the present invention. In order to test SS call baring operation, CAT module 102 first simulates the effects of an inbound roamer ‘a’ making a call to test Nr3 where the inbound roamer's SS call barring is defined on barring all international calls except home, through ISD and IAM messages as shown at steps 2302 to 2306. Although CAT module 102 is not involved with CAP signaling, CAT module 102 still examines whether tests are successful or not based on whether it receives release or answer, since CAT simulates a calling device. Hence in this case, at step 2308, when the VLR-C 106 sends the IDP message with all parameters, then according to IR.32 SS/ODB call baring logic, SCP-R 130 alters the destination address to a number located in country ‘c’. In order to test ODB call baring operation, CAT module 102 simulates the effects of an inbound roamer making a call to testNr3 where the inbound roamer's ODB call barring is defined on barring all international calls except home, through ISD and IAM messages as shown at steps 2302 to 2306. In this case, CAT module 102 determines if the tests are successful if it receives Release call, at step 2310, and does not hear any announcement or hears barring announcement.
In order to test IDP Phase 2 operation for the simulated inbound roamer, following table provides the test case as per IR. 32 with pre-condition, action, service logic and expected results and some comments.


Preconditions:	MS₄(a) has location updated successfully in VPLMN(b). HLR
	entry for MS₄(a) contains “O-CSI, DestinationNumberLengthList = 4,
	enabling”. [Set by HLR Admin]
Action:	MS₄(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.
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. 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.

FIG. 24 represents a flow diagram for testing IDP Phase 2 operation for the simulated inbound roamer, in accordance with an embodiment of the present invention. CAT module 102 first simulates the effects of an inbound roamer ‘a’ making a call to testNr4#, through ISD and IAM messages as shown at steps 2402 to 2406. Although CAT module 102 is not involved with CAP signaling, CAT module 102 still examines whether it hears “success” or “failure” of the test result. Hence in this case, at step 2408, when the VLR-C 106 sends the IDP message with all parameters, then according to IR.32 IDP Phase 2 logic, SCP-R 130 alters the destination address to Test Announcement 1. Thereafter, at step 2410, if CAT module 102 hears “success” in the Answer message, then IDP Phase 2 operation is validated.
In order to test FCI on No-Answer, Unreachable, Busy and Route-Select-Failure operation for the simulated inbound roamer, following tables provide the test case as per IR. 32 with pre-condition, action, service logic and expected results and some comments.

IR.32 Test Case for FCI No-Answer Operation


Preconditions:	MS₅(a) and MS₃(b) have location updated successfully in
	VPLMN(b). HLR entry for MS₅(a) contains “O-CSI”. [Set by HLR Admin]
	No GSM CF is active for MS₃(b).
Action:	MS₅(a) attempts a call to MS₃(b). MS₃(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, 15 sec], [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
	(40 byte FreeFormat(octet-string), legID = 1) + CON(AAC1)
Result:	Successful result if Test Announcement 1 is played to calling party.
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.

IR.32 Test Case for FCI Busy Operation


Preconditions:	MS₅(a) and MS₃(b) have location updated successfully in
	VPLMN(b). HLR entry for MS₅(a) contains “O-CSI”. [Set by
	HLR Admin]. MS₃(b) is engaged in a call and therefore busy.
Action:	MS₅(a) attempts a call to MS₃(b).
Service logic:	CC + NDC of IDP.calledPartyBCDNumber differs from CC +
	NDC of country (a): SCF sends RRBE ([O_NoAnswer,
	Interrupted, leg2, 15 sec], [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 (40 byte
	FreeFormat(octet-string), leg1) + CON(AAC1)
Result:	Successful result if Test Announcement 1 is played to calling party.
Comments:	This test case checks arming and correct reporting of EDP-R5, O_Busy
	with indication of busy.
	The charging information may optionally contain a cause value
	indicating the reconnect was due to busy.

IR.32 Test Case for FCI Route-Select-Failure Operation


Preconditions:	MS₅(a) and MS₃(b) have location updated successfully in
	VPLMN(b). HLR entry for MS₅(a) contains “O-CSI”. [Set by
	HLR Admin]. MS₃(b) is switched off and therefor not reachable (detached).
Action:	MS₅(a) attempts a call to MS₃(b).
Service logic:	CC + NDC of IDP.calledPartyBCDNumber differs from CC +
	NDC of country (a): SCF sends RRBE ([O_NoAnswer,
	Interrupted, leg2, 15 sec], [O_Busy, Interrupted, leg2],
	[Route_Select_Failure, Interrupted, leg2]) + CUE.
	After reception of ERB(O_Busy, BusyCause = not reachable)) SCF
	sends transparent charging information through FCI and
	reconnects to AAC1. FCI (40 byte FreeFormat(octet-string), leg1) +
	CON(AAC1)
Result:	Successful result if Test Announcement 1 is played to calling
	party.
Comments:	This test case checks arming and correct reporting of EDP-R5,
	O_Busy with indication of not reachable.
	The charging information may optionally contain a cause value
	indicating the reconnect was due to not reachable.

FIG. 25 represents a flow diagram of testing FCI on No-Answer, Unreachable, Busy and Route-Select-Failure operations for the simulated inbound roamer, in accordance with an embodiment of the present invention.
In order to test FCI on No-answer operation, CAT module 102 simulates the effects of an inbound roamer ‘a’ making a call to a local mobile that is not answering, through ISD and IAM messages as shown at steps 2502 to 2506. In the case, CAT module 102 faking the local mobile. Roaming partner network's 120 service logic is expected to request no-answer event and continue the call. At step 2508, CAT module 102 receives an IAM message. At step 2510, CAT module 102 release the call with a cause (NO-ANSWER) as it is faking the local mobile. HPMN service logic expects to connect the inbound roamer call to AAC1. Although CAT module 102 is not involved with CAP signaling, CAT module 102 still examines whether tests are successful or not based on whether it hears “success” or “failure” of the test result. The charging action can be used to verify TAP information.
Similarly, for testing FCI on Busy/Unreachable/Route-select-failure operation, CAT module 102 again simulates the effects of an inbound roamer ‘a’ making a call to a local mobile that is busy or not reachable or not routable in VPMN. In the case, CAT module 102 is faking the local mobile. HPMN service logic is expected to request busy/unreachable/route-selection-failure event and continue the call. In this case to, when CAT module 102 receives an IAM message, it releases it with a cause (busy/unreachable/not routable) as it is faking the local mobile. Although CAT module 102 is not involved with CAP signaling, it still examines whether tests are successful or not based on whether it hears “success” or “failure” of the test result.
In order to test reporting accuracy, credit balance accuracy and tariff switching for Call Information (CI) request and report, Send Charging Information (SCI) and Apply Charging request and report, operations for the simulated inbound roamer, following tables provide the test case as per IR. 32 with pre-condition, action, service logic and expected results and some comments.

IR.32 Test Case for Reporting Accuracy for CI, SCI and AC Operation


Preconditions:	MS₄(a) has location updated successfully in VPLMN(b).
	HLR entry for MS₄(a) contains “O-CSI”. [Set by HLR Admin]
Action:	MS₄(a) attempts a call to TestNbr5.
Service logic:	IDP.calledPartyBCDNumber consists of TestNbr5:
	The SCF alters the destination address to be that of Test
	Announcement 5 and sends CIReq + SCI + AC(CPD = 5 sec,
	TSI = 1 sec) + RRBE(disconnect-interruptMode) + CON. After the
	first ACR is received AC(CPD = 5 sec), after the second ACR
	SCI + AC(CPD = 5 sec, TSI = 2 sec) and after the third ACR
	AC(CPD = 3600 sec) is sent. AAC5 disconnects in 30 s
	(i) When SCF has received ERB and if the correct call
	periods within the ACRs and the correct
	callConnectedElapsedTime = TSI_ACR+ 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 MS₄(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:

IR.32 Test Case for Tariff Switching for CI, SCI and AC Operation


Preconditions:	MS₄(a) has location updated successfully in VPLMN(b). HLR
	entry for MS₄(a) contains “O-CSI”. [Set by HLR Admin]
Action:	MS₄(a) attempts a call to TestNbr7.
Service logic:	IDP.calledPartyBCDNumber consists of TestNbr7:
	The SCF alters the destination address to be that of Test
	Announcement 5 and sends CIReq + AC(CPD = 15 sec,
	TSI-10 sec) + RRBE(disconnect, interruptMode) + CON. After
	reception of ACR AC(CPD = 86400 sec, TSI = 86390 sec) is sent.
	AAC5 disconnects after 30 s
	(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.
	(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 TSI_ACR+
	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:

IR.32 Test Case for Credit Balance for CI, SCI and Ac Operation


Preconditions:	MS₄(a) has location updated successfully in VPLMN(b). HLR
	entry for MS₄(a) contains “O-CSI”. [Set by HLR Admin]
Action:	MS₄(a) attempts a call to TestNbr6.
	Check if a warning tone is played to calling party after about 10 seconds.
Service logic:	IDP.calledPartyBCDNumber consists of TestNbr6:
	The SCF alters the destination address to be that of Test
	Announcement
3 and sends AC(CPD = 40 sec, RIDE.Tone) and
	CON.
Result:	Successful result if warning tone is heard and 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.

FIG. 26 represents a flow diagram of testing reporting accuracy, credit balance accuracy and tariff switching for CI request and report, SCI and AC request and report, operations for the simulated inbound roamer, in accordance with an embodiment of the present invention. CAT module 102 first simulates the effects of an inbound roamer making a call to the number test Nr5, through ISD and IAM messages as shown at steps 2602 to 2606. Although CAT module 102 is not involved with CAP signaling, CAT module 102 still examines whether tests are successful or not based on whether it hears “success” after about 30 secs or “failure” of the test result since CAT module 102 simulates a calling device with voice recognition unit.
Similarly, while determining tariff switching accuracy test, CAT module 102 examines whether tests are successful or not based on whether it hears “success” after about 30 secs or failure of the test result. Likewise, while determining credit balance accuracy, CAT module 102 examines whether tests are successful or not based on whether it hears “success” after about 10 secs and call is released after about 40 secs or failure of the test result.
In order to test interaction of ETC (Establish Temporary Connection), ARI (Assist Resource Instruction), CTR (ConnectToResource) and PA (Prompt Announcement) operations for the simulated inbound roamer, following table provides the test case as per IR. 32 with pre-condition, action, service logic and expected results and some comments.
FIG. 27 represents a flow diagram of testing interaction of ETC, ARI, CTR and PA operations for the simulated inbound roamer, in accordance with an embodiment of the present invention. CAT module 102 simulates the effects of an inbound roamer making a call to the number testNr10, through ISD and IAM messages as shown at steps 2702 to 2706. Although CAT module 102 is not involved with CAP signaling, CAT module 102 can still examine whether tests are successful or not based on whether it hears HPMN announcement and then AAC1 is heard or failure of the test result.
It will be apparent to a person skilled in the art, that the present invention can also be applied to Code Division Multiple Access (CDMA)/American National Standards Institute #41 D (ANSI-41D), and various other technologies such as, but not limited to, VoIP, WiFi, 3GSM and inter-standard roaming. In one exemplary case, a CDMA outbound roamer travels with an HPMN CDMA handset. In another exemplary case, the CDMA outbound roamer travels with an HPMN GSM SIM and a GSM handset. In yet another exemplary case, GSM outbound roamer travels with an HPMN CDMA RUIM and a CDMA handset. To support these variations, CAT module 102 will have a separate SS7 and network interfaces, corresponding to both the HPMN and VPMN networks. It will also be apparent to a person skilled in the art that these two interfaces in different directions may not have to be the same technologies. Moreover, there could be multiple types of interface in both directions.
An exemplary list of the mapping between GSM MAP and ANSI-41D is described in the table below as a reference.


	GSM MAP	ANSI-41D

	Location Update/ISD	REGNOT
	Cancel Location	REGCAN
	RegisterSS	FEATUREREQUEST
	InterrogateSS	FEATUREREQUEST
	SRI-SM	SMSREQ
	SRI	LOCATION REQUEST
	ForwardSMS	SMSDPP
	ReadyForSMS	SMSNOTIFICATION
	AlertServiceCenter	SMSNOTIFICATION
	ReportSMSDelivery	SMDPP
	ProvideRoamingNumber	ROUTING REQUEST

The present invention can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment containing both hardware and software elements. In accordance with an embodiment of the present invention, software, including but not limited to, firmware, resident software, and microcode, implements the invention.
Furthermore, the invention can take the form of a computer program product, accessible from a computer-usable or computer-readable medium providing program code for use by, or in connection with, a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk-read only memory (CDROM), compact disk-read/write (CD-R/W) and Digital Versatile Disk (DVD).
The components of present system described above include any combination of computing components and devices operating together. The components of the present system can also be components or subsystems within a larger computer system or network. The present system components can also be coupled with any number of other components (not shown), such as other buses, controllers, memory devices, and data input/output devices, in any number of combinations. In addition, any number or combination of other processor-based components may be carrying out the functions of the present system.
It should be noted that the various components disclosed herein may be described using computer aided design tools and/or expressed (or represented), as data and/or instructions embodied in various computer-readable media, in terms of their behavioral, register transfer, logic component, transistor, layout geometries, and/or other characteristics. Computer-readable media in which such formatted data and/or instructions may be embodied include, but are not limited to, non-volatile storage media in various forms (e.g., optical, magnetic or semiconductor storage media) and carrier waves that may be used to transfer such formatted data and/or instructions through wireless, optical, or wired signaling media or any combination thereof.
Unless the context clearly requires otherwise, throughout the description and the claims, the words “comprise,” “comprising,” and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in a sense of “including, but may not be limited to.” Words using the singular or plural number also include the plural or singular number respectively. Additionally, the words “herein,” “hereunder,” “above,” “below,” and words of similar import refer to this application as a whole and not to any particular portions of this application. When the word “or” is used in reference to a list of two or more items, it covers all of the following interpretations: any of the items in the list, all of the items in the list and any combination of the items in the list.
The above description of illustrated embodiments of the present system is not intended to be exhaustive or to limit the present system to the precise form disclosed. While specific embodiments of, and examples for, the present system are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the present system, as those skilled in the art will recognize. The teachings of the present system provided herein can be applied to other processing systems and methods. They may not be limited to the systems and methods described above.
The elements and acts of the various embodiments described above can be combined to provide further embodiments. These and other changes can be made in light of the above detailed description.

Other Variations

Provided above for the edification of those of ordinary skill in the art, and not as a limitation on the scope of the invention, are detailed illustrations of a scheme for proactive roaming tests, discoveries of roaming partner services and discoveries of frauds in roaming using simulated roaming traffic. Numerous variations and modifications within the spirit of the present invention will of course occur to those of ordinary skill in the art in view of the embodiments that have been disclosed. For example, the present invention is implemented primarily from the point of view of GSM mobile networks as described in the embodiments. However, the present invention may also be effectively implemented on GPRS, 3G, CDMA, WCDMA, WiMax etc., or any other network of common carrier telecommunications in which end users are normally configured to operate within a “home” network to which they normally subscribe, but have the capability of also operating on other neighboring networks, which may even be across international borders.
The examples under the system of present invention detailed in the illustrative examples contained herein are described using terms and constructs drawn largely from GSM mobile telephony infrastructure. However, use of these examples should not be interpreted as limiting the invention to those media. The system and method can be of use and provided through any type of telecommunications medium, including without limitation: (i) any mobile telephony network including without limitation GSM, 3GSM, 3G, CDMA, WCDMA or GPRS, satellite phones or other mobile telephone networks or systems; (ii) any so-called WiFi apparatus normally used in a home or subscribed network, but also configured for use on a visited or non-home or non-accustomed network, including apparatus not dedicated to telecommunications such as personal computers, Palm-type or Windows Mobile devices; (iii) an entertainment console platform such as Sony Playstation, PSP or other apparatus that are capable of sending and receiving telecommunications over home or non-home networks, or even (iv) fixed-line devices made for receiving communications, but capable of deployment in numerous locations while preserving a persistent subscriber id such as the eye2eye devices from Dlink; or telecommunications equipment meant for voice over IP communications such as those provided by Vonage or Packet8.
In describing certain embodiments of the system under the present invention, this specification follows the path of a telecommunications call, from a calling party to a called party. For the avoidance of doubt, such a call can be a normal voice call, in which the subscriber telecommunications equipment is also capable of visual, audiovisual or motion-picture display. Alternatively, those devices or calls can be for text, video, pictures or other communicated data.
In the foregoing specification, specific embodiments of the present invention have been described. However, one of ordinary skill in the art will appreciate that various modifications and changes can be made without departing from the scope of the present invention as set forth in the claims below. Accordingly, the specification and the figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of present invention. The benefits, advantages, solutions to problems, and any element(s) that may cause any benefit, advantage, or solution to occur, or to become more pronounced, are not to be construed as a critical, required, or essential feature or element of any or all of the claims.

APPENDIX

Acronym	Description

3G	Third generation of mobile
ACM	ISUP Address Completion Message
ANM	ISUP Answer Message
ANSI-41	American National Standards Institute #41
ATI	Any Time Interrogation
BCSM	Basic Call State Model
BSC	Base Station Controller
BOIC	Barring Outgoing International Calls
BOIC-EX-Home	Barring Outgoing International Calls except to home
	country
CAMEL	Customized Application for Mobile Enhanced Logic
CAP	Camel Application Part
CB	Call Barring
CC	Country Code
CDMA	Code Division Multiplexed Access
CdPA	Called Party Address
CDR	Call Detail Record
CF	Call Forwarding
CgPA	Calling Party Address
CIC	Circuit Identification Code
CLI	Calling Line Identification
CSD	Circuit Switched Data
CSI	Camel Subscription Information
DPC	Destination Point Code
DSD	Delete Subscriber Data
DTMF	Dual Tone Multi-Frequency
ERB	CAP Event Report Basic call state model
EU	European Union
FPMN	Friendly Public Mobile Network
FTN	Forward-To-Number
GLR	Gateway Location Register
GGSN	Gateway GPRS Support Node
GMSC	Gateway MSC
GMSC-F	GMSC in FPMN
GMSC-H	GMSC in HPMN
GPRS	General Packet Radio System
GSM	Global System for Mobile
GSMA	GSM Association
GSM SSF	GSM Service Switching Function
GsmSCF	GSM Service Control Function
GT	Global Title
GTP	GPRS Tunnel Protocol
HLR	Home Location Register
HPMN	Home Public Mobile Network
IN	Intelligent Network
IOT	Inter-Operator Tariff
GTT	Global Title Translation
IAM	Initial Address Message
IDP	Initial DP IN/CAP message
IDD	International Direct Dial
IMSI	International Mobile Subscriber Identity
IMSI-H	HPMN IMSI
IN	Intelligent Network
INAP	Intelligent Network Application Part
INE	Interrogating Network Entity
IP	Internet Protocol
IREG	International Roaming Expert Group
IRS	International Revenue Share
ISC	International Service Carrier
ISD	MAP Insert Subscriber Data
ISG	International Signal Gateway
IST	Immediate Service Termination
ISTP	International STP
ISTP-F	ISTP connected to FPMN STP
ISTP-H	ISTP connected to HPMN STP
ISUP	ISDN User Part
ITPT	Inbound Test Profile Initiation
ITR	Inbound Traffic Redirection
IVR	Interactive Voice Response
LU	Location Update
LUP	MAP Location Update
MAP	Mobile Application Part
MCC	Mobile Country Code
MCC	Mobile Country Code
MD	Missing Data
ME	Mobile Equipment
MGT	Mobile Global Title
MMS	Multimedia Message Service
MMSC	Multimedia Message Service Center
MMSC-F	FPMN MMSC
MMSC-H	HPMN MMSC
MNC	Mobile Network Code
MNP	Mobile Number Portability
MO	Mobile Originated
MOS	Mean Opinion Score
MS	Mobile Station
MSC	Mobile Switching Center
MSISDN	Mobile Station International Subscriber Directory
	Number
MSISDN-F	FPMN MSISDN
MSISDN-H	HPMN MSISDN
MSRN	Mobile Station Roaming Number
MSRN-F	FPMN MSRN
MSRN-H	HPMN MSRN
MT	Mobile Terminated
MTP	Message Transfer Part
NDC	National Dialing Code
NP	Numbering Plan
NPI	Numbering Plan Indicator
NRTRDE	Near Real Time Roaming Data Exchange
O-CSI	Originating CAMEL Subscription Information
OCN	Original Called Number
ODB	Operator Determined Barring
OPC	Origination Point Code
OR	Optimal Routing
ORLCF	Optimal Routing for Late Call Forwarding
OTA	Over The Air
OTPI	Outbound Test Profile Initiation
PDP	Protocol Data Packet
PDN	Packet Data Network
PDU	Packet Data Unit
PRN	MAP Provide Roaming Number
PSI	MAP Provide Subscriber Information
QoS	Quality of Service
RAEX	Roaming Agreement Exchange
RI	Routing Indicator
RIS	Roaming Intelligence System
RDN	Redirecting Number
RNA	Roaming Not Allowed
RR	Roaming Restricted due to unsupported feature
RRB	CAP Request Report Basic call state model
RSD	Restore Data
RTP	Real-Time Transport Protocol
SAI	Send Authentication Info
SC	Short Code
SCA	Smart Call Assistant
SCCP	Signal Connection Control part
SCP	Signaling Control Point
SF	System Failure
SG	Signaling Gateway
SGSN	Serving GPRS Support Node
SGSN-F	FPMN SGSN
SIM	Subscriber Identity Module
SIGTRAN	Signaling Transport Protocol
SME	Short Message Entity
SM-RP-UI	Short Message Relay Protocol User Information
SMS	Short Message Service
SMSC	Short Message Service Center
SMSC-F	FPMN SMSC
SMSC-H	HPMN SMSC
SoR	Steering of Roaming
SPC	Signal Point Code
SRI	MAP Send Routing Information
SRI-SM	MAP Send Routing Information For Short Message
SS	Supplementary Services
SS7	Signaling System #7
SSN	Sub System Number
SSP	Service Switch Point
STK	SIM Tool Kit Application
STP	Signal Transfer Point
STP-F	FPMN STP
STP-H	HPMN STP
TADIG	Transferred Account Data Interchange Group
TAP	Transferred Account Procedure
TCAP	Transaction Capabilities Application Part
VT-CSI	Visited Terminating CAMEL Service Information
TP	SMS Transport Protocol
TR	Traffic Redirection
TS	Traffic Steering
TT	Translation Type
UD	User Data
UDH	User Data Header
UDHI	User Data Header Indicator
USSD	Unstructured Supplementary Service Data
VAS	Value Added Service
VIP	Very Important Person
VLR	Visited Location Register
VLR-F	FPMN VLR
VLR-H	HPMN VLR
VLR-V	VPMN VLR
VMSC	Visited Mobile Switching Center
VoIP	Voice over IP
VPMN	Visited Public Mobile Network
ATI	Access Transport Information
UDV	Unexpected Data Value
USI	User Service Information
WAP	Wireless Access Protocol

Technical references, each of which is incorporated by reference in its entirety herein:

GSM 378 on CAMEL Digital Cellular telecommunications system (Phase 2+); Customized Applications for Mobile network Enhanced Logic (CAMEL) Phase 2; Stage 2 (GSM 03.78 version 6.7.0 Release 1997)
GSM 978 on CAMEL Application protocol Digital cellular telecommunications system (Phase 2+); Customized Applications for Mobile network Enhanced Logic (CAMEL); CAMEL Application Part (CAP) specification (GSM 09.78 version 7.1.0 Release 1998)
GSM 379 on CAMEL Digital cellular telecommunications system (Phase 2+); Customized Applications for Mobile network Enhanced Logic (CAMEL); CAMEL Application Part (CAP) specification (GSM 09.78 version 7.1.0 Release 1998)
GSM 318 on CAMEL Basic Call Handling; Digital cellular telecommunications system (Phase 2+) Basic call handling; Technical realization (GSM 03.18 version 6.6.0 Release 1997)
IREG 32
IREG 24
ITU-T Recommendation Q.1214 (1995), Distributed functional plane for intelligent network CS-1;
ITU-T Recommendation Q.1218 (1995), Interface Recommendation for intelligent network CS-1;
ITU-T Recommendation Q.762 (1999), Signaling system No. 7—ISDN user part general functions of messages and signals;
ITU-T Recommendation Q.763 (1999), Signaling system No. 7—ISDN user part formats and codes;
ITU-T Recommendation Q.764 (1999), Signaling system No. 7—ISDN user part signaling procedures;
ITU-T Recommendation Q.766 (1993), Performance objectives in the integrated services digital network application;
ITU-T Recommendation Q.765 (1998), Signaling system No. 7—Application transport mechanism;
ITU-T Recommendation Q.769.1 (1999), Signaling system No. 7—ISDN user part enhancements for the support of Number Portability
BA 19 GSMA RAEX on AA 14 and IR 21
FF 17 International Revenue Share Fraud

Claims

1. A method of facilitating roaming tests for a club network, the method comprising:

facilitating by a signaling gateway (SG), simulation of a roamer's profile and associating it with one of the club network and a roaming partner network of the club network; and

performing by the SG, one or more Customized Application for Mobile Enhanced Logic (CAMEL) capability tests on the roamer;

wherein the club network and the roaming partner network correspond to one of a Home Public Mobile Network (HPMN) and a Visited Public Mobile Network (VPMN); and

wherein the roaming subscriber is associated with one of the club network and the roaming partner network.

2. The method claim 1, wherein the SG is situated on network either inside the club network or outside the club network having a signalling connection to reach the club network, facilitating roaming tests for different club networks.

3. The method of claim 2, wherein the signalling connection comprises at least one of Signalling System 7 (SS7), Session Initiated Protocol (SIP) and Integrated Services Digital Network (ISDN) User Part (ISUP).

4. The method of claim 1, wherein the roamer is an outbound roamer of the club network, the club network being the HPMN and the roaming partner network being the VPMN.

5. The method of claim 4, wherein the outbound roamer's profile is simulated at the VPMN by creating a CAMEL profile of the roamer at the VPMN.

6. The method of claim 4, wherein the CAMEL profile is created by faking the outbound roamer's location at VPMN's VLR/VMSC.

7. The method of claim 4, wherein the CAMEL capability test comprises at least one of:

validating IDP parameters in CAMEL trigger;

testing CAMEL CONTINUE operation;

testing CAMEL CONNECT operation;

testing CAMEL Default Call Handling CONTINUE operation;

testing CAMEL Default Call Handling RELEASE operation;

testing CAMEL Release Call operation;

testing CAMEL Event Reports on ANSWER and DISCONNECT;

testing CAMEL Event Reports on BUSY, No ANSWER and Not-REACHABLE;

testing CAMEL Call Information Report operation;

testing CAMEL Apply charging operation;

testing CAMEL Furnish Charge Information on Event Reports on ANSWER and DISCONNECT;

testing interaction of MAP PSI on location with CAMEL operation;

testing interaction of MAP PSI on subscriber state with CAMEL operation;

testing interaction of MAP barring all call messages with CAMEL operation;

testing interaction of MAP barring all international calls with CAMEL operation; and

testing interaction of MAP PRN with Suppression of Announcement (SoA) with CAMEL operation.

8. The method of claim 1, wherein the roamer is an inbound roamer of the club network.

9. The method of claim 8, the club network being the VPMN and the roaming partner network being the HPMN.

10. The method of claim 8, wherein the inbound roamer's profile is simulated at the VPMN.

11. The method of claim 8, wherein the inbound roamer has one or more CAMEL profiles based on one or more IMSIs provided by the HPMN to the VPMN.

12. The method of claim 8, wherein the CAMEL capability test comprises at least one of:

validating IDP parameters in CAMEL trigger;

testing CAMEL CONNECT operation;

testing CAMEL CONTINUE operation;

testing CAMEL Default Call Handling CONTINUE operation;

testing CAMEL Default Call Handling RELEASE operation;

testing interaction of MAP PSI on subscriber state with CAMEL operation;

testing CAMEL Event Reports on ANSWER and DISCONNECT;

testing ODB call barring operation;

testing SS call barring operation;

testing CAMEL Furnish Charge Information on Event Reports on NO-ANSWER;

testing CAMEL Furnish Charge Information on Event Reports on BUSY;

testing CAMEL Furnish Charge Information on Event Reports on UNREACHABLE;

testing CAMEL Furnish Charge Information on Route-Selection Failure operation;

testing reporting accuracy of CI request and report, SCI and Apply charging request and report operation;

testing tariff switching accuracy of CI request and report, SCI and Apply charging request and report operation;

testing credit balance accuracy of CI request and report, SCI and Apply charging request and report operation; and

testing interaction of ETC (Establish Temporary Connection), ARI (Assist Resource Instruction), CTR (Connect To Resource) and PA (Prompt Announcement) operations.

13. A system for facilitating roaming tests for a club network, the system comprising:

a gateway associated with the club network for simulating a roamer's profile and associating it with one of: the club network and a roaming partner network of the club network;

wherein the gateway performs one or more Customized Application for Mobile Enhanced Logic (CAMEL) capability tests on the roamer;

14. The system of claim 13, wherein the roamer is an outbound roamer of the club network, the club network being the HPMN and the roaming partner network being the VPMN.

15. The system of claim 13, wherein the roamer is an inbound roamer of the club network, the club network being the VPMN and the roaming partner network being the HPMN.

16. The system of claim 13, wherein the gateway simulates the roamer's profile at the VPMN by faking the roamer's location at the VPMN's VLR/VMSC.

17. The system claim 13, wherein the SG is situated on a network either inside the club network or outside the club network having a signalling connection to reach the club network, facilitating roaming tests for different club networks.

18. The system of claim 17, wherein the signalling connection comprises at least one of Signalling System 7 (SS7), Session Initiated Protocol (SIP) and Integrated Services Digital Network (ISDN) User Part (ISUP).

19. A computer program product comprising a computer usable medium including computer usable program code for facilitating roaming tests for a club network, the computer program product comprising:

computer usable program code for facilitating by a signaling gateway (SG), simulation of a roamer's profile and associating it with one of: the club network and a roaming partner network of the club network; and

computer usable program code for performing by the SG, one or more CAMEL capability tests on the roamer;