Definition
CDR (Call Detail Record) is a record generated by telecom operators for each call or data session, containing fields such as caller and callee, ICCID, usage, time, region, PLMN, etc. In ICMP, CDR is the core data source for billing, Usage Aggregation, and Reconciliation, supporting Cross-Border Billing and Multi-Currency Settlement.
CDR Fields and Uses
Typical CDR fields include: identification (ICCID, IMSI, IMEI, MSISDN); usage (data traffic, call duration, number of SMS); time (start time, end time, duration); location (MCC/MNC, PLMN, country/region); billing (tariff, rate, currency). The platform aggregates CDRs to generate usage reports, Usage Analytics, billing according to Rate Card, and Reconciliation with operator bills.
Cross-Border Scenarios
In cross-border IoT scenarios, CDRs come from multiple operators, and formats, time zones, and currencies may not be consistent. ICMP needs to support CDR parsing, normalization, time zone conversion, and currency conversion; support Usage Aggregation aggregated by customer, by SIM, and by region; support Usage Analytics to analyze roaming behavior and abnormal consumption. CDRs need to interface with Roaming Partner settlement data to support Multi-Currency Settlement.
Data Quality and Compliance
CDRs need to ensure completeness, accuracy, and timeliness. The platform must handle lost records, delays, duplicates, and format exceptions; support CDR retransmission, recalculation, and reconciliation of differences. CDRs contain user communication data, and storage and processing must comply with GDPR and Data Residency requirements. Sensitive fields must be anonymized or encrypted, and access must be logged to Audit Trail.
The detail record as the billing atom of one session
A detail record is the operator’s record of a call, message, or data session that has already happened. It is not traffic the platform estimated for itself. For data, it often arrives as a charging data record, and the fields still have to point back to that one session: which SIM, which device, from when to when, how much, on which network, and through which access point. Rating, usage totals, and reconciliation should all use this record as the atom. Invoicing from counters the device reported, before any detail record exists, usually fails to match the operator’s bill later.
A long session may produce partial records first, and a final record when the session ends. Partial records are for usage that is close to real time. Only the final record is fit to invoice from. Adding every partial as if it were an independent session counts the traffic more than once. The visited network and country on the record are the basis for geographic rates. Without that set of fields, rating falls back to a single default price.
Fields that must be complete before a record can be posted
Before posting, four questions have to be answerable: who generated it, over which closed time interval, how much usage, and which price version applies. The matching fields are a SIM or subscriber identifier, start and end time, a time zone or one shared time standard, byte count or call duration, visited network, access point, and a rate version that can be matched. The amount can be recalculated on the platform from the rate, but the usage in that calculation must come from the detail record, not from a report that has already been rounded.
A cross-border record also has to be placed in the customer’s billing period. The operator cuts records by its own settlement day and local time. If the platform invoices by the calendar month where the customer is, sessions on the boundary need one attribution rule: start time or end time, and the same rule for the whole month. If that conflicts with usage aggregation, the total that can be traced back to the original records wins. A record that cannot be matched to a rate should go to a pending queue, not be posted at zero or at an arbitrary unit price. An empty currency field cannot be assumed to match the settlement currency of cross-border billing.
Billing gaps from time zones, duplicates, and late arrival
If the time zone is not stated, the same record is placed on two adjacent days by two systems, and the start-of-month reconciliation shows a steady one-day shift. Duplicates come from retransmission and retries: the same content with a different sequence number, or the same sequence number with a slightly corrected volume. Without a deduplication key, a retransmission doubles usage. A key that is too coarse drops a later volume correction. Late arrival is more common in roaming. A visited-network record reaches the home network days later. If the period is already closed and late records are refused, the customer’s usage for this month is low, and next month suddenly shows an adjustment.
Keep the original record and store adjustments separately. Do not change a historical invoice already sent to the customer and leave no trace. Deduplicate first on the record number the operator supplied. If there is no record number, use the SIM identifier, start time, end time, and network together, and let a volume correction become an adjustment rather than a discard. Do not mix test sessions and production sessions in the same posting pipeline. Isolate and count malformed rows. One bad row must not drop the whole batch, and the whole batch must not be posted as success either. A reconciliation difference should say whether records are missing, duplicated, or on a different price version, not only quote a total gap.
Link partial records and the final record with the same session key, and state which one the display uses and which one invoicing uses. A real-time page may add up partial records that are not yet closed. Month-end uses only the final record. If the final record never arrives, list the unclosed session as an exception, rather than treating partial records as final usage forever. A retransmission file should carry the original billing period and land as an adjustment, not as a new month. If a file-level check fails, isolate the whole file. If a single row fails, isolate that row and count it. Without that split, more retransmissions make the gap larger, because the old month and the new month each record the usage once.