Charge Detail Records Interchange Format and Reference File Download Link
https://eu2.contabostorage.com/00f3241116844f24b628f46d81abb929:st1/folder7/7249/1656286141_201401110_charge_detail_records_interchange_format_v1_6_-_Standar_Format.xls
2026-05-30 22:04:05 - Admin
<style> body { font-family: Arial, Helvetica, sans-serif; line-height: 1.6; margin: 0; padding: 20px; background-color: #f9f9f9; color: #333; } h1, h2, h3 { color: #004080; } pre { background: #eef; padding: 10px; overflow-x: auto; } table { border-collapse: collapse; width: 100%; margin: 15px 0; } th, td { border: 1px solid #bbb; padding: 8px; text-align: left; } th { background: #ddd; } a { color: #0066cc; text-decoration: none; } a:hover { text-decoration: underline; } </style><h1>Charge Detail Records Interchange Format (CDRIF)</h1><p>The <strong>Charge Detail Record (CDR) Interchange Format</strong> 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.</p><h2>Why a Standard Interchange Format Matters</h2><ul> <li><strong>Interoperability</strong>: Different vendors (mediation platforms, rating engines, OSS/BSS) can exchange records without custom parsers.</li> <li><strong>Scalability</strong>: Large volumes (millions of records per day) can be processed by streaming parsers that rely on predictable delimiters.</li> <li><strong>Regulatory compliance</strong>: Many jurisdictions require auditready logs that can be exported in a defined structure.</li> <li><strong>Analytics readiness</strong>: A uniform schema simplifies loading data into data warehouses or bigdata platforms.</li></ul><h2>Core Concepts</h2><h3>Record Types</h3><p>Most specifications define several record types, each identified by a leading tag:</p><table> <thead> <tr><th>Tag</th><th>Name</th><th>Description</th></tr> </thead> <tbody> <tr><td>H</td><td>Header</td><td>Filelevel metadata creation date, version, source system.</td></tr> <tr><td>D</td><td>Detail</td><td>Actual charge data one line per event.</td></tr> <tr><td>T</td><td>Trailer</td><td>Totals, record counts, checksum for integrity.</td></tr> </tbody></table><h3>Field Delimiters</h3><p>Common delimiters include:</p><ul> <li>Comma (CSV) simple, widely supported.</li> <li>Pipe (|) avoids clashes with embedded commas.</li> <li>Tab ideal for fixedwidth logs.</li></ul><p>Some implementations use a <em>fixedwidth</em> layout where each field occupies a specific number of characters, eliminating delimiters altogether.</p><h3>Encoding & Character Set</h3><p>UTF8 is the default for modern CDRIF files, ensuring support for international subscriber identifiers and comments. Legacy systems may still use ISO88591 or ASCII.</p><h2>Typical CDR Fields</h2><p>While the exact set varies by industry, the following fields appear in most CDRs:</p><pre>Record Type | Timestamp | Service ID | Originator | Destination | Duration | Volume | Unit Price | Total Charge | Currency | Rating ID</pre><p>Explanation:</p><ul> <li><strong>Record Type</strong>: H, D, or T as described above.</li> <li><strong>Timestamp</strong>: ISO8601 datetime (e.g., 2026-05-30T13:45:12Z).</li> <li><strong>Service ID</strong>: Identifier of the service (voice, SMS, data, power).</li> <li><strong>Originator/Destination</strong>: Subscriber identifiers (MSISDN, IMSI, account number).</li> <li><strong>Duration</strong>: Length of the event in seconds (for voice, sessions).</li> <li><strong>Volume</strong>: Amount of data or units transferred.</li> <li><strong>Unit Price</strong>: Price per unit in the billing currency.</li> <li><strong>Total Charge</strong>: Calculated charge (Unit Price Volume/Duration).</li> <li><strong>Currency</strong>: ISO 4217 code (USD, EUR, etc.).</li> <li><strong>Rating ID</strong>: Identifier linking to the rule set that produced the charge.</li></ul><h2>Example File (PipeDelimited)</h2><pre>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</pre><p>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.</p><h2>Validation Rules</h2><ol> <li><strong>Mandatory fields</strong>: Every detail record must contain at least timestamp, service ID, originator, and total charge.</li> <li><strong>Data types</strong>: Dates must be ISO8601, numeric fields must contain only digits (and a single decimal point if required).</li> <li><strong>Length limits</strong>: If a fixedwidth layout is used, each column length is strictly enforced; excess characters cause a rejection.</li> <li><strong>Checksum</strong>: Most formats include a simple XOR or CRC checksum in the trailer for integrity checking.</li> <li><strong>Reference integrity</strong>: Rating IDs must exist in the rating engine's rule repository; otherwise the record is flagged.</li></ol><h2>Common Standards & Variants</h2><table> <thead> <tr><th>Standard</th><th>Domain</th><th>Key Features</th></tr> </thead> <tbody> <tr><td>3GPP CDR</td><td>Mobile Telephony</td><td>Supports IMSI, MSC, GGSN fields; typically CSV.</td></tr> <tr><td>ITUT C.250</td><td>Universal Billing</td><td>Defines a fixedwidth layout and optional XML wrapper.</td></tr> <tr><td>GSMA MAP CDR</td><td>Roaming</td><td>Binary TLV encoding for lowbandwidth links.</td></tr> <tr><td>OpenCGA CDR</td><td>Utility (Electricity/Water)</td><td>XMLbased, with nested measurement blocks.</td></tr> <tr><td>ETSI NFV CDR</td><td>Network Functions Virtualisation</td><td>JSON format focused on resource usage.</td></tr> </tbody></table><h2>Processing Pipeline Overview</h2><ol> <li><strong>Collection</strong> Network elements generate raw events.</li> <li><strong>Mediation</strong> Raw data is normalized, enriched, and written out in CDRIF.</li> <li><strong>Rating</strong> Rating engine reads the CDRs, applies pricing rules, and populates the Total Charge field.</li> <li><strong>Billing</strong> Rated records are aggregated into invoices or statements.</li> <li><strong>Archiving & Auditing</strong> Original CDR files are stored for the legally required retention period.</li></ol><h2>Best Practices</h2><ul> <li><strong>Versioning</strong>: Include a version identifier in the header; never change the layout without incrementing it.</li> <li><strong>Compression</strong>: Use gzip or bzip2 for bulk transfer; decompression should be lossless.</li> <li><strong>Streaming support</strong>: Design parsers to handle records linebyline, enabling processing of files that exceed RAM.</li> <li><strong>Error handling</strong>: Separate malformed records into a reject file with detailed error codes for later reprocessing.</li> <li><strong>Secure transport</strong>: Transfer files over SFTP, FTPS, or via HTTPS APIs; avoid plain FTP.</li></ul><h2>Future Directions</h2><p>As networks evolve towards 5G, IoT, and edge computing, CDRIF is expanding beyond traditional voice/SMS models:</p><ul> <li><strong>Eventdriven CDRs</strong>: Tiny records generated for each sensor reading or API call.</li> <li><strong>JSONLD and Avro</strong>: Selfdescribing formats that embed schema information, simplifying downstream processing.</li> <li><strong>Realtime streaming</strong>: Integration with Apache Kafka or Pulsar to push CDRs directly into analytics pipelines.</li> <li><strong>PrivacybyDesign</strong>: Tokenisation of subscriber identifiers and selective field masking to meet GDPRlike regulations.</li></ul><h2>Getting Started</h2><p>For a quick proofofconcept:</p><ol> <li>Decide on a delimiter (pipe is a safe default).</li> <li>Create a header with version and source identification.</li> <li>Generate a few sample detail lines using the field list above.</li> <li>Calculate total charges (unit price quantity) and add them.</li> <li>Append a trailer containing the record count and a simple checksum (e.g., sum of ASCII codes modulo 65536).</li> <li>Validate the file with a small script (Python, Bash, or PowerShell) that checks field count, data types, and checksum.</li></ol><p>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.</p><h2>References</h2><ul> <li>3GPP TS32.297 Charging Data Record formats.</li> <li>ITUT RecommendationC.250 CDR data definition.</li> <li>GSMA Charging for Roaming MAP CDR guidelines.</li> <li>ETSI NFVMANO specifications resource usage CDRs.</li> <li>OpenAPI & JSON Schema designing JSONbased CDRs.</li></ul>