Charge Detail Records Interchange Format (CDRIF)

The Charge Detail Record (CDR) Interchange Format is a standardized way of representing billingrelated events generated by telecom, utility, and other serviceprovider networks. A CDR captures the who, what, when, where and how much of a chargeable event, and the interchange format defines how that data is packaged for exchange between rating, billing, mediation, and reporting systems.

Why a Standard Interchange Format Matters

• Interoperability: Different vendors (mediation platforms, rating engines, OSS/BSS) can exchange records without custom parsers.
• Scalability: Large volumes (millions of records per day) can be processed by streaming parsers that rely on predictable delimiters.
• Regulatory compliance: Many jurisdictions require auditready logs that can be exported in a defined structure.
• Analytics readiness: A uniform schema simplifies loading data into data warehouses or bigdata platforms.

Core Concepts

Record Types

Most specifications define several record types, each identified by a leading tag:

Tag	Name	Description
H	Header	Filelevel metadata creation date, version, source system.
D	Detail	Actual charge data one line per event.
T	Trailer	Totals, record counts, checksum for integrity.

Field Delimiters

Common delimiters include:

• Comma (CSV) simple, widely supported.
• Pipe (|) avoids clashes with embedded commas.
• Tab ideal for fixedwidth logs.

Some implementations use a fixedwidth layout where each field occupies a specific number of characters, eliminating delimiters altogether.

Encoding & Character Set

UTF8 is the default for modern CDRIF files, ensuring support for international subscriber identifiers and comments. Legacy systems may still use ISO88591 or ASCII.

Typical CDR Fields

While the exact set varies by industry, the following fields appear in most CDRs:

Record Type | Timestamp       | Service ID | Originator | Destination | Duration | Volume | Unit Price | Total Charge | Currency | Rating ID

Explanation:

• Record Type: H, D, or T as described above.
• Timestamp: ISO8601 datetime (e.g., 2026-05-30T13:45:12Z).
• Service ID: Identifier of the service (voice, SMS, data, power).
• Originator/Destination: Subscriber identifiers (MSISDN, IMSI, account number).
• Duration: Length of the event in seconds (for voice, sessions).
• Volume: Amount of data or units transferred.
• Unit Price: Price per unit in the billing currency.
• Total Charge: Calculated charge (Unit Price Volume/Duration).
• Currency: ISO 4217 code (USD, EUR, etc.).
• Rating ID: Identifier linking to the rule set that produced the charge.

Example File (PipeDelimited)

H|2026-05-30T00:00:00Z|Version=1.0|Source=MediateX|FileID=12345D|2026-05-30T10:15:23Z|VOICE|447700900123|447700900456|300|0|0.0400|12.00|GBP|RAT001D|2026-05-30T10:20:07Z|SMS|447700900123|447700900789|0|1|0.0100|0.01|GBP|RAT002D|2026-05-30T10:25:12Z|DATA|447700900123|INTERNET|0|2048|0.0005|1.02|GBP|RAT003T|3|13.03|Checksum=7A9F

The header (H) defines filelevel context, each detail (D) line carries a chargeable event, and the trailer (T) reports that three detail records were processed with a total charge of 13.03.

Validation Rules

1. Mandatory fields: Every detail record must contain at least timestamp, service ID, originator, and total charge.
2. Data types: Dates must be ISO8601, numeric fields must contain only digits (and a single decimal point if required).
3. Length limits: If a fixedwidth layout is used, each column length is strictly enforced; excess characters cause a rejection.
4. Checksum: Most formats include a simple XOR or CRC checksum in the trailer for integrity checking.
5. Reference integrity: Rating IDs must exist in the rating engine's rule repository; otherwise the record is flagged.

Common Standards & Variants

Standard	Domain	Key Features
3GPP CDR	Mobile Telephony	Supports IMSI, MSC, GGSN fields; typically CSV.
ITUT C.250	Universal Billing	Defines a fixedwidth layout and optional XML wrapper.
GSMA MAP CDR	Roaming	Binary TLV encoding for lowbandwidth links.
OpenCGA CDR	Utility (Electricity/Water)	XMLbased, with nested measurement blocks.
ETSI NFV CDR	Network Functions Virtualisation	JSON format focused on resource usage.

Processing Pipeline Overview

1. Collection Network elements generate raw events.
2. Mediation Raw data is normalized, enriched, and written out in CDRIF.
3. Rating Rating engine reads the CDRs, applies pricing rules, and populates the Total Charge field.
4. Billing Rated records are aggregated into invoices or statements.
5. Archiving & Auditing Original CDR files are stored for the legally required retention period.

Best Practices

• Versioning: Include a version identifier in the header; never change the layout without incrementing it.
• Compression: Use gzip or bzip2 for bulk transfer; decompression should be lossless.
• Streaming support: Design parsers to handle records linebyline, enabling processing of files that exceed RAM.
• Error handling: Separate malformed records into a reject file with detailed error codes for later reprocessing.
• Secure transport: Transfer files over SFTP, FTPS, or via HTTPS APIs; avoid plain FTP.

Future Directions

As networks evolve towards 5G, IoT, and edge computing, CDRIF is expanding beyond traditional voice/SMS models:

• Eventdriven CDRs: Tiny records generated for each sensor reading or API call.
• JSONLD and Avro: Selfdescribing formats that embed schema information, simplifying downstream processing.
• Realtime streaming: Integration with Apache Kafka or Pulsar to push CDRs directly into analytics pipelines.
• PrivacybyDesign: Tokenisation of subscriber identifiers and selective field masking to meet GDPRlike regulations.

Getting Started

For a quick proofofconcept:

1. Decide on a delimiter (pipe is a safe default).
2. Create a header with version and source identification.
3. Generate a few sample detail lines using the field list above.
4. Calculate total charges (unit price quantity) and add them.
5. Append a trailer containing the record count and a simple checksum (e.g., sum of ASCII codes modulo 65536).
6. Validate the file with a small script (Python, Bash, or PowerShell) that checks field count, data types, and checksum.

Once the format is stable, integrate the file exchange with your mediation platform via SFTP or an HTTPPOST endpoint, and configure the rating engine to ingest the same layout.

References

• 3GPP TS32.297 Charging Data Record formats.
• ITUT RecommendationC.250 CDR data definition.
• GSMA Charging for Roaming MAP CDR guidelines.
• ETSI NFVMANO specifications resource usage CDRs.
• OpenAPI & JSON Schema designing JSONbased CDRs.