Following paper provides small overview of recent research results on fraud detection solutions, test environment, conditions that showed a lack of focus and testing on standardized data formats and following information delivery time. In paper data preparation and enrichment algorithm scheme, related tables, configurations, required fields for mapping between session detail record from VoLTE platform and billing data was described. Developed algorithm approbation results were provided and compared between case with only standardized data format (NRTRDE, TAP3) and case that combines NRTRDE, TAP3 data with enriched xDR prepared by algorithm. Conclusions were made, that following algorithm improved fraudulent traffic detection time, allows to upload and enrich data directly in Fraud detection system database, proved that data delivery time is vital KPI and should be considered during Fraud management system development phase and approbation before implementation on carrier network.
for transaction delivery time to partner network. This delivery time can vary not more than 4 hours
or 8 hours (in case of outages on partner network) for NRTRDE and not more than 30 days or not
more than 40 days (in case of outages on partner network) for TAP3 defined by GSMA [
In order to simulate NRTRDE and TAP3 files preparation, Oracle Billing system was used. This system has embedded feature to generate such files. For data transfer from one carrier network to another carrier DCH providers are used of some other near real time file sharing service.
Test environment (figure 1) consist of two OCS for carrier 1 and 2, Rhino VoLTE TAS Application
server, Rhino CDR ETL server and Fraud detection system (FMS). All elements are connected to one
and same NAS to deliver, prepare and upload files to FMS. OCS of carrier 1 provides price file to
calculate cost of subscriber session in Rhino Raw. OCS of carrier 2 generates NRTRDE and TAP3
files with time delays defined in their standards [
OOaCnrSadocRlfeecvBaerilrnliiuenreg2 OOaCnrSadocRfleecvaBerilrnliiuenreg1 sRehrviAneporpoVlifoccaLaTtirEorinTeArS1 bFaraseudd odnetOecraticolen RsyDsBteMmS TAP3, NRTRDE
Price
Rhino Raw
Price, Rhino csv Rhino CDR
ETL server Price, Raw Rhino
TAP3, NRTRDE
NAS
Price files exported from OCS contain 8 fields (refer to table 1) for recognition of service name and type, TADIG, MCC, MNC, IOI, minimum price and currency. Fields from Rhino CDR OC-ServiceType, OC-Call-Type, OC-Access-Network-MCC-MNC, OC-Visited-Network-MCC-MNC, OC-IMSIMCC-MNC, Inter-Operator-Identifier are used from Rhino csv to correlate Price file and session.
To prepare Rhino csv file, ETL server have bash code configured to run periodically through cron
jobs. Rhine raw file is delivered by VoLTE in AVP (attribute value-pair) format and one AVP can
contain more than one child AVP. Rhino VoLTE AVP fields are similar to ETSI standard [
Oracle ODI logical flow (figure 2) perform next actions: 1. Files are loaded from directories «/media/sf_fraud_detection/Price/in» «/media/sf_fraud_detection/Rhino/in» to temporary tables C$_0EXP, C$_1CDR; and • • • • •
Values from temporary tables are transformed into expressions (EXPRESSION_EXP, EXPRESSION_CDR) for join operations (JOIN_MOC, JOIN_MTC); Data from tables are joined by expression for JOIN_MTC CDR.Service_name=EXP.Service_name and EXP.Service_type=CDR.Service_type and CDR.Destination_network=EXP.IOI and JOIN_MOC ; After join operation was done, results are loaded in table fraud.ur_ims_records. In this table (to_date('1970-01-01 00:00:00','YYYY-MM-DD HH24:MI:SS') + numtodsinterval((CDR.Start_call_time/1000),'SECOND')) , price for provided service is calculated by - , session (CDR.End_call_time-CDR.Start_call_time)/60000 After record is loaded in table, system periodically checks it and loads new CDRs in application memory, where these records will be processed by fraud detection rules; After ODI loaded records in table, original files that are located in «/media/sf_fraud_detection/Rhino/in» moved automatically to directory «/media/sf_fraud_detection/Rhino/done»;
On physical level of described ODI scheme for data load from files to temporary table Loading Knowledge Module (LKM) SQL to SQL (Built-in) Global is used. It is built-in ODI module for common operations with relational databases.
After records were loaded in database, Fraud detection software starts to process it and each record goes through next lifecycle of tables located in RDBMS: fraud.ur_ims_records>fraud.pos_prealerts->total_alerted_cdrs/fraud.ims_alerted_cdrs->fraud.alerts->fraud.cases This tables perform next functions: fraud.ur_ims_records this table is used to store Rhino CDRs on FMS DB; fraud.pos_prealerts this table is used by FMS to create temporary fraud alerts. It stores all types of alerts that became complete or were discarded as duplicates; fraud.ims_alerted_cdrs this table stores the CDRs that were used to create a fraud alert. By default, the records in total_alerted_cdrs duplicate the information in fraud.ur_ims_records, but will also provide the time when record was added into the table after alert was created and alert ID related to record. fraud.total_alerted_cdrs - stores information about all CDRs that were used to create an alert, regardless of the source type (it combines CDRs from all types of data sources). fraud.alerts stores information about alerts. This table is common for all data source types and provides information about the alert creation time, number of CDR records, rule
Mapping between table fraud.ur_ims_records in FMS, Rhino raw and price file, described in table 2. Depending on service type in record only one of two fields can be filled: • •
Originated_imei can be filled in Rhino raw if service type is MOC
Destination_imei can be filled in Rhino raw if service type is MTC.
Fraud detection in FMS consists of Detection, Correlation and Case management phases (figure 3). Each phase uses next lookup tables: • • • • • • fraud.sources stores information about data sources and their unique identifiers. fraud.rule_sources stores information about rules belonging to data sources defined in fraud.sources. fraud.rules - this table stores information about rules created by users (unique identifier of the rule, name of conditions used to detect suspicious traffic, and boundary conditions, which include the monitoring period, number of suspicious sessions required to create a fraud case, etc). fraud.conditions this table contain information about conditions created by users to track a certain type of traffic. Conditions can consist of any fields of the ur_*_records tables and lists that use Boolean algebra conditions to combine or exclude a certain condition. fraud.hotlist - stores information about existing lists created by users. It contains information such as the list creation time, username, list name, and its unique identifier. fraud.hotlist_values - this table stores the values of suspicious objects or identifiers of unscrupulous carriers. Each value contains the time it was created and the time until which this value must exist in the list to which it belongs. Detection
NRTRDE and TAP3 files are decoded by built-in ASN1_decoder of Fraud management system to csv format and loaded in appropriate tables: • fraud.ur_nrtrde_records this table is used to store decoded CDRs from NRTRDE on FMS
DB; • fraud.ur_ims_records this table is used to store decoded CDRs from TAP3 on FMS DB; Processing flow for NRTRDE and TAP3 records by Fraud detection software is same: • fraud.ur_nrtrde_records->fraud.pos_prealerts
>total_alerted_cdrs/fraud.nrtrde_alerted_cdrs->fraud.alerts->fraud.cases; • fraud.ur_tap3_records->fraud.pos_prealerts->total_alerted_cdrs/fraud.tap3_alerted_cdrs>fraud.alerts->fraud.cases;
To detect fraudulent traffic several same detection rules were created for each type of data source (refer to table 3). Following rules are targeted to detect long and small duration sessions that are commonly recognized as fraudulent behavior.
Traffic definition for monitoring MOC, (terminating network SWE01 or terminating network bea.net), calling number is not present in whitelist MOC, (terminating network SWE01 or terminating network bea.net), calling number is not present in whitelist MOC, (terminating network SWE01 or terminating network bea.net), calling number is not present in whitelist MOC, (terminating network SWE01 or terminating network bea.net), calling number is present in whitelist MTC, (originating network SWE01 or originating network bea.net), called number is not present in whitelist MTC, (originating network SWE01 or originating network bea.net), called number is not present in whitelist MTC, (originating network SWE01 or originating network bea.net), called number is not present in whitelist MTC, (originating network SWE01 or originating network bea.net), called number is not present in whitelist duration>=30 min and duration<=1800 min duration>20 sec duration>20 sec and duration<30 sec duration>20 sec and duration<30 sec duration>=30 min and duration<=1800 min duration>20 sec duration>20 sec and duration<30 sec duration>20 sec and duration<30 sec count >=3 calls based on originated IMSI/MSISDN count >=10 calls based on originated IMSI/MSISDN sum duration >= 1 hours based on originated IMSI/MSISDN sum duration >= 1 hours based on terminated IMSI/MSISDN count >=3 calls based on originated IMSI/MSISDN count >=10 calls based on originated IMSI/MSISDN sum duration >=1 hours based on originated IMSI/MSISDN sum duration >= 1 hours based on terminated IMSI/MSISDN
For traffic generation environment have 980 subscribers (490 virtual numbers for each carrier). Number of sessions in network can vary from 7 to 8 thousand within 24 hours. Table 4 contain number of files and session records generated within 1 day for each source type (Rhino CDR, NRTRDE, TAP3).
The formulas defined in [
Table 5 contain summary for fraud detection based on NRTRDE and TAP3 files detected within 24 hours.
fraudulent records for NRTRDE and TAP3 source types
In percentage distribution 31% of alerts generated based on NRTRDE files were uploaded in system within one hour, while 36% of alerts generated based on TAP3 files were uploaded in system within 24 hours.
Table 6 provide combined statistics with Rhino for NRTRDE and TAP3 data sources. In percentage distribution 94% of alerts created based on combination of NRTRDE and Rhino CDR files were uploaded in system within one hour, while 95% of alerts created based on combination of TAP3 and Rhino CDR files that were uploaded in system within one hour.
Comparing weighted average value of for NRTRDE and TAP3, can be noticed that for NRTRDE latency was reduced by 3,7 times and for TAP3 it was reduced by 14 times (table 7). Approbation results of developed algorithm showed improvement in fraud detection speed, that decrease reaction time from security on fraudulent traffic. Algorithm allows to directly upload, transform time and calculate transaction cost of detail record in FMS database. Results proved that data delivery time have significant impact on fraud detection systems and should be considered during development and maintenance in test environment before system delivery on actual carrier network.
The authors have not employed any Generative AI tools.