Content for TS 32.297 Word version: 18.1.0

5.0 General 5.1 Local CDR and CDR file handling 5.2 File format principles 5.3 File transport and protocol 5.4 File transfer modes and session management

4 Architecture considerations p. 12

"Bx" is a common designator for the reference points from the network to the Billing Domain (BD) that are intended for the transport of CDR files. The letter "x" indicates the different 3GPP network domain, subsystem or service, where

represents 5G connection and mobility in TS 32.256,

represents Circuit Switched (CS) in TS 32.250,

represents Control Plane data transfer (CP) in TS 32.253,

represents 5G Data Connectivity in TS 32.255,

represents Exposure function API in TS 32.254,

represents Edge Computing in TS 32.257,

represents IP Multimedia Subsystem (IMS) in TS 32.260,

represents Location Service (LCS) in TS 32.271,

represents Multimedia Messaging Service (MMS) in TS 32.270,

represents Multimedia Broadcast/Multicast Service (MBMS) in TS 32.273,

represents Network Slice in TS 28.201 and TS 28.202,

nsac

represents Network Slice admission control in TS 28.203,

nsssaa

represents Network slice-specific authentication and authorization in TS 28.204,

represents the Online Charging System (OCS) in TS 32.296,

represents Packet Switched (PS) in TS 32.251,

represents Proximity-based Services (ProSe) in TS 32.277,

represents the CAMEL SCF in TS 23.078,

represents Short Message Service (SMS) in TS 32.274,

represents the PoC service (PoC) in TS 32.272,

tsn

represents time sensitive networking in TS 32.282,

represents interworking Wireless LAN (discontinued in Release 12), and

represents Monitoring Event in TS 32.278.

In the 3GPP charging architecture, the Bx reference point connects the CGF in each network domain, service or subsystem to the Billing Domain.

Further details of the Billing Domain, i.e. beyond terminating Bx, are outside the scope of 3GPP standardization. Refer to TS 32.240 for the complete description of the 3GPP charging architecture.

Note that the OCS can also generate CDRs and transfer them to the BD across the Bo reference point as described in TS 32.296.

Furthermore the GSM SCF, defined in CAMEL, can also generate CDRs and transfer them to the BD across the Bs reference point as described in TS 23.078.

5 CDR file transfer principles and scenarios p. 13

5.0 General |R12| p. 13

This clause contains specifications for the principles and scenarios covering the CDR file transfer interface from the network to the Billing Domain. These specifications apply to all domains, subsystems and services that are listed in clause 4, including the OCS Bo and the GSM SCF's Bs interface. Alternatively, in the CS domain (i.e. for Bc), the file transfer mechanism specified in TS 32.250 may be used. Consequently, for Bc it is up to implementation choice to provide either the legacy interface, the interface specified in the present document, or both.

The scenarios in this clause are divided into the following categories:

Local CDR and CDR file handling;
File format principles;
File transport and protocol;
File transfer modes and session management.

Other interface principles such as security and performance are dependent on vendor implementation and operator's network design and are not covered by the present document.

5.1 Local CDR and CDR file handling p. 13

5.1.1 CDR processing p. 13

The CGF collects CDRs from the CDF. If the CDF and the CGF are separate entities, then the standard Ga interface as specified in TS 32.295 is used to transfer the CDRs from the CDF to the CGF.

If CDF and CGF are integrated, then a proprietary, internal mechanism is used. The possibilities of separate or integrated CDF and CGF are specified per domain, subsystem and service in the respective "middle tier" charging TSs, i.e. those in the [10] through [49] reference number range, and in TS 32.296 for the OCS.

In any case, CDRs are transferred, in near real-time, from the CDF to the CGF as soon as they have been closed by the CDF. Refer to TS 32.295 for further details. Once received by the CGF, the CDRs may undergo semantical and/or syntactical sanity checks, however, these checks are not specified further within the present document.

If the CGF determines that a CDR is not well formatted, or otherwise incorrect, then the defective CDR parameter(s) shall be filled with an appropriate "replacement" indicator within the limits of the syntax allowed for the parameter.

If the error renders the complete CDR unusable (i.e. the above replacement of erroneous parameters is not possible), then no further action of the CGF can be performed regarding this CDR. An example of a case where the erroneous parameter cannot be replaced is when the "CDR type" attribute of a CDR received by the CGF is corrupted.

Details of this function are implementation specific.

CDRs that have been processed by the CGF without error, or where errors have been corrected by the CGF as described above, are considered "acceptable" by the CGF. CDRs that have non-recoverable errors are not considered "acceptable" by the CGF. The "acceptable" CDRs are immediately placed into a CDR file by the CGF.

The CDRs that are not "acceptable" should be properly reflected in an error log and appropriate alarms should be generated, after which they may be destroyed. Furthermore, to the extent possible, the number of lost CDRs and the fact that CDRs were lost, shall be indicated in the CDR file.

It is acknowledged that the processing of a CDR between being received until it is placed on the CDR file, takes a small amount of time. Hence, where the present document mandates the "immediate" treatment of CDRs received by the CGF, it is to be interpreted such that it is not allowed to postpone the processing of any received CDRs for any reason. In technical terms, "immediate" shall be interpreted as:

The system shall be capable of complying with near real-time requirements as specified in clause 3.1.
The system should be capable of complying, as closely as possible, with real-time requirements as specified in clause 3.1.

Once a CDR has been stored on the appropriate file, the CGF may destroy any other reference to that CDR.

5.1.2 CDR routing p. 14

In the default mode of operation, the CGF manages a single ("default") file for the storage of all "acceptable" CDRs. However, the CGF may also route CDRs to different files that are kept open concurrently, i.e. additional files may be configured by OAM&P commands together with associated CDR routeing filters. While the CGF stores only those CDRs matching the associated routeing filter on each of the additional files, the default file is used to store all CDRs that do not match any of the routeing filters configured for the additional files.

The CDR routeing function shall apply CDR parameters and CDR origin to decide into which file to place the CDR. The file name shall, within the limits of the file naming conventions, contain an indication of the CDR routeing filter applied.

As a minimum, each CGF implementation shall support the CDR type and the sending CDF as selection criteria for CDR routeing. It shall then be possible to include in a file only the following CDRs:

CDRs of a single type;
CDRs of a set of specified types (e.g. only IMS CDR types);
CDRs originated by a single CDF;
CDRs originated by a set of CDFs;
Any combination of the above.

Further details of the CDR routeing function, such as:

the maximum number of simultaneously open CDR files;
the order in which the routeing filters are evaluated;
the way CDR filters can be configured by OAM&P;

are implementation specific. In order to avoid arbitrary routeing of CDRs, operators should assure that the routeing filters assigned per file, do not overlap with each other.

The term "matching CDR" is used in the present document to denote a CDR that matches the routeing filter of a given CDR file.

5.1.3 Local CDR file management p. 15

For the default case, plus each of the additional CDR routeing filters that may be set up on the CGF (see clause 5.1.2), the CGF provides a non-interrupted chain of CDR files. As described above, each CDR is immediately stored in the appropriate file after being received and determined "acceptable" by the CGF.

Several conditions may govern the closure of a CDR file by the CGF:

A configurable file size limit;
A configurable file closure time;
A configurable file lifetime ("interval");
A configurable number of CDRs within the file;
CDR release, version or encoding change;
Manual OAM&P actions;
System defined reasons (e.g. file system full).

When a CDR file is closed, the next matching CDR shall be placed in the next file in the chain.

The exact time when this next CDR file is physically generated, i.e.:

immediately after the previous file has been closed (i.e. the earliest possible time),
when the next matching CDR arrives (i.e. the latest possible time),
anytime in between,

is implementation specific. However, each CDR file shall contain all "acceptable" matching CDRs received and processed by the CGF between the closure of the previous file and the configured file closure trigger of the current file, as specified above. In any case, a file shall be generated and closed upon the occurrence of the file closure trigger, i.e. an empty file (containing no CDRs) if no matching CDRs arrived since the closure of the last file in the chain.

Upon file closure, the CDR file is immediately available for transfer to the BD.

CDR files may be removed from the CGF in one of the following ways:

By the BD issuing corresponding commands provided by the file transfer protocol;
By the CGF application once the file has been transferred;
Due to CGF file system storage limitation or configurable file age limits;
OAM&P action.

In order to avoid loss of CDRs, operators should manage the system in a way that the "system defined" file closure triggers mentioned above do not occur.

5.2 File format principles p. 16

The CDR file format is depicted in Figure 5.2.1.

Copy of original 3GPP image for 3GPP TS 32.297, Fig. 5.2.1: CDR file format

Figure 5.2.1: CDR file format
(⇒ copy of original 3GPP image)

The CDR files contain a variable length header section followed by a variable sized CDR data section.

The CDR data section contains zero or more concatenated CDRs. Each CDR in a file includes a header indicating the CDR length, data record format, release, version and encoding scheme.

The BD should use a decoder with a version number which is equal or greater of this version to be able to decode all the CDRs in the file.

Clause 6 specifies the file format applying the above principles at bit level detail.

5.3 File transport and protocol p. 17

5.3.0 General |R12| p. 17

Two mechanisms are defined for the transport of CDR files from the CGF to the BD:

A basic transport mechanism is defined in clause 5.3.1 and shall be supported by all CGF implementations;
The use of the File Transfer IRP as described in clause 5.3.2 may additionally be supported by the CGF as an implementation option.

The use of IPDR as described in clause 5.3.3 may optionally be supported on the Bx reference point.

5.3.1 Basic file transport mechanism p. 17

The following stipulations govern the choice and usage of file transport protocol for this transport mechanism.

The default protocol for CDR file transport is FTP (RFC 959).
The use of other protocols is optional, however FTP shall always be supported.
The CDR files may be transferred in either push or pull mode on the Bx interface. Further specifications of these transfer modes are provided in clause 5.4.1 and clause 5.4.2, respectively.
All standard FTP commands specified in RFC 959 shall be supported by the CGF.

All further requirements specified within the present document with reference to the operation of the file transfer protocol in this mechanism (see clause 6), are solely related to FTP as the transfer protocol, as no assumptions can be made as to the ways of working of optional other protocols. However, additional protocols shall be implemented such that, to the extent possible, the same logic is applied as described in the present document for FTP.

5.3.2 Use of File Transfer IRP p. 17

The File Transfer IRP is specified in TS 32.341, TS 32.342, TS 32.343 and TS 32.344 [204].

The support of the solution sets (CORBA, CMIP or both) is left to implementation choice. Otherwise, the CGF implementation of the IRP shall comply with the above TSs; i.e. there are no further additions or limitations with regard to the use of the IRP in charging.

5.3.3 Use of IPDR |R7| p. 17

As depicted in ATIS-PP-0300075.1.200X [401] IPDR file transfer or streaming protocol can be used for the Bx reference point.

The IPDR file transfer is specified in IPDR/File Transfer Protocol [402].

The IPDR streaming protocol is specified in IPDR/SP [403].

5.4 File transfer modes and session management p. 18

5.4.1 Basic file transfer mechanism p. 18

5.4.1.0 Introduction |R12| p. 18

Files can be transferred to the BD in one, or both, of the following modes.

Detailed FTP file transfer and session management procedures are specified in clause 6.

5.4.1.1 Push mode p. 18

In this transfer mode the CDR files are written from the CGF to the BD filestore at a time and/or frequency controlled by the CGF. I.e. the CGF pushes the files to the BD. This implies that the CGF operates in client mode and the BD in server mode. If the CGF generates concurrent CDR files based on the CDR routeing function specified in clause 5.1.2, then it shall be able to send the different files to different BD systems; i.e. the BD address is part of the CDR file routeing filter.

As a minimum, the following events shall be capable of triggering a file push in the CGF:

A (configured number of) new CDR file(s) has become available for transmission;
The CDR file / files has / have exceeded a configurable (total) size limit;
A configurable, regular time interval has elapsed;
The CGF filestore utilization has exceeded a configurable level.

If the file transfer fails, the CGF should properly reflect this in an error log and generate appropriate alarms.

Possible measures to handle file transfer failures are discussed in clause 6.

Security measures, e.g. the mutual identification / verification of the peer systems, are outside the scope of the present document.

5.4.1.2 Pull mode p. 18

In this transfer mode the BD reads the CDR files that are available in the appropriate CGF directories.

The time and/or frequency of the file transfer is controlled by the BD. I.e. the BD pulls the files from the CGF.

This implies that the CGF operates in server mode and the BD in client mode.

In this mode, the BD may request the files from the CGF at any point in time at the discretion of the BD, i.e. the CGF cannot make any assumptions of the time or frequency of the file pull to occur. If the file transfer fails, any further action is up to the BD, however, the CGF should properly reflect this in an error log and generate appropriate alarms. Possible measures to handle file transfer failures are covered in clause 6.

Security measures, e.g. the mutual identification / verification of the peer systems, are outside the scope of the present document.

5.4.2 Use of File Transfer IRP p. 18

File transfer modes and session management using the optional File Transfer IRP are governed by TS 32.341, TS 32.342, TS 32.343 and TS 32.344 [204].

5.4.3 Use of IPDR |R7| p. 18

File transfer mode and session management using the optional IPDR protocols are governed by IPDR File Transfer [402] or streaming protocol [403].