Generating Valid Synthetic Data for Telecom: IMSI, IMEI, and CDRs

If you are building a 5G billing engine, a telecommunications analytics dashboard, or a SIM-fraud detection model, generic data generators are useless.

Telecom systems do not run on arbitrary strings; they run on strict international standards. An IMSI is not just a random 15-digit number—it contains routing logic. An IMEI isn't just a serial number—it requires a cryptographic check digit. A Call Detail Record (CDR) isn't just a log—it is a causal sequence of events.

If you try to test your telecom infrastructure with Math.random(), your billing routers will reject the payloads, your network parsers will crash, and your fraud models will learn nothing.

Here is why generic mocking tools fail at telecom schemas, and how to generate mathematically valid, structurally perfect mock telecom data for both local testing and enterprise ML streams.

The Code Problem: The Protocol Trap

To understand why custom seed scripts break telecom applications, look at a standard relational schema for a subscriber database and its associated Call Detail Records (CDRs):

-- 1. The Subscriber Table (Requires Valid Formats)

CREATE TABLE subscribers (

subscriber_id UUID PRIMARY KEY,

imsi VARCHAR(15) UNIQUE NOT NULL, -- e.g., '310150123456789' (AT&T US)

imei VARCHAR(15) NOT NULL, -- Must pass the Luhn algorithm check

msisdn VARCHAR(15) NOT NULL -- The actual phone number (E.164 format)

);

-- 2. The Call Detail Record (CDR) Ledger

CREATE TABLE call_detail_records (

cdr_id UUID PRIMARY KEY,

calling_imsi VARCHAR(15) REFERENCES subscribers(imsi),

called_msisdn VARCHAR(15) NOT NULL,

call_start_time TIMESTAMP NOT NULL,

call_duration_seconds INT NOT NULL,

call_end_time TIMESTAMP GENERATED ALWAYS AS (call_start_time + call_duration_seconds \ INTERVAL '1 second') STORED,

data_volume_mb DECIMAL(10,2)

);

Why Faker.js and Custom Scripts Fail

If you use a generic data generator to seed these tables, your testing environment will immediately fail:

1. Routing and Checksum Violations: A generic script will generate a random 15-digit number for the IMEI. However, the 15th digit of an IMEI is a calculated checksum (the Luhn algorithm). If your application validates this checksum (which all telecom apps do), 90% of your generated rows will be immediately rejected as "corrupt devices."
2. Nonsensical IMSIs: An IMSI is composed of a Mobile Country Code (MCC), a Mobile Network Code (MNC), and a subscriber number. A random string generator might create an IMSI with an MCC of 999—which doesn't exist. Your routing logic will drop the packet.
3. Temporal Impossibilities: A basic script generating CDRs might simulate a user making two different phone calls at the exact same millisecond, or consuming 500GB of data in a 2-second call window. This destroys the mathematical validity of the billing ledger.

The Solution: Two Paths for Telecom Synthetic Data

Because telecommunications require strict protocol formatting for application testing and massive, causal scale for AI training, Algomimic provides two distinct solutions.

Path A: For Billing & App Developers (The Aphelion CLI)

If you are a backend engineer or QA lead building a telecom billing system or OSS/BSS dashboard, you need to populate your local database with valid network identifiers.

Aphelion is a local, Rust-native CLI that automatically introspects your database. It comes with telecom-specific generators that understand the Luhn algorithm, E.164 phone number formatting, and valid MCC/MNC routing tables.

The Recipe for Local Telecom Seeding:

# 1. Point Aphelion at your local telecom database

aphelion introspect postgres://admin:password@localhost:5432/oss_billing_dev

# 2. Generate 100,000 constraint-safe subscribers and CDRs

aphelion generate --table subscribers --rows 100000 --seed 2026

Result: Your local database is instantly hydrated with perfectly formatted IMEIs, valid IMSIs routed to real geographic codes, and timestamp-accurate CDRs. You can test your frontend dashboards and billing logic without exposing real subscriber data.

Path B: For Enterprise ML & Network Fraud (CausalFoundry)

If you are an ML Engineer training a model to detect SIM-box fraud, International Revenue Share Fraud (IRSF), or network anomalies, simply having "valid formats" isn't enough. You need millions of events that simulate complex human behavior and coordinated attacks.

CausalFoundry is an enterprise synthetic data factory that enforces temporal and behavioral rules using an in-memory StateMap.

The Recipe for Telecom ML Streams:

# causal_manifest.yaml

invariants:

- physical_limitations:

policy: deterministic

# Enforce that a single IMSI cannot originate two calls simultaneously

constraint: "NO_OVERLAP(subscribers.active_call_windows)"

state: telecom.network_state

entropy:

- inject_fraud_scenario:

type: sim_box_attack

# Inject a scenario where 100 IMEIs rapidly rotate through a single cell tower

trigger: "random(0.005)" 



- fuzz_subscriber_pii:

fields: msisdn, billing_address, imsi

shadow: true # Safely shadow live production Kafka CDR streams

Result: CausalFoundry shadows your live production CDR streams, deterministically fuzzes sensitive subscriber data, enforces the physical laws of the cellular network, and explicitly injects rare fraud patterns into your data pipelines for ML model training.

Stop Testing with Corrupted Packets

You cannot build reliable telecom infrastructure if your test data violates the basic protocols of the network.

• ✓Building a billing app? Download the free Aphelion CLI to seed constraint-safe subscribers locally.
• ✓Training a network fraud model? Join the CausalFoundry Beta to stream causally accurate, stateful CDR data at massive scale.