ETSI TS 132 295 V16.0.0 (2020-08)

Digital cellular telecommunications system (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); LTE; Telecommunication management; Charging management; Charging Data Record (CDR) transfer (3GPP TS 32.295 version 16.0.0 Release 16)

RTS/TSGS-0532295vg00

General Information

• Status: Not Published
• Technical Committee: 3GPP SA 5 - Telecom Management
• Current Stage: 12 - Completion
• Completion Date: 13-Aug-2020

Standards Content (Sample)

TECHNICAL SPECIFICATION
Digital cellular telecommunications system (Phase 2+) (GSM);
Universal Mobile Telecommunications System (UMTS);
LTE;
Telecommunication management;
Charging management;
Charging Data Record (CDR) transfer
(3GPP TS 32.295 version 16.0.0 Release 16)

3GPP TS 32.295 version 16.0.0 Release 16 1 ETSI TS 132 295 V16.0.0 (2020-08)

Reference
RTS/TSGS-0532295vg00
Keywords
GSM,LTE,UMTS
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2020.
All rights reserved.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.

3GPP™ and LTE™ are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3GPP TS 32.295 version 16.0.0 Release 16 2 ETSI TS 132 295 V16.0.0 (2020-08)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Legal Notice
This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities. These shall be
interpreted as being references to the corresponding ETSI deliverables.
The cross reference between 3GPP and ETSI identities can be found under http://webapp.etsi.org/key/queryform.asp.
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
3GPP TS 32.295 version 16.0.0 Release 16 3 ETSI TS 132 295 V16.0.0 (2020-08)
Contents
Intellectual Property Rights . 2
Legal Notice . 2
Modal verbs terminology . 2
Foreword . 5
1 Scope . 6
2 References . 6
3 Definitions, symbols and abbreviations . 7
3.1 Definitions . 7
3.2 Symbols . 9
3.3 Abbreviations . 10
4 Architecture considerations . 11
4.1 High level architecture . 11
5 Transfer principles and scenarios . 12
5.1 Transfer principles . 12
5.1.0 General . 12
5.1.1 Charging related transfer requirements . 12
5.1.2 CDR transport by GTP' . 12
5.1.2.1 CDF - CGF communication . 12
5.1.2.2 CGF - CGF communication . 12
5.1.3 Port usage . 14
5.2 GTP' transfer scenarios . 15
5.2.1 Basic principles . 15
5.2.2 GTP' messaging cases . 15
5.2.2.0 General . 15
5.2.2.1 The normal CDR packet transfer . 16
5.2.2.2 The CDF-CGF connection breaks before a successful CDR reception . 17
5.2.2.3 The CDF-CGF connection breaks after a successful CDR reception . 19
5.2.2.4 CGF redundancy mechanism . 21
6 Data description for the transfer . 24
6.1 The GTP' charging protocol . 24
6.1.0 General . 24
6.1.1 Usage of GTP header in charging . 24
6.1.2 Information Elements (IEs). 24
6.2 GTP' message types . 25
6.2.1 List of all GTP' message types . 25
6.2.2 Reused GTP message types . 26
6.2.3 GTP message type modifications, implied by GTP' . 27
6.2.4 GTP' message types . 27
6.2.4.0 General . 27
6.2.4.1 Node Alive Request . 27
6.2.4.2 Node Alive Response . 27
6.2.4.3 Redirection Request . 28
6.2.4.4 Redirection Response . 29
6.2.4.5 Data Record Transfer Request . 29
6.2.4.5.0 Introduction . 29
6.2.4.5.1 Information Elements in Data Record Transfer Request . 29
6.2.4.5.2 Packet Transfer Command IE . 30
6.2.4.5.3 Data Record Packet IE . 31
6.2.4.5.4 Sequence Numbers of Released Packets IE . 31
6.2.4.5.5 Sequence Numbers of Cancelled Packets IE . 32
6.2.4.5.6 Private Extension IE . 32
6.2.4.6 Data Record Transfer Response . 33
ETSI
3GPP TS 32.295 version 16.0.0 Release 16 4 ETSI TS 132 295 V16.0.0 (2020-08)
6.3 Data Record Format in GTP' . 34
6.3.0 Introduction. 34
6.3.1 Standard Data Record Format . 34
6.3.2 Private Data Record Formats . 34
6.4 Data Record Format Version for CDRs . 35
Annex A (informative): Bibliography . 36
Annex B (informative): Change history . 37
History . 38

ETSI
3GPP TS 32.295 version 16.0.0 Release 16 5 ETSI TS 132 295 V16.0.0 (2020-08)
Foreword
rd
This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.
ETSI
3GPP TS 32.295 version 16.0.0 Release 16 6 ETSI TS 132 295 V16.0.0 (2020-08)
1 Scope
The present document is part of a series of Technical Specifications (TSs) that specify charging functionality and
charging management in 3GPP networks (GSM/UMTS/EPS). The 3GPP core network charging architecture and
principles are specified in TS 32.240 [1], which provides an umbrella for other charging management TSs that specify:
- the content of the CDRs per domain / subsystem / service (offline charging);
- the content of real-time charging messages per domain / subsystem / service (online charging);
- the functionality of online and offline charging for those domains / subsystems / services;
- the interfaces that are used in the charging framework to transfer the charging information (i.e. CDRs or
charging events)
The complete document structure for these TSs is defined in TS 32.240 [1].
The present document specifies the transaction based mechanism for the near real time transfer of CDRs
within the network.
The present document is related to other 3GPP charging TSs as follows:
- The common 3GPP charging architecture is specified in TS 32.240 [1];
- The parameters, abstract syntax and encoding rules for the CDRs are specified in TS 32.298 [51];
- The file based mechanism used to transfer the CDRs from the network to the operator's Billing Domain (e.g. the
post-processing system or a mediation device) is specified in TS 32.297 [52];
The 3GPP Diameter application that is used for offline and online charging is specified in TS 32.299 [50].
All terms, definitions and abbreviations used in the present document, that are common across 3GPP TSs, are defined in
the 3GPP Vocabulary, TR 21.905 [100]. Those that are common across charging management in 3GPP domains
services, or subsystems are provided in the umbrella document TS 32.240 [1] and are copied into clause 3 of the present
document for ease of reading. Finally, those items that are specific to the present document are defined exclusively in
the present document.
Furthermore, requirements that govern the charging work are specified in TS 22.115 [101].
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
- References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
- For a specific reference, subsequent revisions do not apply.
- For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.
[1] 3GPP TS 32.240: "Telecommunication management; Charging management; Charging
architecture and principles".
[2] - [9] Void.
[10] 3GPP TS 32.250: "Telecommunication management; Charging management; Circuit Switched
(CS) domain charging".
[11] 3GPP TS 32.251: "Telecommunication management; Charging management; Packet Switched
(PS) domain charging".
ETSI
3GPP TS 32.295 version 16.0.0 Release 16 7 ETSI TS 132 295 V16.0.0 (2020-08)
[12] - [29] Void.
[30] 3GPP TS 32.270: "Telecommunication management; Charging management; Multimedia
Messaging Service (MMS) charging".
[31] - [49] Void.
[50] 3GPP TS 32.299: "Telecommunication management; Charging management; Diameter charging
application".
[51] 3GPP TS 32.298: "Telecommunication management; Charging management; Charging Data
Record (CDR) parameter description".
[52] 3GPP TS 32.297: "Telecommunication management; Charging management; Charging Data
Record (CDR) file format and transfer".
[53] - [99] Void.
[100] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
[101] 3GPP TS 22.115: "Service aspects; Charging and billing".
[102] - [199] Void.
[200] 3GPP TS 29.060: "General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP)
across the Gn and Gp interface".
[201] 3GPP TS 29.274: "3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service
(GPRS) Tunnelling Protocol for Control plane (GTPv2-C); Stage 3".
[202] - [299] Void.
[300] - [399] Void.
[400] - [403] Void.
[404] IETF RFC 768 (1980): "User Datagram Protocol" (STD 6).
[405] IETF RFC 793 (1981): "Transmission Control Protocol" (STD 7).
[406] IETF RFC 791 (1981): "Internet Protocol" (STD 5).
[407] IETF RFC 792 (1981): "Internet Control Message Protocol" (STD 5).
3 Definitions, symbols and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions given in TR 21.905 [50], TS 32.240 [1],
and the following apply:
2G- / 3G-: prefixes 2G- and 3G- refers to functionality that supports only GSM or UMTS, respectively, e.g. 2G-CDF
refers only to the GSM functionality of an CDF.
accounting: process of apportioning charges between the Home Environment, Serving Network and User.
billing: function whereby CDRs generated by the charging function are transformed into bills requiring payment.
Billing Domain: Part of the operator network, which is outside the core network, that receives and processes CDR files
from the core network charging functions. It includes functions that can provide billing mediation and billing other (e.g.
statistical) end applications. It is only applicable to offline charging (see "Online Charging System" for equivalent
functionality in online charging).
chargeable event: activity utilizing telecommunications network infrastructure and related services for:
ETSI
3GPP TS 32.295 version 16.0.0 Release 16 8 ETSI TS 132 295 V16.0.0 (2020-08)
- user to user communication (e.g. a single call, a data communication session or a short message); or
- user to network communication (e.g. service profile administration); or
- inter-network communication (e.g. transferring calls, signalling, or short messages); or
- mobility (e.g. roaming or inter-system handover); and
- that the network operator wants to charge for.
charged party: user involved in a chargeable event who has to pay parts or the whole charges of the chargeable event,
or a third party paying the charges caused by one or all users involved in the chargeable event, or a network operator.
charging: function whereby information related to a chargeable event is formatted and transferred in order to make it
possible to determine usage for which the charged party may be billed.
Charging Data Record (CDR): A formatted collection of information about a chargeable event (e.g. time of call set-
up, duration of the call, amount of data transferred, etc) for use in billing and accounting. For each party to be charged
for parts of or all charges of a chargeable event a separate CDR shall be generated, i.e. more than one CDR may be
generated for a single chargeable event, e.g. because of its long duration, or because more than one charged party is to
be charged.
charging function: entity inside the core network domain, subsystem or service that is involved in charging for that
domain, subsystem or service.
circuit switched domain: domain within GSM / UMTS in which information is transferred in circuit mode.
domain: part of a communication network that provides services using a certain technology.
GPRS: Packet Services for GSM and UMTS systems.
GTP': GPRS protocol, used for CDR transport. It is derived from GTP with enhancements to improve transport
reliability necessary for CDRs. NOTE: This protocol is not used for tunnelling.
GSM only: qualifier indicating that this clause or paragraph applies only to a GSM system. For multi-system cases this
is determined by the current serving radio access network.
inter-system change: change of radio access between different radio access technologies such as GSM and UMTS.
in GSM,.: qualifier indicating that this paragraph applies only to GSM System.
in UMTS,.: qualifier indicating that this paragraph applies only to UMTS System.
middle tier TS: used for the 3GPP charging TSs that specify the domain / subsystem / service specific, online and
offline, charging functionality. These are all the TSs in the numbering range from TS 32.250 [10] to TS 32.27x [3x],
e.g. TS 32.250 [10] for the CS domain, or TS 32.270 [30] for the MMS service. Currently, there is only one "tier 1" TS
in 3GPP, which is the TS 32.240 [1] that specifies the charging architecture and principles. Finally, there are a number
of top tier TSs in the 32.29x numbering range ([50] ff) that specify common charging aspects such as parameter
definitions, encoding rules, the common BD interface or common charging applications.
near real time: near real time charging and billing information is to be generated, processed, and transported to a
desired conclusion in less than one (1) minute.
observed IMEI ticket: record used to describe an EIR relevant event e.g. a blacklisted IMEI.
offline charging: charging mechanism where charging information does not affect, in real-time, the service rendered.
online charging: charging mechanism where charging information can affect, in real-time, the service rendered and
therefore a direct interaction of the charging mechanism with session/service control is required.
Online Charging System: the entity that performs real-time credit control. Its functionality includes transaction
handling, rating, online correlation and management of subscriber accounts/balances.
packet switched domain: domain in which data is transferred between core network elements.
Real-time: real time charging and billing information is to be generated, processed, and transported to a desired
conclusion in less than 1 second.
ETSI
3GPP TS 32.295 version 16.0.0 Release 16 9 ETSI TS 132 295 V16.0.0 (2020-08)
subscriber: A subscriber is an entity (associated with one or more users) that is engaged in a Subscription with a
service provider. The subscriber is allowed to subscribe and unsubscribe services, to register a user or a list of users
authorized to enjoy these services, and also to set the limits relative to the use that associated users make of these
services.
UMTS only: qualifier indicating that this clause or paragraph applies only to a UMTS system. For multi-system cases
this is determined by the current serving radio access network.
user: An entity, not part of the 3GPP System, that uses network resources by means of a subscription. The user may or
may not be identical to the subscriber holding that subscription.
3.2 Symbols
For the purposes of the present document, the following symbols apply:
Bx The reference point between any (generic) 3G domain, subsystem or service CGF and the BD.
Ga Reference point between a CDF and the CGF for CDR transfer.
Rf Reference Point between the CTF within a 3G network element and the CDF for offline charging.

ETSI
3GPP TS 32.295 version 16.0.0 Release 16 10 ETSI TS 132 295 V16.0.0 (2020-08)
3.3 Abbreviations
For the purposes of the present document, the abbreviations defined in TR 21.905 [50] and the following abbreviations
apply:
rd
3G 3 Generation
rd
3GPP 3 Generation Partnership Project
AS Application Server
ASN.1 Abstract Syntax Notation One
BD Billing Domain
CDF Charging Data Function
CDR Charging Data Record
CG Charging Gateway
CGF Charging Gateway Function
CS Circuit Switched
DRP Data Record Packet
EPC Evolved Packet Core
EPS Evolved Packet System
E-UTRAN Evolved Universal Terrestrial Radio Access Network
GPRS General Packet Radio Service
GTP GPRS Tunnelling Protocol
GTPv2-C GTP version 2 – Control Plane
GTP' GPRS protocol, used for CDR transport
IE Information Element
IP Internet Protocol
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
NE Network Element
OAM&P Operation, Administration, Maintenance and Provisioning
OCS Online Charging System
PDN Packet Data Network
PS Packet-Switched
PT Protocol Type (Field in GTP' header)
S-SMO-CDR SGSN Short Message Mobile Originated - CDR
TAP Transferred Account Procedure
TLV Type, Length, Value (GTP header format)
TV Type, Value
ETSI
3GPP TS 32.295 version 16.0.0 Release 16 11 ETSI TS 132 295 V16.0.0 (2020-08)
4 Architecture considerations
4.1 High level architecture
The Ga is the reference point from the Charging Data Function (CDF) to the Charging Gateway Function (CGF), which
is intended for the transport of Charging Data Records (CDRs).
By definition, dealing with CDRs only implies that Ga is solely related to offline charging.
Figure 4.1.1 depicts the position of the Ga reference point within the overall 3GPP offline charging architecture.

3GPP network
CN
Domain
C
C
C
Service
B
R  G x
a
f Billing
T
G
nodes
D
Domain
F
F F
-
Sub
system
CTF: Charging Trigger Function
CDF: Charging Data Function
CGF: Charging Gateway Function
BD: Billing Domain. This may also be a billing mediation device / post-processing system.

Figure 4.1.1: Logical ubiquitous offline charging architecture
As illustrated in figure 4.1.1, the CDF in each network domain, service or subsystem is relevant for the network side of
the Ga reference point. Different mappings of the ubiquitous offline charging functions, CDF and CGF, onto physical
implementations are possible. Further details of the configuration refer to TS 32.240 [1]. Details of the implementation
options per domain / subsystem / service (usually a subset of the overall possible variants described above) are specified
in the respective middle tier TS, e.g. for EPC Charging in TS 32.251 [11].
The transport protocol associated to the Ga reference point, providing functions for transfer of CDRs from CDF to
CGF, is GTP' (because of its derivation from the GTP protocol as specified in TS 29.060 [200]).
ETSI
3GPP TS 32.295 version 16.0.0 Release 16 12 ETSI TS 132 295 V16.0.0 (2020-08)
5 Transfer principles and scenarios
5.1 Transfer principles
5.1.0 General
The GTP' protocol is optional, and is used for CDR transport between the CDFs and the CGF.
5.1.1 Charging related transfer requirements
Each CDF has an OAM&P configurable address list of CGFs (Charging Gateways) to which it can send its CDRs. The
list is organized in CGF address priority order. If the primary CGF is not available (e.g. out of service), then the CDF
shall send the CDRs to the secondary CGF and so on.
Each CDR generating function only sends the records to the CGF(s) of the same PLMN, not to CGF(s) located in other
PLMNs.
Each CGF in the PLMN may know of other CGFs' network addresses (e.g., for redundancy reasons, to be able to
recommend another CGF address). This is achieved by OAM&P configuration facilities that enable each CGF to have a
configurable list of peer CGF addresses.
5.1.2 CDR transport by GTP'
GTP' has been designed to deliver the CDR(s) from the CDF, which generates CDRs to the CGF(s). This protocol is
required if the CGF resides outside the CDFs. It utilizes some aspects of GTP (defined in
TS 29.060 [200]), which is used for packet data tunnelling in the backbone network.
GTP' operates on the Ga interface and does not imply the use of any specific backbone network.
GTP' performs the following functions:
- CDR transfer between the CDF and the CGF.
- Redirection of CDRs to another CGF.
- Detect communication failures between the communicating peers, using echo messaging.
- Advertise to peers about its CDR transfer capability (e.g., after a period of service downtime).
- Prevents duplicate CDRs that might arise during redundancy operations.
If so configured, the CDR duplication prevention function may also be carried out by marking potentially
duplicated CDR packets, and, delegating the final duplicate deletion task to a CGF or the Billing Domain
(instead of handling the possible duplicates solely by GTP' messaging).
5.1.2.1 CDF - CGF communication
As illustrated in figure 5.1.2.1.1, the CDF - CGF communications are carried out using GTP' over UDP/TCP and IP.

Figure 5.1.2.1.1: Protocol layers between the CDF and the CGF

CDRs CDRs
5.1.2.2 CGF - CGF communication
If necessary, CGF to CGF communications are carried out using GTP' over UDP/TCP and IP.
This is illustrated in figure 5.1.2.2.1.
GTP’ GTP’
UDP/TCP UDP/TCP
IP IP
L2 L2
ETSI
L1 L1
3GPP TS 32.295 version 16.0.0 Release 16 13 ETSI TS 132 295 V16.0.0 (2020-08)

Figure 5.1.2.2.1: Protocol layers between CGFs
CDRs CDRs
GTP’ GTP’
UDP/TCP UDP/TCP
IP
IP
L2 L2
L1 L1
CGF CGF
ETSI
3GPP TS 32.295 version 16.0.0 Release 16 14 ETSI TS 132 295 V16.0.0 (2020-08)
5.1.3 Port usage
Transporting the CDRs from the CDFs to the CGF over the Ga reference point may facilitate charging.
The Path Protocol may be UDP (compliant with STD 0006 [404]) or TCP (compliant with STD 0007 [405]) over IP.
- UDP as the Path Protocol
Ports for signalling the request messages:
- The UDP Destination Port may be the server port number 3386 which has been reserved for GTP’.
Alternatively another port can be used, which has been configured by OAM&P, except Port Number 2123
which is used by GTPv2-C.
- The UDP Source Port is a locally allocated port number at the sending network element.
NOTE: UDP Source Port number should be different than UDP Source Port number allocated to GTPv2
(see TS 29.274 [201]).
Ports for signalling the response messages:
- The UDP Destination Port value shall be the value of the Source Port of the corresponding request message.
- The UDP Source Port shall be the value from the Destination Port of the corresponding request message.
- TCP as Path Protocol
The TCP Destination Port may be the server port number 3386, which has been reserved for G-PDUs.
Alternatively, another port may be used as configured by OAM&P. Extra implementation-specific destination ports
are possible but all CGFs shall support the server port number.
The TCP Source Port is a random port, locally assigned at the sending network element.
- Network layer and lower layers
Beneath the Path Protocol there is the network IP layer, which shall be the Internet Protocol (IP) compliant with
STD 0005 (see [406] and [407]). Beneath the network IP layer are the L2 and L1 layers, which are not specified, in
the present document.
ETSI
3GPP TS 32.295 version 16.0.0 Release 16 15 ETSI TS 132 295 V16.0.0 (2020-08)
5.2 GTP' transfer scenarios
5.2.1 Basic principles
Each function (i.e. CDF and CGF) that supports the GTP' shall be capable of handling or responding with a
"Service/Version not supported" message if that function is configured to be addressed by another peer function.
5.2.2 GTP' messaging cases
5.2.2.0 General
The following example cases represent the three different key "Data Record Transfer Request/Response" messaging
related CDR handling schemes. Cases (2) and (3) represent situations involving the redundancy mechanism.
(1) The normal CDR packet transfer:
The CDF sends successfully a CDR packet to the CGF, and since the CDF gets a response (Request Accepted) for
the Data Record Transfer Request, there is no need to use the CGF redundancy mechanism and redirect the CDR
packet traffic flow to another CGF.

(2) The CDF-CGF connection breaks before a successful CDR reception:
In this case the CDR packet sent by the CDF is lost before it is received by the CGF. (The loss might be caused by a
link failure or e.g. a major CGF failure.)

(3) The CDF-CGF connection breaks after a successful CDR reception:
In this case the CDR sent by the CDF is received correctly by the CGF and moved to its non-volatile memory
(or even to the next NE in the communication chain). Anyhow, the CDF-CGF communication stops working, in this
example case, before the CDF gets the positive response (Data Record Transfer Response: Request Accepted)
which would acknowledge that the CDR packet was successfully received by CGF.

(4) CGF redundancy mechanism
An overview on the mechanism, involved in cases (2) and (3), preventing duplicated CDR packets to enter a BD.

The next four clauses describe in more detail each of these key "Data Record Transfer Request / Response" messaging
schemes.
ETSI
3GPP TS 32.295 version 16.0.0 Release 16 16 ETSI TS 132 295 V16.0.0 (2020-08)
5.2.2.1 The normal CDR packet transfer
Figure 5.2.2.1.1 shows the default mode of CDR transfer from the CDR generating functions (CDFs) to the CDR
collecting functions (CGFs).
CGF’s Non-volatile
CDF volatile memory CGF memory
1. Data Record Transfer
Request: Send Data
Record Packet
2. CDRs are stored
in a secure way
3. Data Record Transfer
Response: Request
Accepted
4. < Succesfully
sent CDRs are deleted
from the CDF
buffers >
. . . . . .
Figure 5.2.2.1.1: Normal CDR transfer process between a CDF and CGF
1) The CDR generating entity sends CDR(s) in a packet to CGF (that is the current primary Charging Gateway
Functionality for the specific CDF, "CGF1"). The sending is performed by using the Data Record Transfer
Request message, with the Packet Transfer Command IE having the value "Send Data Record Packet".
2) The CGF opens the received message and stores the packet contents in a safe way (to e.g. a redundant RAM
memory unit or a mirrored non-volatile memory or even to another node).
3) The CDR receiving entity (CGF) sends confirmation of the successful packet reception to the CDF.
The confirmation is performed by using the Data Record Transfer Response message, with the Cause value
being "Request Accepted".
4) After the positive response "Request Accepted" is received by the CDF, it may delete the successfully sent
CDRs from its send buffer.
The general principle of GTP' to retransmit the request if the response has not been received within a configurable time-
out limit, is also followed here in point 1). The maximum amount of retries is a configurable value.
ETSI
3GPP TS 32.295 version 16.0.0 Release 16 17 ETSI TS 132 295 V16.0.0 (2020-08)
5.2.2.2 The CDF-CGF connection breaks before a successful CDR reception
Figure 5.2.2.2.1 shows the exceptional case when the CDR transfer from a CDR generating entity (CDF) to the primary
CDR packet collecting entity (CGF1) fails in a way that the CGF1 is not able to store the CDR packet sent by the CDF.
(The reason for the failure in packet transfer may be e.g. a link failure between the CDF and CGF1, or a capacity
exhausting error in the storage device of CGF1, or a general CGF1 system failure or CGF1 maintenance break.)

CDR post-
CDF CGF1 CGF2 processing
system
1. Data Record Transfer
Request: Send Data
Record Packet
2. < CDRs not stored to non-volatile memory
nor sent to postprocessing >
3. < No positive response to CDF even to resent requests >
4. Data Record Transfer Request: Send possibly
duplicated Data Record Packet
5. < CGF2 stores the CDR packet contents to its buffer for pot. dupl. packets >
6. Data Record Transfer Response: Request Accepted
7. < CDRs are
deleted
. . . . . .
. . .
from CDF
buffers >
8. Node Alive Request
9. Node Alive Response: Request Accepted
10. Data Record Transfer Request: Send possibly
duplicated Data Record Packet (empty)
11. Data Record Transfer Response: Request Accepted
12. Data Record Transfer Request: Release Data Record Packet
13. CDRs
14. Data Record Transfer Response: Request Accepted

Figure 5.2.2.2.1: Duplicate prevention case: CDR sending via CGF1 had not succeeded
1) The CDR generating entity (CDF) sends CDR(s) in a packet to CGF (that is, the current primary CGF for the
specific CDF, "CGF1"). The sending is performed by using the Data Record Transfer Request message, with the
Packet Transfer Command IE having the value "Send Data Record Packet".
2) Due to a failure in the CDF-CGF1 communication link of CGF1, the CGF1 is not able to store the packet sent by
the CDF in a safe way (to e.g. a redundant RAM memory unit or a mirrored non-volatile memory or to another
node).
3) Therefore the CDF is not able to get a response (or it could alternatively get a negative response like "No
resources available" as the Cause value in the Data Record Transfer Response message).
ETSI
3GPP TS 32.295 version 16.0.0 Release 16 18 ETSI TS 132 295 V16.0.0 (2020-08)
4) The CDF may now first test the CDF-CGF2 link by an Echo Request message that the CGF2 would respond by
the Echo Response.) Then, the CDF sends the same CDR packet that could not be sent to CGF1 to the next CGF
in its CGF preference list (here CGF2) using the Data Record Transfer Request message, with the Packet
Transfer Command IE having the value "Send possible duplicated Data Record Packet".
5) As the connection to the CGF2 is working, the CGF2 is able to process the CDR packet. Since the packet was
marked by the sending CDF to be potentially duplicated, it is stored into the CGF2, but not yet sent forward
towards the BD.
6) The CGF2 sends confirmation of the successful packet reception to the CDF. The confirmation is performed by
using the Data Record Transfer Response message, with the Cause value being "Request Accepted"
7) The CDF can now delete the now successfully sent (potentially duplicated) CDRs from its CDR buffer (but it
keeps the sequence number(s) of the sent potentially duplicated packet(s) in a buffer dedicated for that.
8) When CGF1 is recovering after a system reboot, it sends a Node Alive Request message to the configured peer
CDF(s), and so the CDF notices that it can again successfully communicate with the CGF1. (The CDF may also
detect this by using the Echo Request messages, which would be answered by CGF1 by the Echo Response
message.)
9) CDF acknowledges the CGF1 by Node Alive Response message.
10) For the earlier unacknowledged Data Record Transfer Request message(s), the CDF sends CGF1 empty test
packet(s) (with no CDR payload in the Data Record Packet IE but just the other parts of the message frame).
11) CGF1 responds with Data Record Transfer Response message, with the Cause value being "Request Accepted",
because in this example case CGF1 had lost the communication capability towards CDF before storing the
previously received (and by CGF1 unacknowledged) CDR packet.
12) Now CDF knows that the CGF1 had not originally been able to process and forward the original version of the
CDR packet from the CDF, and it indicates CGF2 that CGF2 can send the CDR packet(s) related to the
previously unacknowledged GTP' Sequence Number(s) to post-processing. Those packets' Sequence Numbers
are indicated in the Sequence Numbers of the Released Packets IE.
13) CGF2 shall now be able to send the released records towards the post-processing system.
14) CGF2 responds with Data Record Transfer Response message, with the Cause value being 'Request Accepted'.
After all the potentially duplicated packets are cleared from CGF(s), the CDF can continue in normal way the transfer
of CDRs.
ETSI
3GPP TS 32.295 version 16.0.0 Release 16 19 ETSI TS 132 295 V16.0.0 (2020-08)
5.2.2.3 The CDF-CGF connection breaks after a successful CDR reception

CDR post-
CDF CGF1 CGF2 processing
system
1. Data Record Transfer
Request: Send Data
Record Packet
< 2. CDR packet contents is stored to non-volatile
CGF1 memory or sent for postprocessing >
3. < No positive response to CDF, even to resent requests >
4. Data Record Transfer Request: Send possibly duplicated Data Record Packet
5. < CGF2 stores the CDR packet contents to its buffer for pot. dupl. packets >
6. Data Record Transfer Response: Request Accepted
7. < CDRs are
deleted from
. . . . . . . . .
CDF buffers >
8. Node Alive Request
9. Node Alive Response
10. Data Record Transfer Request: Send possibly
duplicated Data Record Packet (empty)
11. Data Record Transfer Response: Request related
to possibly duplicated packets already fulfilled
12. Data Record Transfer Request: Cancel Data Record Packet
13.
14. Data Record Transfer Response: Request Accepted

Figure 5.2.2.3.1: Duplicate prevention case: CDR sending via CGF1 had succeeded
1) The CDR generating entity (CDF) sends CDR(s) in a packet to CGF (that is the current primary Charging
Gateway Functionality for the specific CDF, "CGF1"). The sending is performed by using the Data Record
Transfer Request message, with the Packet Transfer Command IE having the value "Send Data Record Packet".
2) The CGF1 is able to store the packet sent by the CDF in a safe way (to e.g. a redundant RAM memory unit or a
mirrored non-volatile memory or to another networ
...