GSM Association Non-confidential

Official Document TD.106 - Use of NRTRDE for the Single IMSI Fraud Interface

Use of NRTRDE for the Single IMSI Fraud Interface

Version 1.0
27 November 2013

This is a Binding Permanent Reference Document of the GSMA

Security Classification: Non-confidential

Access to and distribution of this document is restricted to the persons permitted by the security classification. This document is confidential to the
Association and is subject to copyright protection. This document is to be used only for the purposes for which it has been supplied and
information contained in it must not be disclosed or in any other way made available, in whole or in part, to persons other than those permitted
under the security classification without the prior written approval of the Association.

Copyright Notice
Copyright 2013 GSM Association

Disclaimer
The GSM Association (Association) makes no representation, warranty or undertaking (express or implied) with respect to and does not accept
any responsibility for, and hereby disclaims liability for the accuracy or completeness or timeliness of the information contained in this document.
The information contained in this document may be subject to change without prior notice.

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

V1.0 Page 1 of 10
GSM Association Non-confidential
Official Document TD.106 - Use of NRTRDE for the Single IMSI Fraud Interface

Table of Contents
1 Introduction 3
1.1 Overview 3
1.2 Scope 3
1.3 Definitions 3
1.4 Abbreviations 3
1.5 References 4
1.6 Conventions 4
2 General Requirements 4
2.1 Considerations If Not Implementing This Interface 4
2.2 Requirements On Top Of On-line Interfaces 5
2.3 Requirements Where No On-line Interfaces Exist 5
2.4 Additional Provisions 5
3 Required Data Items 5
3.1 File Level 5
3.2 Call Detail Level 6
3.2.1 MOC 6
3.2.2 MTC 7
3.2.3 GPRS 7
4 Physical Format 8
5 File Names 8
6 Timescales and Liability 9
7 Error Reports and File Delivery Reports 9
8 File Exchange Rules 9
Document Management 10
Document History 10
Other Information 10

V1.0 Page 2 of 10
GSM Association Non-confidential
Official Document TD.106 - Use of NRTRDE for the Single IMSI Fraud Interface

1 Introduction

1.1 Overview
This document explains how to use NRTRDE for the optional Single IMSI Fraud Interface
(SI-IF8) between the DSP and ARP.

1.2 Scope
This document needs to be read in conjunction with TD.35 [3].

Voice over LTE and SMS over IP is out of scope for the SI-IF8 fraud interface and for further
study (will not be received on the VPMN/HPMN interface).

Note: TD.35 [3] has been defined for the VPMN/HPMN fraud prevention interface. The use
of the document also for the DSP/ARP fraud prevention interface therefore needs to
consider that it has been written to define the rules on how the VPMN must populate
NRTRDE. When for example TD.35 [3] specifies available from the network, this shall be
interpreted as available to the DSP at the time of creation of the ARP fraud prevention file.

1.3 Definitions
Term Description
Calls All call events defined for the SI-IF8

1.4 Abbreviations
Term Description
ARP Alternative Roaming Provider
BS Bearer Service
DSP Domestic Service Provider
GPRS General Packet Radio Service
GGSN Gateway GPRS Support Node
GSM Global System for Mobile communications (originally Groupe Spcial Mobile)
GSMA GSM Association
HPMN Home PMN
IF Interface
IMEI International Mobile station Equipment Identity
IMSI International Mobile Subscriber Identity
IP Internet Protocol
LTE Long Term Evolution
MCC Mobile Country Code
MNC Mobile Network Code
MO Mobile Originated
MOC Mobile Originated Call
MSISDN Mobile Station International Subscriber Directory Number

V1.0 Page 3 of 10
GSM Association Non-confidential
Official Document TD.106 - Use of NRTRDE for the Single IMSI Fraud Interface

Term Description
MT Mobile Terminated
MTC Mobile Terminated Call
NI Network Identification
NRTRDE Near Real Time Roaming Data Exchange
OI Operator Identification
PMN Public Mobile Network
PRD Permanent Reference Document
RFC Request for Comments
SGSN Serving GPRS Support Node
SI Single IMSI
SMS Short Message Service
SMSC Short Message Service Centre
TADIG Transferred Account Data Interchange Group
TAP Transferred Account Procedure
TS Teleservice
UTC Universal Time Co-ordinated
VPMN Visited PMN

1.5 References
Ref Doc Number Title
GSMA PRD
[1] Fraud Prevention Procedures
BA.20
GSMA PRD
[2] File Transfer Methods
TD.28
GSMA PRD
[3] NRTRDE Format Specification
TD.35
Key words for use in RFCs to Indicate Requirement Levels, S. Bradner,
[4] RFC 2119
March 1997. Available at http://www.ietf.org/rfc/rfc2119.txt

1.6 Conventions
The key words must, must not, required, shall, shall not, should, should not,
recommended, may, and optional in this document are to be interpreted as described in
RFC 2119 [4].

2 General Requirements
2.1 Considerations If Not Implementing This Interface
If the DSP chooses not to implement this interface according to the requirements in this
section, it is liable (towards the ARP) for any related proven roaming fraud. It is recognised
that the DSP could have implemented other methods to combat roaming fraud, or (in case
the VPMN has failed to comply with the NRTRDE process towards the HPMN) liability for the
fraudulent calls could be transferred to the VPMN.

V1.0 Page 4 of 10
GSM Association Non-confidential
Official Document TD.106 - Use of NRTRDE for the Single IMSI Fraud Interface

2.2 Requirements On Top Of On-line Interfaces

The DSP must always forward to the ARP SMS-MO records where a third party SMSC is
used (due to a potential fraud concern), even where on-line (real-time) interfaces are in
place.

2.3 Requirements Where No On-line Interfaces Exist

Where there are no on-line (real-time) retail charging interfaces with the ARP, the DSP must
forward to the ARP MOC, MTC and SMS-MO records for all services/destinations that are
being managed by the ARP.

2.4 Additional Provisions

The NRTRDE data needs to be sent to the current ARP for that customer as per the start
time of the call event.

Sending of other NRTRDE data not listed as mandatory in sections 2.2 and 2.3 (for example
SMS-MT and GPRS data) is optional and at the discretion of the DSP. Unless otherwise
agreed between the DSP and the ARP, the DSP is doing this on a best efforts basis and
only in the interest of helping the ARP stop fraud, however it is not liable in the event that it
fails to comply with the NRTRDE rules (for example timescales).

For the purpose of fraud prevention, the DSP is also allowed to analyse the NRTRDE data
sent to the ARP. The DSP and ARP should agree on how to manage the fraud process.

The source of the NRTRDE data can be the NRTRDE data received from the VPMN, or any
other information (for example SMSC or home GGSN information) at the discretion of the
DSP.

3 Required Data Items

This section lists all required data items (names as in TD.35 [3]) per call scenario, and how
they should be populated on the DSP to ARP interface.
3.1 File Level
Data Item How to populate Comments
Specification Version Number Set to 2
Release Version Number Set to 1
Sender TADIG code of DSP
Recipient TADIG code of ARP
Sequence Number Maintain sequence numbers
for the DSP/ARP relationship
File Available Timestamp Set to the time when the file
(including UTC Time Offset) is sent
Call Events Count Calculate from individual call
records

Table 1: File Level

V1.0 Page 5 of 10
GSM Association Non-confidential
Official Document TD.106 - Use of NRTRDE for the Single IMSI Fraud Interface

3.2 Call Detail Level

3.2.1 MOC
Data Item How to populate Comments
IMSI IMSI If MSISDN is not populated,
then IMSI must be provided
in full.
If MSISDN is populated, then
population of the IMSI is at
the discretion of the DSP (as
a minimum the MCC/MNC of
the HPMN/DSP must be
populated).
IMEI IMEI if available
Call Event Start Timestamp Call Event Start Timestamp
(including UTC Time Offset) (including UTC Time Offset)
Total Call Event Duration Total Call Event Duration
Cause for Termination Cause for Termination
TeleService Code TeleService Code if available One of TS or BS Code must
be present
Bearer Service Code Bearer Service Code if One of TS or BS Code must
available be present
Supplementary Service Code Supplementary Service Code Call forwarding indicator.
if available
Dialled Digits Dialled Digits if available
Connected Number Connected Number if For SMS-MO, this will
available contain the SMSC address.
Third Party Number Third Party Number if
available
Recording Entity Identification Recording Entity Populate with real Recording
Identification Entity Identification if
available.
If not available, populate with
UNKNOWN or VPMN TADIG
Code
Call Reference Call Reference or Message
Reference where available
Serving Network If Serving Network is present
in the incoming record, then
populate with that.
Otherwise populate with the
TADIG code of the VPMN.
MSISDN MSISDN Populate if available.

Table 2: MOC

V1.0 Page 6 of 10
GSM Association Non-confidential
Official Document TD.106 - Use of NRTRDE for the Single IMSI Fraud Interface

3.2.2 MTC
Data Item How to populate Comments
IMSI IMSI If MSISDN is not populated,
then IMSI must be provided
in full.
If MSISDN is populated, then
population of the IMSI is at
the discretion of the DSP (as
a minimum the MCC/MNC of
the HPMN/DSP must be
populated).
IMEI IMEI if available
Call Event Start Timestamp Call Event Start Timestamp
(including UTC Time Offset) (including UTC Time Offset)
Total Call Event Duration Total Call Event Duration
Cause for Termination Cause for Termination
TeleService Code TeleService Code if available One of TS or BS Code must
be present
Bearer Service Code Bearer Service Code if One of TS or BS Code must
available be present
Calling Number Calling Number if available For SMS-MT, this will contain
the SMSC address.
Recording Entity Identification Recording Entity Populate with real Recording
Identification Entity Identification if
available.
If not available, populate with
UNKNOWN or VPMN TADIG
Code
Call Reference Call Reference or Message
Reference where available
Serving Network If Serving Network is present
in the incoming record, then
populate with that.
Otherwise populate with the
TADIG code of the VPMN.
MSISDN MSISDN Populate if available.

Table 3: MTC
3.2.3 GPRS
Data Item How to populate Comments
IMSI IMSI If MSISDN is not populated,
then IMSI must be provided
in full.
If MSISDN is populated, then
population of the IMSI is at
the discretion of the DSP (as

V1.0 Page 7 of 10
GSM Association Non-confidential
Official Document TD.106 - Use of NRTRDE for the Single IMSI Fraud Interface

Data Item How to populate Comments

a minimum the MCC/MNC of
the HPMN/DSP must be
populated).
IMEI IMEI if available
Call Event Start Timestamp Call Event Start Timestamp
(including UTC Time Offset) (including UTC Time Offset)
Total Call Event Duration Total Call Event Duration
Cause for Termination Cause for Termination
Access Point Name NI Access Point Name NI
Access Point Name OI Access Point Name OI if
available
Data Volume Incoming Data Volume Incoming
Data Volume Outgoing Data Volume Outgoing
SGSN Address SGSN Address Populate with real SGSN
Address if available.
If not available, populate with
1.1.1.1.
GGSN Address GGSN Address Populate with real GGSN
Address if available.
If not available, populate with
1.1.1.1.
Charging Id Charging Id
Serving Network If Serving Network is present
in the incoming record, then
populate with that.
Otherwise populate with the
TADIG code of the VPMN.
MSISDN MSISDN Populate if available.

Table 4: GPRS

4 Physical Format
The physical format is standard NRTRDE as defined in TD.35 [3].

5 File Names
The file naming convention should follow the NRTRDE standard:
NR[DSP TADIG code][ARP TADIG code][Sequence number
Example: NRLUXPTLUXAR0012345
The ARP will need to use an in-country TADIG code, whether it has a registered in-country
presence or not. The GSMA issues TADIG codes, and there are plenty of codes available
within each European country. For the avoidance of doubt, if the ARP is also a MNO with
international roaming agreements, it cannot reuse that TADIG code in its role as an ARP.

V1.0 Page 8 of 10
GSM Association Non-confidential
Official Document TD.106 - Use of NRTRDE for the Single IMSI Fraud Interface

6 Timescales and Liability

The timescale for the VPMN to make the NRTRDE records available to the HPMN is 4 hours
from call/partial end time. As at least some of the information will be sourced from the
incoming NRTRDE files, the HPMN will need additional time to make the records available to
the ARP (potentially via a MVNO).
The DSP must make correct NRTRDE records (subject to the requirements in section 2)
available to the ARP within 8 hours from call/partial end time. The additional 4 hours is
needed to cater for exceptional cases of operational problems, validation, re-rating, transfer
via a MVNO, etc. The actual time can also be shorter than 8 hours as agreed between the
DSP and ARP.
The liability rules that apply to the VPMN and HPMN over the VPMN/HPMN interface as
defined in BA.20 [1], apply also to the DSP and ARP over the DSP/ARP interface. The two
interfaces are independent of one another.

7 Error Reports and File Delivery Reports

File Delivery Reports and Error Reports as defined in TD.35 [3] are mandatory on the
VPMN/HPMN interface, and must (as requested by the Fraud Forum) also be used over the
DSP/ARP interface. If not implemented, then the ARP will accept the data as sent by the
DSP.

8 File Exchange Rules

Physical transfer methods are discussed in TD.28 [2].

V1.0 Page 9 of 10
GSM Association Non-confidential
Official Document TD.106 - Use of NRTRDE for the Single IMSI Fraud Interface

Document Management

Document History
Version Date Brief Description of Change Approval Editor /
Authority Company
New PRD Christer
27 Nov TADIG eVote
1.0 Created by the BEREC Stakeholder Forum Gullstrand /
2013 PSMC #118
Billing & Provisioning Subgroup Syniverse

Other Information
Type Description
Document Owner TADIG
Editor / Company Christer Gullstrand / Syniverse

It is our intention to provide a quality product for your use. If you find any errors or omissions,
please contact us with your comments. You may notify us at [email protected].

Your comments or suggestions & questions are always welcome.

V1.0 Page 10 of 10