GTPP has been designed to deliver the CDR(s) from the CDF to the CGF(s). This protocol is required if the CGF resides outside the CDFs. It utilizes some aspects of GTPP, which is used for packet data tunneling in the backbone network.

GTPP operates on the Ga interface and does not imply the use of any specific backbone network.

GTPP performs the following functions:

In GTPP messaging only the signalling plane of GTPP is partly reused. The GTPP header is shown in the following figure.

Bit 5 of octet 1 of the GTPP header is the Protocol Type (PT) flag: it is '0' if the message is GTPP.

The Version bits indicate the GTPP protocol version when the Protocol Type flag is '0'.

Bit 1 of octet 1 is not used in GTPP (except in v0), and it is marked '0' in the GTPP header. It is in use in GTPP v0 and distinguishes the used header-length. In the case of GTPP v0, this bit being marked one (1) indicates the usage of the 6 octets header. If the bit is set to '0' (usually the case) the 20-octet header is used. For all other versions of GTPP, this bit is not used and is set to '0'. However, this does not suggest the use of the 20-octet header, rather a shorter 6-octet header.

The Length indicates the length of payload (number of octets after the GTPP header). The Sequence Number of the packet is part of the GTPP header.

The messages contain several Information Elements (IEs). The TLV (Type, Length, Value) or TV (Type, Value) encoding formats will be used for the GTPP IEs. The GTPP messages have the IEs sorted with the Type fields in ascending order. The Length field contains the IE 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.

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.

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 GTPP 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, thus reducing network load by reducing number of Echo Requests.

The Node Address format is the same as for the Charging Gateway Address format described in TS 29.060.

The format definition for the Node Address information element is the same as the format of the source and destination address of the IP packet that transports the GTPP messages. The optional Alternative Node Address IE can be used in the Node Alive Request if the message sender wants to advertise an IP address that is different from the node address format. This way both the IPv4 and IPv6 node address formats can be supported simultaneously in the messaging, regardless of whether IPv4 or IPv6 is used in the underlying transport.

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

The Node Alive Response message, shown in the following table, will be sent as a response to a received Node Alive Request.

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

There are two use cases for the Redirection Request message:

The Information Elements in a Redirection Request Message are listed in the following table. 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. This way, the network performance can be maintained. The Address of Recommended Node describes an intra-PLMN node containing a CGF, and not a node in any other PLMN.

Possible Cause values are:

The Address of Recommended Node IE, shown in the following figure, defines the IPv4 or IPv6 format address that the node is identified by in the UMTS network.

Figure 2. Address of Recommended Node IE

The format definition for the Address of Recommended Node information element is the same as the format of the source and destination address of the IP packet that transports the GTPP messages. The optional Alternative Address of Recommended Node IE can be used in the Node Alive Request if the message sender wants to advertise an IP address that is different from the node address format. This way both the IPv4 and IPv6 node address formats can be supported simultaneously in the messaging, regardless of whether IPv4 or IPv6 is used in the underlying transport.

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

A Redirection Response message will be sent as a response of a received Redirection Request.

Possible Cause values are:

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

This message is used to transmit the CDR(s) to the CGF.

The CDRs are placed in the Data Record Packet information element.

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

The Cause (whatever the value may be) applies for all those Data Record Transfer Requests, responded by that particular Data Record Transfer Response.

Possible Cause values are:

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

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

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.

By default, on getting an error response, the request is retried to the same CGF server until max-retries is reached. Then the server is marked as NOT ACTIVE and the request is retried to the secondary server. This behavior is seen for the below response causes.

On getting the following error response causes, the request will NOT retried and the server will be marked as NOT ACTIVE immediately.

No special action is taken on getting "CDR Decoding error" response cause and the behavior is similar to getting a "Request Accepted" cause.

On getting "Version not supported" cause, the request is resent with the version supported by the CGF server (by default, GTPP v2 is supported).

The file format determines the information organization and structure -- format -- of the generated data files. All file formats are different and are customizable.

ePDG-CDRs are generated according to 3GPP TS 32.298 V12.6.0.

G-CDRs are generated according to 3GPP TS 32.251 V6.6.0. Currently ECS supports generation of CDRs using AAAMgrs only.

The ECS also supports enhanced G-CDRs, which is an enhanced format of standard G-CDRs to provide greater portability of charging information. eG-CDRs are compliant with 3GPP TS 32.298 v6.5.0 for Rel. 6 based dictionaries, and with 3GPP TS 32.298 v7.4.0 for Rel. 7 based dictionaries.

By default, the G-CDR does not support the traffic and vendor specific records. To support a traffic and vendor specific record, the ECS must be configured to generate eG-CDRs. eG-CDRs are useful to implement Time Based Charging (TBC) and Flow Based bearer Charging (FBC) to ECS.

eG-CDR supports customer specific formats configured in Ga context in a GGSN service with standard or custom specific GTPP dictionaries.

PGW-CDRs are generated according to 3GPP TS 32.298 V8.5.0.

SGW-CDRs are generated according to 3GPP TS 32.298 V8.7.0.

S-CDRs are generated according to 3GPP TS 32.215 V4.5.0 for Release 4 dictionaries, and 3GPP TS 32.298 V6.4.1 for Release 6 dictionaries.

WLAN-CDRs are generated according to 3GPP TS 32.298 V6.4.1.

The ePDG will use the Charging Characteristics to determine whether to activate or deactivate CDR generation. The Charging Characteristics are also used to set the coherent chargeable event conditions (e.g. time/volume limits that trigger CDR generation or information addition). Multiple Charging Characteristics "profiles" are configured on the ePDG to allow different sets of trigger values.

The following sections describe the triggers for the generation of partial and final G-CDRs and eG-CDRs.

The following events trigger closure and the sending of a partial PGW-CDR:

A PGW-CDR is closed as the final record of a subscriber session for the following events:

The following table lists the values for the "CauseForRecordClosing" field based on trigger scenarios.

The SGSN will use the Charging Characteristics to determine whether to activate or deactivate CDR generation. The Charging Characteristics are also used to set the coherent chargeable event conditions (e.g. time/volume limits that trigger CDR generation or information addition). Multiple Charging Characteristics "profiles" may be configured on the SGSN to allow different sets of trigger values.

The following events trigger closure and sending of a partial SGW-CDR.

An SGW-CDR is closed as the final record of a subscriber session for the following events:

The following table lists the different values for the "CauseForRecordClosing" field depending on the different trigger scenarios.

The following events trigger closure and sending of a partial WLAN-CDR:

A WLAN-CDR is closed as the final record of a session for the following events:

The table below lists the different values for the "CauseForRecordClosing" field depending on the different trigger scenarios.

This feature facilitates sending of local CDR (G-CDR, eGCDR, PGW/SGW CDR, or any other GTPP CDR) files to a remote host using the CLI command gtpp storage-server local file push in context configuration mode or GTPP group configuration mode.

When the push is enabled in a GTPP group then the AAA proxy registers with the HD controller for the push. If the registration is successful then the controller periodically (~1 min) checks to see if any of the registered clients have files, in the CDR_DIR (/records/cdr/<gtpp-group>-<vpnid>/*), to be pushed to the configured remote host URLs. If yes, it will start the PUSH process for that particular client. After pushing all the files of this client, the requests for the next client will be serviced in sequence.

If the registration fails, the client will re-attempt to register indefinitely in intervals unless the configuration is removed. Upon each failure an error log will be printed.

For information on how to configure push functionality, refer to the Configuring CDR Push section in the HDD Storage chapter of this guide.

This feature is developed to suppress the CDRs with zero byte data count, so that the OCG node is not overloaded with a flood of CDRs. The CDRs can be categorized as follows:

The customers can select the CDRs they want to suppress. A new CLI command [ default | no ] gtpp suppress-cdrs zero-volume { external-trigger-cdr | final-cdr | internal-trigger-cdr } is introduced to enable this feature. This feature is disabled by default to ensure backward compatibility. For more information on this command, see Cisco ASR 5500 Command Line Interface Reference.

During an ICSR switchover, the GTPP charging interface between the active chassis and CGF server goes down and all pending CDRs are written to internal hard disk. Once the chassis becomes standby, the CDRs will remain on HDD until the chassis becomes active.

This feature provides a way to move the stranded CDRs from the new standby chassis to the new active chassis and stream them to the OCG. The gtpp push-to-active url CLI command enables/disables the Push-To-Active feature to automatically transfer CDR files from new standby chassis to new active chassis.

Releases prior to 16.0, CDRs from current standby chassis were manually transferred to current active chassis using the CLI command "gtpp storage-server streaming start". Once the transfer is complete, a CLI command in the Exec mode is configured to stream the CDRs to CGF.

In 16.0 and later releases, the stranded CDRs in the standby ICSR node (moved from active to standby) are automatically transferred to the newly active ICSR node. This automation process is achieved through the use of "gtpp push-to-active url" CLI command in the Global Configuration mode.

Charging Data Records (CDRs) play very important role in billing of mobile subscribers and hence are of utmost importance for the mobile service providers. Though eGCDRs and PGW-CDRs comply to 32.298 3GPP standards, many customers have their own requirements (customizations) which may vary from the standards and hence there is a need to create and maintain a new "dictionary" which defines the fields and behavior of that customer's CDR.

GTPP dictionary will define all the attributes e.g. list of all the fields, encoding type (ASCII/ASN.1), release-compliance, supported product-type, etc.

The customizations include:

There are various limitations/drawbacks with the current CDR dictionary implementation:

To nullify the above limitations, a new flexible and extensible framework has been implemented to generate eGCDR and PGW-CDR.

This new framework will be provided to define a dictionary in a structured format using a "Dictionary Definition Language (DDL)". Using this language customers can clearly define fields, encoding and behavior applicable for a particular GTPP dictionary. DDL file will be parsed at compilation time and metadata will be populated to generate eGCDR and PGW-CDR.

PGW-CDRs/eGCDRs have been moved onto flexible DDL based framework. The syntax of these dictionaries/field modified dictionaries can be validated using the ddl_validate binary provided.

In StarOS release 16.0, the CLI command "gtpp egcdr new-path" is used to activate new framework for customized/field defined CDR generations. In release 17.0, the CLI command "gtpp egcdr dynamic-path" should be used to to load the customized or dynamic DDL. This framework provides a mechanism to define and load a customized dictionary by providing the path to the appropriate DDL file through this CLI command.

Customers should explicitly configure the dictionary as there will be no default dictionary. If no dictionary is configured, then eGCDR/PGW-CDR will not be generated.

When customer wants to add/modify/remove a field, this information has to be updated in DDL. The DDL file is processed dynamically and the field reflects in CDR.

It is not recommended to enable gtpp egcdr dynamic-path when there are active calls.

For more information on the command, refer to the Command Line Interface Reference.

In a multi-product deployment environment where CDRs are received from different gateway services like ePDG, SaMOG and (pseudo) P-GW (in Local Breakout scenario), the mediation server finds it difficult to differentiate between the CDRs. Easy identification of CDRs is possible if CDRs corresponding to each gateway service are mapped to different ports of the same CGF server. To achieve this, CLI support is provided to configure multiple GTPP groups with the same CGF server IP address and different port numbers. This configuration provides the flexibility to send the ePDG, SaMOG and P-GW LBO CDRs to the same CGF server on different ports.

For ePDG and SaMOG, different GTPP groups should be configured in the respective call-control profiles. For P-GW LBO, GTPP group is selected from APN configuration.

In releases prior to 20.0, configuration of CGF server with the same IP address but different ports was not allowed within and across GTPP groups. In release 20.1 and later, configuration of CGF server with the same IP address and different ports is allowed across the GTPP groups. With this change, whenever AAA proxy logs are displayed, it includes both CGF IP address and port.

The use of optional keyword port in the gtpp test accounting, show gtpp counters, show gtpp statistics and clear gtpp statistics CLI commands enables this functionality. When port is specified along with IP address in these CLI commands, then the CGF server with the specified IP address and port is only considered. If the port is not specified, then all GTPP servers with the specified IP address will be considered irrespective of the configured port.

For more information on these CLI commands, refer to the Command Line Interface Reference guide.