7 Charging Protocols

32.0153G call and event data for the Packet Switched (PS) domain3GPPCharging managementRelease 1999Telecommunications managementTS

The GTP’ charging protocol is optional. GPRS nodes generate CDRs. These CDRs are to be collected by the CGF. The protocol GTP’ has been designed to provide this CDR collection.

The CGF-BS interface is also described in this subclause.

7.1 GPRS CDR Collection by GTP’ Protocol

The GTP’ protocol has been designed to deliver GPRS CDR’s to the CGF(s) from those Network Elements (NEs) or functional entities generating charging records. The GTP’ protocol is required when the CGF resides in alternate nodes to those CDR generating nodes (e.g. the SGSN and GGSN). The GTP’ protocol designed for GPRS charging data collection has been derived from the GTP protocol (defined in 3GPP TS 29.060 [22]) which is used for packet data tunnelling in the GPRS backbone network.

GTP’ is based on GTP with enhancements and additional message types. GTP’ operates on the Ga interface.
GTP’ however does not imply the use of the GPRS backbone network, and may be implemented on alternate bearers.

The GTP’ contains the following functions:

– CDR transfer mechanism between GPRS nodes generating CDRs and the Charging Gateway Functionality.

– Redirection of CDR transfer to another CGF.

– Ability to detect communication failures between the CDR handling GPRS Network Elements by echo messaging.

– Ability of a CDR handling node to advertise the peer CDR handling GPRS Network Elements about its CDR transfer capability (e.g. after a period of service downtime).

– Ability to prevent 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 CGF or Billing System – BS (instead of handling the possible duplicates solely by GTP’ messaging).

– The aim of the duplication prevention support of GTP’ is to reduce the number of duplicated CDRs sent towards the BS and to support the BS in keeping the efforts for duplicate CDR checking as small as possible.

7.1.1 SGSN – CGF communication

SGSN – CGF: GTP’ over UDP/TCP and IP

Figure 9: Protocol layers between the SGSN and the CGF

7.1.2 GGSN – CGF communication

GGSN – CGF: GTP’ over UDP/TCP and IP:

Figure 10: Protocol layers between the GGSN and the CGF

7.1.3 CGF – CGF communication

CGF – CGF: GTP’ over UDP/TCP and IP:

Figure 11: Protocol layers between CGFs

7.1.4 Port usage

GPRS charging may be facilitated by sending the CDRs from the GSNs to the CGF over the Ga interface. The Path Protocol may be UDP (compliant with STD 0006[36]) or TCP (compliant with STD 0007[39]).

7.1.4.1 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 O&M.

– The UDP Source Port is a locally allocated port number at the sending GSN.

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.

7.1.4.2 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 O&M. 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 GSN.

7.1.4.3 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 [37] and [38]). Beneath the network IP layer are the L2 and L1 layers, which are not specified in the present document.

7.1.5 Charging related requirements for GPRS nodes

Each GPRS node (SGSN, GGSN, CGF, and in future the PTM-SC) supporting GTP’ shall be capable of handling or responding with a "Service/Version not supported" message if that node is configured to be addressed by another GPRS node.

When a new PDP context is activated or after an inter SGSN handover the GGSN will inform the related SGSN which CGF it should send its CDRs to. All other non-PDP context related CDRs are sent to the current default CGF for that CDR generating node. Each CDR generating node will have an O&M configurable CGF address list to which it can send its CDRs. The list will be organized in CGF address priority order. If the Primary CGF is e.g. out of service, then the CDR generating node shall send the CDRs to the Secondary CGF and so on.

Each GPRS CDR generating node will only send the records to the CGF(s) of the same GPRS PLMN, not to CGF(s) located in other PLMNs.

Each CGF in the GPRS PLMN shall know of all other CGFs network addresses. This is achieved by O&M configuration facilities that will enable each CGF to have a configurable list of peer CGF addresses.

7.2 The GTP’ charging protocol

This subclause describes the features of the GTP’ protocol. For the message types mentioned in subclause 7.3.2 ("Reused GTP message types") of the present document, see also the related subchapters in 3GPP TS 29.060 [22].
GTP’ is used for GPRS and 3G charging data collection.

7.2.1 Usage of GTP Header in charging

The start of the GTP header defined in 3GPP TS 29.060 [22] is reused. In GTP’ messaging only the signalling plane of GTP is partly reused.

Bit 5 of octet 1 of the GTP header is the Protocol Type flag and is ‘0’ if the message is GTP’.

The Version bits indicate the GTP’ protocol version when the Protocol Type flag is ‘0’.

Bit 1 of octet 1 is not used in GTP’ (except in v0), and it is ‘0’ in the GTP’ header.

The Length indicates the length of payload (number of octets after the GTP’ header).

The Sequence Number of the packet is part of the GTP’ header.

Bits

Octets

8

7

6

5

4

3

2

1

1

Version

PT

Spare ‘ 1 1 1 ‘

‘ 0 ‘

2

Message Type

3 – 4

Length

5 – 6

Sequence Number

Figure 12: GTP’ header

7.2.2 Information elements

The messages may contain several information elements. The TLV (Type, Length, Value) or TV (Type, Value) encoding formats shall be used for the GTP’ information elements. The GTP’ messages shall have the information elements sorted with the Type fields in ascending order. The Length field shall contain the information element length excluding the Type and Length fields.

Within the Type field the most significant bit will be set to 0 when the TV format is used and set to 1 when the TLV format is used.

Figure 12a: Type field for TV and TLV format

7.3 GTP’ Message Types

7.3.1 List of all GTP’ message types

GTP’ defines a set of messages between two associated nodes. The GTP’ messages defined are shown in table 11.
The messages introduced by GTP’ are printed in this table in boldface. The other messages are inherited from the GTP protocol.

Of the GTP’ introduced signalling message types, Node Alive Request, Node Alive Response, Redirection Request and Redirection Response belong to the "Path Management messages". The Data Record Transfer Request and Data Record Transfer Response form the message type group "Record Transmission messages".

The reserved fields in the signalling messages shall be filled with ones, and are intended for future use.

GTP’ reuses the GTP Cause values. The message type numbers required for the newly introduced GTP’ messages have been derived from the unallocated message type number space specified in the GTP message table defined in 3GPP TS 29.060 [22].

The number ranges allocated for GTP’ are as follows:

For Information Elements: 117-127 (TV type fields) and 239-254 (for TLV type fields).

TLV Information Element types introduced in the present document:

254 Address of Recommended Node

253 Requests Responded

252 Data Record Packet

251 Charging Gateway Address (this IE is also used in 3GPP TS 29.060 [22])

250 Sequence Numbers of Cancelled Packets

249 Sequence Numbers of Released Packets

TV Information Element types introduced in the present document:

127 Charging ID

126 Packet Transfer Command

For Cause Codes: Cause values used in requests: 49 to 63, Cause values used in responses indicating acceptance: 177 to 191, Cause values used in responses indicating rejection: 241 to 255.

Charging related Cause values introduced for the present document:

In requests:

63 This node is about to go down

62 Another node is about to go down

61 The receive buffers are becoming full

60 The transmit buffers are becoming full

59 System failure

In responses indicating acceptance:

177 CDR decoding error

In responses indicating rejection:

255 Request not fulfilled

254 Sequence numbers of released/cancelled packets IE incorrect

253 Request already fulfilled

252 Request related to possibly duplicated packets already fulfilled

The charging related message types are listed in table 11. Those GTP’ messages that are listed in boldface in table 11, are defined in the present document, the other GTP’ messages listed in table 11 are inherited from the GTP protocol. For a description about the GTP messages reused in GTP’, see the subclause 7.3.2 ("Reused GTP message types") of the present document, and for further details about those messages see 3GPP TS 29.060 [22], the GTP specification.

Table 11: GTP’ messages

Message Type value

(Decimal)

GTP’ message

(see NOTE)

1

Echo Request

2

Echo Response

3

Version Not Supported

4

Node Alive Request

5

Node Alive Response

6

Redirection Request

7

Redirection Response

240

Data Record Transfer Request

241

Data Record Transfer Response

others

reserved for future use

7.3.2 Reused GTP message types

The existing Echo Request and Echo Response messages defined in 3GPP TS 29.060 [22] are also used in GPRS charging. They may be used by the CDR generating nodes SGSN or GGSN, or by the CGF for checking if another GSN or CGF is alive. If the present document and 3GPP TS 29.060 [22] differ in their description then the 3GPP TS 29.060 [22] is to be taken as the latest specification status of the related Information Elements. If the path protocol is TCP, Echo Request and Echo Response messages are not required.

The Version Not Supported message in the GTP’ resembles much the corresponding GTP message. It indicates the latest GTP’ version that the GTP’ entity can support. If a receiving node receives a GTP’ message of an unsupported version, that node shall return a GTP’ Version Not Supported message indicating in the Version field of the GTP’ header the latest GTP’ version that that node supports. The received payload data of the GTP’ packet shall then be discarded.

The Version bits in the GTP’ header have currently the following possible values:

GTP’ version 0 (binary ‘000’) is the GSM 12.15 v7.0.0 (October 1998) level, with the following Message Type values: 3 = Version Not Supported, 4 = Node Alive Request, 5 = Node Alive Response, 6 = Redirection Request, 7 = Redirection Response. In clause 7.3.4.6 the Requests Responded information element has Length field in place of the Number of Requests Responded field, to make that TLV IE to be handled like normal TLV IEs. If the GTP’ v0 is used in parallel to GTP’ v2 or a newer version, then a 6 octet header length (with no trailing dummy octets) is used also with v0 (like in GTP’ v2). The mark of the usage of GTP’ v0 with 6 octet header (instead of the original 20 octet long header) is then the version bits being 0 and the bit 1 of octet 1being ‘1’ (instead of ‘0’).

GTP’ version 1 (binary ‘001’) is the same as version 0, but with the duplicate CDR prevention mechanism, introduced in GSM 12.15 version 7.2.1 (1999-07) of the GPRS charging specification.

GTP’ version 2 (binary ‘010’) is the same as version 1, but the header is just 6 octets long (no unused trailing octets). IPv6 address type is also supported (for Address of Recommended Node information element of the Redirection Request).

7.3.3 GTP message type modifications implied by GTP’

The GPRS charging related features in GTP are in the Create PDP Context Response: the Charging ID Information Element (IE) and the Charging Gateway Address IE, in the Update PDP Context Response the Charging ID Information Element (IE) and the Charging Gateway Address IE, in the Create AA PDP Context Response: the Charging ID IE and the Charging Gateway Address IE. Refer to 3GPP TS 29.060 [22] for details.

The general principle is that the CDRs are always sent to a CGF residing in the same network as the CDR generating node. In the case of roaming it is conceivable that some CDRs relating to the same PDP context will be sent to different networks’ CGFs. The cost balancing of the roaming traffic is to be agreed between the GPRS Operators.

7.3.4 GTP’ message types

7.3.4.1 Node Alive Request

The Node Alive Request message may be used to inform that a node in the network has started its service (e.g. after a service break due to software or hardware maintenance or data service interruption after an error condition). A node may send a different Node Address than its own in the Information Element, e.g. informing the "next node in the chain" that the "previous node in the chain" (which is located on the other side of the sender of this message) is now ready for service. This message type is optional if the Path Protocol is TCP.

The Node Alive Request message allows a quicker reconnect capability than the Echo Request message based polling can provide, and its usage will have a reduced load effect on the network, particularly when the number of network nodes using GTP’ is high. It may also be used to inform when a new network node has become available for service. If the Echo Request message is also used then the usage of the Node Alive Request message allows the interval of Echo Requests to be longer than would be otherwise required, thus reducing network loading with many Echo Requests.

Table 12: Information Elements in a Node Alive Request

Information Element

Presence requirement

Node Address

Mandatory

Private Extension

Optional

The Node Address format and type number are the same as for the Charging Gateway Address format and type described in 3GPP TS 29.060 [22]).

The optional Private Extension IE contains vendor- or operator-specific information.

7.3.4.2 Node Alive Response

The Node Alive Response message shall be sent as a response to a received Node Alive Request.

Table 13: Information Elements in a Node Alive Response

Information Element

Presence requirement

Private Extension

Optional

The optional Private Extension IE contains vendor- or operator-specific information.

7.3.4.3 Redirection Request

There are two kinds of usage for the Redirection Request message. One is to advise that received CDR traffic is to be redirected to another CGF due to that CGF node is about to stop service (due to an outage for maintenance or an error condition). The second purpose is to inform a CDR generating node (e.g. SGSN) that is currently sending data to this node (e.g. CGF), that the next node in the chain (e.g. a mediator device or Billing Computer) has lost connection to this node (e.g. CGF).

An Address of Recommended Node may be given if for example a CGF maintenance outage is handled by first introducing another CGF ready to take incoming CDRs. In this way the network performance can be maintained. The Address of Recommended Node shall only describe an intra-PLMN node containing a CGF, and not to a node in any other PLMN.

Table 14: Information Elements in a Redirection Request

Information Element

Presence requirement

Cause

Mandatory

Address of Recommended Node

Optional

Private Extension

Optional

Possible Cause values are:

– "This node is about to go down";

– "Another node is about to go down";

– "System failure";

– "Receive buffers becoming full";

  • "Send buffers becoming full".

The Address of Recommended Node information element defines the IPv4 or IPv6 format address that the node is identified by in the GPRS network.

Figure 13: Address of Recommended Node information elements

The optional Private Extension contains vendor- or operator- specific information.

7.3.4.4 Redirection Response

The message shall be sent as a response of a received Redirection Request.

Table 15: Information Elements in a Redirection Response

Information Element

Presence requirement

Cause

Mandatory

Private Extension

Optional

Possible Cause values are:

– "Request Accepted";

– "No resources available";

– "Service not supported";

– "System failure";

– "Mandatory IE incorrect";

– "Mandatory IE missing";

– "Optional IE incorrect";

– "Invalid message format";

– "Version not supported".

The optional Private Extension contains vendor- or operator-specific information.

7.3.4.5 Data Record Transfer Request

This message is used in GPRS charging to transmit the CDR information. The CDR information is placed in the Data Record information element.

7.3.4.5.1 General logic

This subclause is intended to be read together with subclause 7.3.4.7 "Examples of GTP’ messaging cases". The normal communication would be GSN sending Data Record Packets to a CGF, which answers with "Request Accepted" responses. Under normal condition the CDR transmission uses a Request-Response messaging sequence in the GSN to CGF GTP’ protocol communication.

Sometimes a non-PDP context related CDR (e.g. M-CDRs) is transmitted, and thus the GGSN does not pass the CGF address information to the SGSN. The SGSN will in this case direct the CDRs to the current default CGF for the SGSN. This is the configured Primary CGF address, or if that CGF is out of service, then the secondary CGF address etc.

Summary of the CGF redundancy mechanism that prevents duplicated CDR packets to enter the BS:

The general logic of the duplicate CDR packet prevention in CGF redundancy cases is shown in Figure 14, where the message numbers are numbered in the order of time sequence. Alternative messages are indicated by an index character (‘a’ or ‘b’) that follows the arrow sequence number.

The main mechanism of the messaging in CGF redundancy cases (when a GSN-CGF link is down or a CGF is not working) is based on (1) first trying to send a CDR packet to CGF1. Then if no successful response is received (2) because the request does not reach CGF1 even when retried (or the responses from CGF1 to GSN are lost after CGF1 either stored it securely or sent it towards post-processing (2b)), the unacknowledged CDR packets are redirected to CGF2. The GSN may first test the GSN-CGF2 link by an Echo Request message that the CGF2 would respond by Echo Response. The CDR packets not successfully received by the primary CGF (=CGF1) are sent to another CGF2 (3), marked as potential duplicates, and CGF2 responds the request(s) (4). Those CDRs will wait there for further commands from GSN. When the GSN detects (5) and (6) that CGF1 is again able to communicate with it by receiving Node Alive Request (or getting a Echo Response from CGF2 to a Echo Request sent by the GSN) it answers by Node Alive Respond. Then the GSN tests with an empty packet (7), retrying continuously if no response, using e.g. increasing timeouts (using the old unacknowledged packet’s Sequence Number, if the CGF1 would consider the packet to be a new one (8a) or an already received one (8b) ). According to the response of the CGF1, the GSN gives the CGF2 a command to either release (9a) or cancel (9b) the corresponding CDR packet from CGF2. CGF2 then confirms the decision (10), and is able to send the CDRs towards the BS (11a).

Error handling: As a default, retransmissions after configurable timeouts are used. If after CGF1 communication failure the CDR packet sending from GSN to CGF2 does not succeed, the GSN tries to use CGF3 as the intermediate CDR packet storage entity, etc. If the acknowledgement (10) is not got by the GSN for its message (9a) or (9b), the GSN will retransmit the message (9a) or (9b) continuously and persistently, using e.g. increasing time intervals. An alarm should be sent to the O&M system if a communication link goes down. It shall be possible to release/cancel CDR packets from CGFs and unacknowledged sequence numbers from GSNs by O&M operations if permanent GSN-CGF link failures would occur. The buffers containing Sequence Numbers of potentially duplicated packets and the buffers containing the numbers of unacknowledged CDR packets shall be kept up to date (with CDR packet transfers) using atomary transaction mechanisms. If the GSN-CGF1 communication link is down, any new CDRs generated by the GSN are sent to a properly working CGF2, instead of the CGF1.

Figure 14: General CGF redundancy messaging scheme

A more detailed description of the CGF redundancy mechanism:

Due to a network failure or node failure, a CGF might not send a response within the configured timeout period to a request it got from a GSN. As a first attempt, retries of requests are to be used as defined in 3GPP TS 29.060 [22], if the response is not received in the configured time.

If a CDR generating node loses its connection to the CGF unexpectedly, it may send the CDRs to the next CGF in the priority list. If the CGF changes, the GSN can continue sending CDRs to different CGF nodes, depending on which CGF has been configured as the receiver of CDRs for a particular PDP context.

Sequence number buffers: The GSN might lose its connection to its primary CGF due to a link failure or CGF going down. In this kind of redundancy condition the GSN attempts to redirect the CDR traffic to a secondary CGF (after possible retries have failed). The GSN maintains an internal buffer for Sequence Numbers of requests not yet successfully responded by the primary CGF, for the case that it may become capable of communicating to the primary CGF at a later date. The GSN will send the not responded Data Record Packets (DRPs) to the secondary CGF, and the GSN maintains also a buffer for the Sequence Numbers related to those DRPs that have been temporarily stored to this secondary CGF. (If the communication towards the secondary CGF would not work, the transfer of possibly duplicated DRPs and Sequence Number bookkeeping would be done for a tertiary CGF etc.) Also the CGFs maintain Sequence Number buffers for each of their GSN links. The Sequence Numbers may in future be needed in relation to the possibly duplicated CDRs that the CGFs have got from the GSN(s). The Sequence Numbers are stored to wait for a final decision to release them towards the BS (if the primary CGF had not received successfully the packets originally sent by a GSN) or to cancel them (if the primary CGF had received and processed successfully the originally by GSN sent packets).

The GSN is able to cancel (or release for transfer towards the BS) CDR packets sent to a secondary CGF if the primary CGF becomes available for service. To make the right decision the GSN first sends an empty test packet with the ‘Send possibly duplicated Data Record Packet’ Packet Transfer Command to the primary CGF, using a previously not responded Sequence Number.

In case that the empty test packet to the primary CGF which was temporarily down (or to which the link was down) is responded with the Cause value "Request Accepted", the GSN will release the corresponding CDRs waiting for final decision in the secondary CGF, towards the Billing System (BS) with the Packet Transfer Command ‘Release Data Record Packet’.

If the primary CGF responses this test message with the Cause value "Request related to possibly duplicated packets already fulfilled", the GSN will cancel the corresponding CDRs waiting for final decision in the secondary CGF, using the Packet Transfer Command ‘Cancel Data Record Packet’.

To enable that a GSN failure (destroying its Sequence Number buffers per each CGF link for non-responded requests or possibly duplicated packets) would not cause CDR packets to stay forever in the temporary decision waiting buffers of CGFs, there should also be O&M means of emptying those CGF buffers.

There shall be a also configurable parameter in the CGF for making the final decision as to whether or not it is able to send the CDRs to the Billing System (BS) for the case where the backup buffering mechanism in the GSN could not be used until the end of the messaging sequence related to a certain CDR packet has completed. This way the operator can:

  1. Select that the GSNs and CGFs take care of duplicate prevention and the BS is not required to do duplicate checking due to possible duplicates caused by GPRS node redundancy.
  2. Select that BS performs the duplicate prevention. To do this in the most effective way, the CGF may include an additional flag linked to possibly duplicated CDRs sent to Billing System, that they have not been released by a GSN for BS use (or use special kind of file name if a file protocol is used between CGF and BS). This means that the BS has somewhat more processing work to do, but the BS would anyway get a duplicate free end result. CGF is in this case always authorised to forward CDRs towards the BS, also when they contain possibly duplicated data. For this case the CGFs may also have a configurable flag that Data Record Packet Cancel/Release operations are not needed.
7.3.4.5.2 Information Elements in Data Record Transfer Request

Table 16: Information Elements in a Data Record Transfer Request

Information Element

Presence requirement

Packet Transfer Command

Mandatory

Data Record Packet

Conditional

Sequence Numbers of Released Packets

Conditional

Sequence Numbers of Cancelled Packets

Conditional

Private Extension

Optional

7.3.4.5.3 Packet Transfer Command IE

The value of the Packet Transfer Command in its Information Element tells the nature of the message:

1 = ‘Send Data Record Packet’;

2 = ‘Send possibly duplicated Data Record Packet’;

3 = ‘Cancel Data Record Packet’;

4 = ‘Release Data Record Packet’.

The following describes the usage of each Packet Transfer Command.

1) Send Data Record Packet. This is used for the normal CDR sending, and it is the usual Packet Transfer Command, other commands being used only in error recovery cases. Of the conditional IEs, the "Data Record Packet" is present in the message.

2) Send possibly duplicated Data Record Packet. When the CDR packet is directed to a secondary CGF (by a CDR generating node) because the currently used CGF not working or the CDR transfer is not working properly, then this Packet Transfer Command is used instead of the normal ‘Send Data Record Packet’. Of the conditional IEs, the Data Record Packet" is present in the message, when sending the message to a CGF acting as temporary storage, when the original primary CGF could not be contacted. This Packet Transfer Command is used also when sending "empty" test packets with older (but not yet acknowledged) sequence numbers after a peer node or link recovery, to check if the CGF had received some Data Record Packets (whose acknowledgement did not come to the Data Record Packet sending node) before the link to the recipient node became inoperable.

3) Cancel Data Record Packet. Of the conditional IEs, the "Sequence Numbers of Cancelled Packets" is present in the message.

4) Release Data Record Packet. Of the conditional IEs, the "Sequence Numbers of Released Packets" is present in the message.

Figure 15: Packet Transfer Command information element

After the CGF has received the Packet Transfer Command ‘Release Data Record Packet’ with the Sequence Number(s) for earlier sent ‘Send possibly duplicated Data Record Packet’ command(s), it can consider itself authorised to send the Data Record Packets previously marked as possibly duplicated towards the Billing System (BS) as normal (not duplicated) CDRs.

7.3.4.5.4 Data Record Packet IE

The Data Record Packet element, which is present conditionally if the Packet Transfer Command is ‘Send Data Record Packet’ or ‘Send possibly duplicated Data Record Packet’, may contain one or more data records. This IE is illustrated in Figure 16. If an "empty packet" is to be sent, then the Data Record Packet IE contains only the Type (with value 252 in decimal) and the Length (with value 0) fields.

As shown in Figure 16, there are two fields identifying the CDR format: Data Record Format and Data Record Format Version. The format of the records is ASN.1 or some other format, as identified by the Data Record Format. The Data Record Format Version identifies the TS release and version numbers that were used for the CDR encoding. The formats of these two fields are described in detail in section 7.4 and 7.5, respectively.

Figure 16: Data Record Packet information element

7.3.4.5.5 Sequence Numbers of Released Packets IE

The Sequence Numbers of Released Packets is present if the Packet Transfer Command is ‘Cancel Data Record Packet’. The format of the Information Element is described below:

Figure 17: Sequence Numbers of Released Packets information element

7.3.4.5.6 Sequence Numbers of Cancelled Packets IE

The Sequence Numbers of Cancelled Packets information element contains the IE Type, Length and the Sequence Number(s) (each 2 octets) of the cancelled Data Record Transfer Request(s). It is present if the Packet Transfer Command is ‘Cancel Data Record Packet’.

Figure 18: Sequence Numbers of Cancelled Packets information element

7.3.4.5.7 Private Extension IE

The optional Private Extension contains vendor or operator specific information.

7.3.4.6 Data Record Transfer Response

The message shall be sent as a response of a received Data Record Transfer Request. Also, several Data Record Transfer Requests can be responded by a single Data Record Transfer Response.

Table 17: Information Elements in a Data Record Transfer Response

Information Element

Presence requirement

Cause

Mandatory

Requests Responded

Mandatory

Private Extension

Optional

The Cause value is the same (whatever the value) for all those messages responded by that particular Response.

Possible Cause values are:

– "Request Accepted";

– "No resources available";

– "Service not supported";

– "System failure";

– "Mandatory IE incorrect";

– "Mandatory IE missing";

– "Optional IE incorrect";

– "Invalid message format";

– "Version not supported";

– "Request not fulfilled";

– "CDR decoding error";

– "Request already fulfilled";

  • "Request related to possibly duplicated packet already fulfilled".

The cause value "CDR decoding error" is optional, primarily intended to inform the CDR generating node that the receiving node can not decode the CDR. Thus, special features in the receiving node that are based on information within the CDR would not be operable. This message could alert the operator of a remote generating node of incompatible CDR encoding. It is Optional and no action or response is required.

The Requests Responded information element contains the IE Type, Length and the Sequence Numbers (each 2 octets) of the Data Record Transfer Requests.

Figure 19: Requests Responded information element

The optional Private Extension contains vendor or operator specific information.

Depending on the Cause value severity and general occurrence frequency, the node that sent the corresponding Data Record Transfer Request, may start to direct its CDRs to another CGF.

7.3.4.7 Examples of GTP’ messaging cases

The following example cases represent the three different key Data Record Transfer Request/Response messaging related CDR packet handling schemes:

Case 1): The normal CDR packet transfer:

GSN sends successfully a CDR packet to the CGF, and since the GSN gets a response (Request Accepted) for the Data Record Transfer Request, there is no need to revert to the CGF redundancy mechanism and redirect the CDR packet traffic flow to an other CGF.

Case 2): The GSN-CGF1 connection breaks before a successful CDR reception:

In this example case the CDR packet sent by the GSN is lost before it is received by the CGF1. (The loss might be caused by a link failure or e.g. a major CGF1 failure.)

Case 3): The GSN-CGF1 connection breaks after a successful CDR reception:

In this example case the CDR packet sent by the GSN is received correctly by the CGF1 and moved to its non-volatile memory (or even to the next NE in the communication chain). Anyhow, the GSN-CGF1 communication stops in this example case working before the GSN gets the positive response (Data Record Transfer Response: Request Accepted) that would acknowledge that the CDR packet was successfully received by CGF1.

The next three subclauses describe in more detail each of the key Data Record Transfer Request/Response messaging schemes.

7.3.4.7.1 Case 1: The normal CDR packet transfer

Figure 20 represents the default mode of CDR transfer from the CDR generating entities (GSNs) to the CDR packet collecting entities (CGFs).

Figure 20: A normal CDR transfer process between a GSN and CGF

1) The CDR generating entity (here the GSN symbolises either SGSN or GGSN) sends CDR(s) in a packet to CGF (that is the current primary Charging Gateway Functionality for the specific CDR generating node, "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 CDR generating node (GSN). 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 GSN, 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.

7.3.4.7.2 Case 2: The GSN-CGF1 connection breaks before a successful CDR reception

Figure 21 describes the exceptional case when the CDR transfer from a CDR generating entity (GSN) 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 GSN. (The reason for the failure in packet transfer may be e.g. a link failure between the GSN and CGF1, or a capacity exhausting error in the storage device of CGF1, or a general CGF1 system failure or CGF1 maintenance break.)

Figure 21: Duplicate prevention case: CDR sending via CGF1 had not succeeded

1) The CDR generating entity (GSN) sends CDR(s) in a packet to CGF (that is the current primary Charging Gateway Functionality for the specific CDR generating node, "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 GSN-CGF1 communication link of CGF1, the CGF1 is not able to store the packet sent by the GSN 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 GSN 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).

4) (The GSN may now first test the GSN-CGF2 link by an Echo Request message that the CGF2 would respond by the Echo Response.) Then the GSN 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 GSN to be potentially duplicated, it is stored into the CGF2, but not yet sent forward towards the Billing System.

6) The CGF2 sends confirmation of the successful packet reception to the GSN. The confirmation is performed by using the Data Record Transfer Response message, with the Cause value being ‘Request Accepted’

7) The GSN 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 GSN(s), and so the GSN notices that it can again successfully communicate with the CGF1. (The GSN may also detect this by using the Echo Request messages, which would be answered by CGF1 by the Echo Response message.)

9) GSN acknowledges the CGF1 by Node Alive Response message.

10) For the earlier unacknowledged Data Record Transfer Request message(s), the GSN 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 GSN before storing the previously received (and by CGF1 unacknowledged) CDR packet.

12) Now GSN knows that the CGF1 had not originally been able to process and forward the original version of the CDR packet from the GSN, 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 packets towards post-processing.

14) CGF2 responds with Data Record Transfer Response message, with the Cause value being ‘Request Accepted’.

After all the potentially duplicated packets are cleared form CGF(s), the GSN can continue in normal way the transfer of CDRs.

7.3.4.7.3 Case 3: The GSN-CGF1 connection breaks after a successful CDR reception

Figure 22: Duplicate prevention case: CDR sending via CGF1 had succeeded

1) The CDR generating entity (GSN) sends CDR(s) in a packet to CGF (that is the current primary Charging Gateway Functionality for the specific CDR generating node, "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 GSN in a safe way (to e.g. a redundant RAM memory unit or a mirrored non-volatile memory or to another node).

3) Since the GSN-CGF1 communication connection is now broken, the GSN is not able to get the response "Request Accepted" as the Cause value in the Data Record Transfer Response message.

4) Then the GSN sends the same CDR packet that could not be sent to CGF1 to the next CGF in its CGF preference list (here CGF2) a Data Record Transfer Request message, with the Packet Transfer Command IE having the value ‘Send possible duplicated Data Record Packet’. (That sending may be preceded by the testing of the GSN-CGF2 link by an Echo Request message, that the CGF2 would respond by the Echo Response.)

5) As the connection to CGF2 is working, CGF2 is able to process the CDR packet. Since the packet was marked by the sending GSN to be potentially duplicated, it is stored in CGF2, but not yet sent forward towards the post processing or Billing System.

6) The CGF2 sends confirmation of the successful packet reception to the GSN. The confirmation is performed by using the Data Record Transfer Response message, with the Cause value being ‘Request Accepted’

7) The GSN 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 GSN(s), and so the GSN notices that it can again successfully communicate with the CGF1. (The GSN may also detect this by using the Echo Request messages, which would be answered by CGF1 by the Echo Response message.)

9) GSN acknowledges the CGF1 by Node Alive Response message.

10) For the earlier unacknowledged Data Record Transfer Request message(s), the GSN 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 related to possibly duplicated packets already fulfilled’, because in this example case CGF1 had lost the communication capability towards GSN after storing the previously received (and by CGF1 unacknowledged) CDR packet.

12) Now GSN knows that the CGF1 had originally been able to process and forward the original version of the CDR packet from the GSN, and it indicates CGF2 that CGF2 can cancel the CDR packet(s) related to the previously unacknowledged GTP’ GSN-CGF1 Sequence Number(s). Those packets’ Sequence Numbers are indicated in the Sequence Numbers of the Cancelled Packets IE.

13) CGF2 shall now delete the cancelled packet(s) from its buffer for potentially duplicated packets.

14) CGF2 responds with Data Record Transfer Response message, with the Cause value being ‘Request Accepted’.

After all the potentially duplicated packets are cleared form CGF(s), the GSN can continue in normal way the transfer of CDRs.

7.4 Data Record Format in GTP

The format of the CDRs sent between the Network Elements that generate the PS domain CDRs and the CGF are defined by the Data Record Format, which is the 5th octet of Data Record Packet information element, shown in Figure 16.

The following rules govern the Data Record Format:

  • This field consists of one octet (#5).
  • The value range is 1-255 in decimal. The value ‘0’ should not be used.
  • Only the values 1-10 and 51-255 can be used for standards purposes.
  • Values in the range of 11-50 are to be configured only by operators, and are not subject to standardization.
  • The value ‘1’ identifies ASN.1 format (in PS domain charging). If needed other values are specified in subclause 7.4.1.

7.4.1 Standard Data Record Format

For the PS Domain CDR transfer, defined by this TS, only an ASN.1 format is used. For this format the Data Record Format value is ‘1’. See clause 6 and the ASN.1 language descriptions for the definitions. Basic Encoding Rules (BER) provides the transfer syntax for abstract syntax defined in ASN.1.

7.4.2 Private Data Record Formats

The Data Record Format identifiers 11…50 (decimal) are reserved for private (implementation specific) format use.

7.5 Data Record Format Version for CDRs

The CDR release and versions numbers are defined by the ‘Data Record Format Version’, in octet 6 and 7 of the Data Record Packet IE, shown in Figure 13. The format of this field is depicted in Figure 23.

The first octet (#6 in Data Record Packet IE) is divided into two fields each with 4 bits. The first field (octet 6, bits 8-5 in Fig 23) identifies the application. The second field (bits 4-1 of octet 6) identifies the release. For charging purposes, the Application Identifier has a value of ‘1’ (decimal). Other possible applications of GTP’ may use different numbers. The Release Identifier indicates the TS release used to encode the CDR, i.e. its value corresponds to the first digit of the version number of the present document, as shown on the cover sheet.

Bits

Data Record Packet IE

Octet

Octets

7

6

8

7

6

4

3

2

1

5

Application Identifier

Release Identifier

Version Identifier

Bits

Figure 23: The Format of the Data Record Format Version Field

The second octet (#7) identifies the version of the TS used to encode the CDR. For versions up to, and including, "3.1.1", the decimal value of the Version Identifier is provided in Table 18. For versions higher than "3.1.1", the decimal value of the Version Identifier corresponds to the second digit of the version number of the present document (as shown on the cover sheet) plus ‘2’. E.g. for version 3.4.0, the value would be "6". In circumstances where the second digit is an alphabetical character, (e.g. 3.b.0), the corresponding ASCII value shall be taken, e.g. the Version Indicator for TS 32.015 v3.b.0 would be "66" (ASCII(b)).

Table 18: The decimal value of the Version Identifier used in R99 CDRs

Value

R99

1

TS 32.015 v3.0.0

2

TS 32.015 v3.1.0

3

TS 32.015 v3.1.1

7.6 CGF – BS Protocol Interface

7.6.1 The transfer protocols at CGF – BS interface

The present document gives several recommendations for the main protocol layers for the Charging Gateway Functionality – Billing System (BS) interface protocol stack. These recommendations are not strictly specified features, since there are a lot of variations among the existing Billing Systems. The recommendations are FTAM protocol on X.25 or TCP/IP, and FTP over TCP/IP.

7.6.2 The format of the CDRs at CGF – BS interface

The contents of the CDRs sent between the CGF and the Billing System (BS) are defined by the ASN.1 language clause 8, Charging Data Record Structure. Other CDR contents or formats are possible if the CGF provides processing functionality for the CDRs.