IRI Blog Articles

Diving Deeper into Data Management



ASN.1 CDR Transformation & Reporting Support

by David Friedland

Every land line or cellular telephone call made over a Public Land Mobile Network (PLMN) creates one or more call records. These Call Detail Records (CDRs) or Usage Detail Records (UDRs) are generated by the mobile switching center (MSC) — the primary GSM/CDMA service delivery node responsible for routing voice calls, SMS, and other services.

CDRs contain information that the network operator uses for subscriber identification, call charging, services obtained, call routing, etc. After a “data collector” in the network switch captures the CDRs, they are usually converted by a “mediation” system from a binary format into a flat file format. CDRs are typically encoded in a format compliant with a standard called ASN.1 (Abstract Syntax Notation One), a flexible framework for representing data structures in telecommunications and computer networks.

Flat CDRs are used by downstream billing and analytic applications which need to consume that data. Indeed, IRI CoSort and most data integration (ETL) and telco application service provider (ASP) operations have been relying on mediation to convert and enrich the data first, because they cannot natively process the raw, binary ASN.1 formats themselves. That is because ASN is designed to stringently encode machine-generated data for communicating to a non-specific, downstream processor. Mediation has been necessary because of unknown processors, and because the records are structured, macro’d, and not human readable.

In raw form, in general, CDR data can have more than 700 fields which may or may not appear in the actual runtime stream. But again, the character strings and values are encoded in octets which are not human-readable.

Until now.

IRI has developed direct CDR support for the Sort Control Language (SortCL) data manipulation program so that IRI CoSort or IRI Voracity users can process native ASN.1 CDRs at runtime — without prior mediation. A custom input procedure or process type declaration for CDRs tells SortCL to perform the conversion and pass the flattened records in memory into the data transformation and reporting application you’ve written. This eliminates the need for separate mediation software and processing, and the extra I/O and storage required for that process.

Current prototypes support the future-looking TAP3 CDR standard. According to the GSMA (Groupe Speciale Mobile Association),

Roaming is a key feature of GSM, giving consumers seamless same-number contactability in over a hundred countries. Operators exchange call event details on these roaming subscribers. TAP is the process that allows a visited network operator (VPMN) to send billing records of roaming subscribers to their respective home network operator (HPMN). TAP3 is the latest version of the standard and will enable billing for a host of new services that networks intend to offer their customers.

TAP3 support will be documented as a supplement to the CoSort 9.5.3 manual, and IRI services can help you create CDR data integration, masking, migration, billing, and analytic reports using SortCL.  Other ASN.1-compatible CDRs can be handled through the same mechanism.

Note that you can also use the facility to pre-process your own forms of unstructured and semi-structured data, and feed it to SortCL. Consider not only the data processing you can do with those sources directly, but how can you can combine multiple sources of disparate ‘big data’ in a fast, low-cost data integration environment. See this article for more details.

Print Friendly

{ 0 comments… add one now }

Leave a Comment

Previous post:

Next post: