IREG vs TADIG testing: what each validates in a roaming launch

IREG testing checks that roaming technically works between a home and a visited network: registration, calls, SMS and data, run from GSMA end-to-end functional test specifications such as IR.24. TADIG testing checks that the usage produced during those tests is recorded and exchanged correctly for wholesale billing, through TAP and RAP files. IREG comes first and generates the test traffic. TADIG then verifies the billing records for that traffic, and commercial launch follows once both pass.

What is IREG testing?

IREG testing takes its name from the GSMA’s International Roaming Expert Group, which wrote the technical roaming test specifications. The framework is set out in GSMA IR.23, Organisation of GSM International Roaming Tests. Its current version (v8.0, January 2025, updated for 5G SA) recommends three stages:

Stage	Activity	Responsibility
1	Self-certification of MAP, CAP, IP, Diameter, GTP and HTTP/2 interfaces	Each operator, once per network element type and vendor
2	Exchange of numbering, addressing and operations data	Both operators, their carriers, IPX providers and any roaming hub
3	End-to-end functional and capability tests	Both operators (and any roaming hub), per relationship

Older documents number the end-to-end stage differently. IR.24’s title still reads End to End Functional Capability Specification for Inter-PLMN Roaming (Stage 4 Testing), as cited in the reference list of IR.25 v9.0. In practice, “IREG testing” means the per-partner end-to-end stage.

IREG test specifications by technology

IR.23 points to a family of end-to-end test documents:

Document	Covers
IR.24	Basic inter-PLMN roaming: location update, telephony, SMS, barring and call forwarding
IR.26	Phase 2 supplementary services and operator-determined barring
IR.32	CAMEL roaming
IR.35	GPRS roaming
IR.38	LTE and EPC roaming: LTE data, CS fallback, SMS over SGs
IR.25	VoLTE roaming (home-routed S8HR architecture) and SMS over LTE
IR.50	2G/2.5G/3G roaming
IR.60	Prepaid service roaming (CAMEL-based)
NG.143	5G SA roaming

How IREG tests are run

The tests are written in one direction, a subscriber of network A visiting network B, and repeated with the roles swapped for a bilateral relationship. IR.38 describes the typical division of work:

1. The home network issues pre-programmed test SIMs and provisions them in its HSS.
2. The visited network runs the tests. IR.25 also allows the home network to run them using a roaming end-to-end test platform that covers the visited network.
3. The two operators review the results together.

IR.23 says the end-to-end stage must be a high-level functional test that can be completed in a few person-hours, because it is repeated for every roaming relationship. Deep protocol conformance belongs in stage 1.

What IREG testing validates

• The roaming subscriber can register (location update, attach, IMS registration for VoLTE).
• Mobile-originated and mobile-terminated calls connect, including calls to local numbers and back to the home country.
• SMS works in both directions with the home SMS center.
• Data sessions establish on the agreed APNs over GRX/IPX, with correct DNS and routing.
• Supplementary services, barring and call forwarding behave as subscribed.
• Emergency calls work. IR.25 notes these are tested by the visited network using procedures defined by local authorities.

What is TADIG testing?

TADIG testing takes its name from the Transferred Account Data Interchange Group, the GSMA group that defined how operators exchange roaming usage for billing. That work now sits with GSMA’s Interoperability Data Specifications and Settlement Group (IDS), as described in the TAP Testing Toolkit brochure.

The core artifacts are:

• TAP (Transferred Account Procedure). The visited network sends the home network files of roaming usage records to be charged. The TAP3 format is specified in TD.57.
• RAP (Returned Account Procedure). The home network returns TAP records or files it rejects, specified in TD.32.
• NRTRDE. Near-real-time roaming data exchange, used mainly for fraud control, specified in TD.35.
• TADIG codes. Five-character operator identifiers (a three-character country part plus a two-character operator part) that appear in these files, defined in TD.13.

Current IREG documents such as IR.38 and IR.25 v9.0 point to TD.41, Testing the Transferred Account Procedure (TAP), for TADIG testing. VoLTE test cases are mapped to TAP test cases in TD.50. Older editions of IR.24 referred to TADIG document TD.06 instead, so check the current PRD index when citing document numbers.

How TADIG tests are run

GSMA recommends running the TADIG testing process with each roaming partner for every new or updated agreement, service or billing system. Its TAP Testing Toolkit (TTT) supports a standard flow:

1. Network tests run on the visited network with test IMSIs. In practice this is the IREG test traffic. IR.25 describes using the visited network’s toll ticketing output from these tests as a live data file for TADIG testing.
2. The visited network creates TAP files, validates them and cross-references each call event to the test case that produced it.
3. The home network re-validates the files to confirm that commercial files will be accepted, then certifies the results.

What TADIG testing validates

• TAP files pass format and validation rules for the agreed TAP version.
• Every test event appears, and nothing extra does.
• Identifiers are correct: IMSI, MSISDN, called numbers, APN, TADIG codes.
• Timestamps and UTC offsets are correct. A wrong offset is a classic source of disputes.
• Charged items, volumes, durations, charges, taxes and currency are correct under the agreement.
• File sequencing, transfer and RAP handling work end to end.

IREG vs TADIG: side-by-side comparison

	IREG testing	TADIG testing
Question answered	Does roaming work?	Is roaming billed correctly?
Domain	Signaling, radio access, core and IMS interworking	Wholesale billing and data clearing
Key GSMA documents	IR.23, IR.24, IR.35, IR.38, IR.25, NG.143	TD.41, TD.57 (TAP3), TD.32 (RAP), TD.13 (codes), TD.50
Inputs	Test SIMs or profiles, HSS provisioning, IR.21 data	Test usage from IREG tests, roaming agreement terms
Outputs	Pass/fail per test case, traces	Validated TAP files, cross-referenced test cases, certification
Typical owners	Roaming engineering, core network teams	Roaming billing, data clearing house, finance
Typical failures	Registration rejects, missing APN, broken SMS or MT calls	Missing records, wrong time zone, wrong charges, rejected files
When	Before launch; after network changes; periodically	After IREG tests; after billing or agreement changes

Where they fit in a roaming launch

A typical bilateral launch runs in this order:

1. Agreement. Commercial roaming agreement signed, including the services in scope.
2. Data exchange. Each side publishes or updates its IR.21 roaming database entry (GSM Association Roaming Database, Structure and Updating) and exchanges TADIG codes and contacts.
3. Configuration. HLR/HSS profiles, signaling routing (STP, DRA, SEPP), IPX connectivity, APNs, firewalls, steering of roaming lists, CAMEL or IMS settings.
4. IREG testing. End-to-end functional tests in both directions.
5. TADIG testing. TAP files from the test traffic validated and certified.
6. Commercial launch. Roaming opened to subscribers.
7. Ongoing re-testing. IR.23 calls for re-testing after network changes and periodic re-testing after launch, describing weekly test calls with each partner’s test SIMs.

Common failures each stage catches

The two stages catch different classes of problem, and a clean result in one says nothing about the other.

Typical IREG findings:

• Registration rejected because the visited network hasn’t opened the home network’s IMSI range, or the home HSS doesn’t allow that visited network. The reject cause in the NAS signaling usually tells you which side to check.
• Signaling routing gaps. Missing global title translations or Diameter routes, so location updates or authentication requests never reach the home network.
• Data failures. An APN missing from the subscription, APN DNS not resolvable across the GRX/IPX, or GTP firewall rules that drop the tunnel.
• Mobile-terminated failures. Outgoing calls and SMS work, but incoming calls or SMS to the roamer don’t, often a routing or numbering configuration issue.
• VoLTE gaps. IMS registration or call setup fails while data works, because the IMS roaming path or APN wasn’t configured for that partner.

Typical TADIG findings:

• Missing or duplicate records for events that IREG testing clearly generated.
• Wrong time or UTC offset, which shifts events into the wrong charging period or makes them look stale.
• Wrong rating. Charges, taxes or currency that don’t match the agreement, or data volumes rounded differently than agreed.
• Wrong identifiers. An incorrect TADIG code, a malformed number format or an unexpected APN value.
• File-level rejections. Sequence number gaps or validation errors that make the home network return the file through RAP.

Automation opportunities

Both stages are repetitive and well defined, which makes them good automation candidates.

For IREG testing:

• Remote devices in the visited network replace couriered handsets. With eSIM, the home test profile can be downloaded over the air instead of shipping a SIM.
• Forced network selection (AT+COPS with the partner’s MCC-MNC) puts the device on the exact partner under test, even where several partners overlap.
• Scripted test cases for registration, MO/MT calls, SMS and data, each with a recorded verdict and the decoded signaling as evidence, including any attach reject cause.
• Repeatable re-runs. The same scripts become the periodic re-test that IR.23 calls for.

For TADIG testing:

• Expected-records lists. An automated IREG run logs exactly which calls, SMS and data sessions happened, when, from which IMSI or MSISDN and to which number. That log is the expected TAP content.
• Automatic cross-referencing of TAP records against the expected list catches missing events, time zone errors and wrong charges faster than manual review.
• Continuous checks after launch. Small, known test events on each partner can be reconciled against TAP or near-real-time data, which catches billing drift between formal tests.

SimCheck.ai covers the functional side: real modems with real eSIM profiles, forced partner PLMN and radio technology, and voice, SMS and data checks with logs and decoded signaling for every run. Test history and the Roaming matrix report export to CSV, so the events a run generated can be reconciled against the partner’s TAP records.

Test roaming partners without the courier

Formal IREG and TADIG stages happen at launch, but partners change long after the certificates are signed. See how roaming testing on SimCheck.ai runs functional checks on each partner on a schedule, or read the roaming testing guide for KPIs and test cadence.