The present invention tackles the problem of decoding the so-called Charging Data Records (normally known by the acronym CDR) emitted by the nodes of a mobile telephone network.
These charging data records are currently decoded by employing solutions based on software applications, which, for example, decode GSM network records separately from those of an associated GPRS network. Specifically, the application is developed manually starting from the record coding specifications, and each time there is a modification/new release of the GSM and/or GPRS systems and when new functions are added, parts of the software must be to some extent rewritten.
There is consequently a need to provide solutions that can decode both GSM and GPRS format records, and for solutions that take into account the frequent updating of the record format after the introduction of new GSM and GPRS network services/performances, as well as the possibility of easy extension of the application to new functions such as UMTS.
This objective can be reached, according to this invention, by using a method that has the features referred to specifically in the claims that follow. The invention also refers to the relative system.
The solution, according to this invention, basically envisages the automatic generation of the logic that decodes the records. Whereas known solutions include the rewriting of the record decoding software whenever variations are introduced by the MSC manufacturer (Mobile Switching Center) or SGSN/GGSN (Serving GPRS Support Node and Gateway GPRS Support Node), the solution according to the invention simply requires the manufacturer to provide a formal record description of the ASN.1 type (Abstract Syntax Notation One). The solution, according to the invention, then uses this description to directly generate the code that decodes the data record. As a result, the decoder adaptation times can be cut from several weeks to a few days, making it easy to keep right up to date with the mobile network's frequent alterations.
The solution, according to the invention, includes the decoding of GSM records and GPRS records, which means that a single tool can be used on a mixed network employing both technologies. This is particularly advantageous if you consider that the operators of large-scale mobile telephone networks use both technologies in the network, in conditions in which the network update is carried out asynchronously. The solution, according to the invention, proposes to decode the data records for GSM and GPRS functions, but its main features also make it easy and quick to extend the solution to other functions such as UMTS.
The invention is hereafter described, by way of a non-limiting example only, with reference to the annexed drawings wherein:
As shown in
The input or log file 14 contains the records generated by the real network equipment (MSC for GSM records or SGSN/GGSN for GPRS records) in coded hexadecimal format.
The decoding operation is run on the basis of the set of user parameters that characterise the log file, the type of record (SGM/GPRS) and the output format.
In particular, starting from an initial step 100, the first steps in the operating sequence of the system 10 include the reading of the parameters sent to output, which are:
type of record to be decoded: GSM or GPRS (read by the system in step 102),
name of the log file to be decoded (step 104),
decoding format, i.e. the output format of the decoded file (read in step 106); this format may be “long”, when the decoding, the length and the contents in hexadecimal are given for each record field, or “short”, when only the decoding is given for each record field,
log file containing the records to be decoded (step 108), and
formal record description of the ASN.1 type (step 110). Depending on the record description, an interpreter, such as an ASN.1 interpreter, included in the processing core 12 (see block 18 in
The type of decoder selected (114 or 116) according to the parameter indicating the type of record (step 102) is further parameterised according to the parameters read in steps 104 and 106 (log file name and decoding format).
Once the decoder has been updated and programmed, it inputs (step 118) the file 14 containing the records to be decoded, and then outputs (step 120) the file containing the records decoded in text format. Reference 122 indicates the final step in the procedure.
Naturally, numerous changes can be made to the construction and embodiments of the invention envisaged and illustrated herein, without however departing from the scope of the present invention.
Number | Date | Country | Kind |
---|---|---|---|
TO2002A000201 | Mar 2002 | IT | national |
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/EP03/01978 | 2/26/2003 | WO |