- CDR Transport by GTPP
- Usage of GTPP Header in Charging
- Information Elements
- Node Alive Request
- Node Alive Response
- Redirection Request
- Redirection Response
- Data Record Transfer Request
- Information Elements in Data Record Transfer Request
- Packet Transfer Command IE
- Data Record Packet IE
- Sequence Numbers of Released Packets IE
- Sequence Numbers of Canceled Packets IE
- Private Extension IE
- File Format for CDRs
- Evolved Packet Data Gateway Call Detail Records (ePDG-CDRs)
- ePDG-CDR Format
- G-CDR Format
- eG-CDR Format
- PGW-CDR Format
- SGW-CDR Format
- S-CDR Format
- WLAN-CDR Format
- ePDG-CDR Triggers
- ePDG-CDR Charging Information Addition
- Triggers for ePDG-CDR Closure
- G-CDR Triggers
- eG-CDR Triggers
- PGW-CDR Charging Information Addition
- Triggers for S-CDR Closure
- Triggers for S-CDR Charging Information Addition
- SGW-CDR Charging Information Addition
- WLAN-CDR Charging Information Addition
- CDR Push Functionality
- Zero Volume CDR Suppression
- Automatic Transfer of Stranded CDRs on ICSR
- Limitations
- How this Feature Works
- Limitations
GTPP Accounting Overview
This chapter provides an overview of GPRS Tunneling Protocol Prime (GTPP) protocol accounting, and the following Charging Data Records (CDRs) in the Cisco ASR 5500 Multimedia Core Platform:
- Evolved Packet Data Gateway CDRs (ePDG-CDRs)
- Gateway GPRS Support Node (GGSN) CDRs (G-CDRs), Enhanced GGSN CDRs (eG-CDRs)
- Packet Data Network Gateway (P-GW) CDRs (PGW-CDRs)
- Serving Gateway (S-GW) CDRs (SGW-CDRs)
- Serving GPRS Support Node (SGSN) CDRs (S-CDRs, SM-MO-CDRs, SM-MT-CDRs), Mobility CDRs (M-CDRs)
- Wireless Local Area Network CDRs (WLAN-CDRs)
GTPP Interface Overview
This section provides information on GTPP interface between Charging Gateway Function (CGF) and Cisco Systems' licensed products running on the ASR 5500 core platforms, including the GGSN, P-GW, S-GW, and SGSN in General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS) data networks, 3GPP2 evolved High Rate Packet Data (eHRPD) and Long Term Evolution-System Architecture Evolution (LTE-SAE) wireless data networks.
The Ga is the reference point from Charging Data Function (CDF) to the CGF, which is intended for the transport of CDRs. The CDF could either be GGSN, P-GW, S-GW, or any other similar products.
By definition, dealing with CDRs only implies that Ga is solely related to offline charging.
The following figure depicts the position of the Ga reference point within the overall 3GPP offline charging architecture.
As illustrated in the above figure, 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.
The transport protocol associated to the Ga reference point, providing functions for transfer of CDRs from CDF to CGF, is GTPP.
Each CDF will have an O&M; configurable address list of CGFs (Charging Gateways) to which it can send its CDRs. The list will be organized in CGF address priority order. If the primary CGF is not available (for example, out of service), then the CDF will send the CDRs to the secondary CGF and so on.
Each CDR generating function will only send the records to the CGF(s) of the same PLMN, not to CGF(s) located in other PLMNs.
Each CGF in the PLMN will know the other CGFs' network addresses (for example, for redundancy reasons, to be able to recommend another CGF address). This is achieved by O&M; configuration facilities that will enable each CGF to have a configurable list of peer CGF addresses.
The GTPP charging support is currently available for the following core multimedia gateway products:
- Evolved Packet Data Gateway (ePDG)
- Gateway GPRS Support Node (GGSN)
- IP Services Gateway (IPSG)
- Packet Data Gateway/Tunnel Termination Gateway (PDG/TTG)
- Packet Data Network (PDN) Gateway (P-GW)
- Serving Gateway (S-GW)
- Serving GPRS Support Node (SGSN)
- S2a Mobility Over GTP (SaMOG) Gateway
CDR Transport by GTPP
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:
- CDR transfer between the CDF and the CGF
- Redirection of CDRs to another CGF
- Advertise to peers about its CDR transfer capability (for example, 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 GTPP messaging).
Path Protocol
GTPP uses path protocol to transport CDRs from CDF to CGF over the Ga interface so as to facilitate charging.
The following path protocols are supported for GTPP:
- UDP as the Path Protocol Ports for signaling the request messages:
- The UDP Destination Port may be the server port number 3386 which has been reserved for GTPP. Alternatively, another port can be used as configured by O&M.;
- The UDP Source Port is a locally allocated port number at the sending network element.
Ports for signaling the response messages:
- The UDP Destination Port can be the value of the Source Port of the corresponding request message.
- The UDP Source Port can be the value from the Destination Port of the corresponding request message.
ASR chassis supports IPV4 only as a transport layer IP.
GTPP Message Types
GTPP defines a set of messages between two associated nodes. The GTPP messages defined are shown in the following table. The messages introduced by GTPP are in boldface letters. The other messages are inherited from GTPP protocol.
Message Type value (Decimal)
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
Reserved for future use
The GTPP introduced the following signaling message types as Path Management Messages:
- Node Alive Request
- Node Alive Response
- Redirection Request
- Redirection Response
Echo messages and node-alive messages are not supported if the transport layer protocol is TCP.
The following signaling messages are grouped under the category "Record Transmission Messages":
- Data Record Transfer Request
- Data Record Transfer Response
The reserved fields in the signaling messages can be filled with ones, and are intended for future use.
GTPP reuses the GTPP Cause values. The message type numbers required for the newly introduced GTPP messages have been derived from the unallocated message type number space specified in the GTPP message table defined in TS 29.060.
The number ranges allocated for GTPP are as follows:
For Information Elements: 117-127 (TV type fields) and 239-254 (for TLV type fields).
The following table provides the information on the TLV and TV Information Element types introduced in this document:
TLV Information Element Types
Address of Recommended Node
Charging Gateway Address (this IE is also used in TS 29.060 [200])
Sequence Numbers of Canceled Packets
Sequence Numbers of Released Packets
TV Information Element Types
Packet Transfer Command
Usage of GTPP Header in Charging
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.
Information Elements
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.
GTPP Messages
This section provides the detailed information on the GTPP message types.
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.
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.
Node Alive request messages are not supported if the transport layer protocol is TCP.
The Information elements in a Node Alive Request message are shown in the following table:Alternative Node Address
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.
Node Alive Response
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.
Redirection Request
There are two use cases for the Redirection Request message:
- One is to advise that received CDR traffic is to be redirected to another CGF due to the sending CGF node is about to stop service (due to an outage for maintenance or an error condition).
- The second purpose is to inform a CDF which 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).
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.
Address of Recommended Node
Alternative Address of Recommended Node
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 IE, shown in the following figure, defines the IPv4 or IPv6 format address that the node is identified by in the UMTS network.
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.
Redirection Response
A Redirection Response message will be sent as a response of a received Redirection Request.
The information elements of this message are listed in the following table.
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.
Data Record Transfer Request
This message is used to transmit the CDR(s) to the CGF.
The CDRs are placed in the Data Record Packet information element.
Information Elements in Data Record Transfer Request
The IEs in Data Record Transfer Request message are specified in the following table.
Packet Transfer Command
Sequence Numbers of Released Packets
Sequence Numbers of Canceled Packets
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. The first command is for normal CDR transfer while the other values are only used as part of the redundancy mechanism.The following describes the usage of each Packet Transfer Command. The first command is for normal CDR transfer while the other values are only used as part of the redundancy mechanism.
Send Data Record Packet: This is the usual command used for sending CDRs under normal conditions when no error recovery is needed or the redirection mechanism is not involved. The other three commands are being used only in error recovery cases. Out of the three conditional IEs, only the "Data Record Packet" is present in this message.
Send possibly duplicated Data Record Packet: When the CDR packet is redirected to a secondary CGF (by a CDF) because the currently used CGF is not working or the CDR transfer is not working properly, or if there is an error in the link between the CDF and the CGF, 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.
Cancel Data Record Packet: Of the conditional IEs, the "Sequence Numbers of Canceled Packets" is present in the message.
Release Data Record Packet: Of the conditional IEs, the "Sequence Numbers of Released Packets" is present in the message.
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 authorized to send the Data Record Packets previously marked as possibly duplicated towards the BD as normal (not duplicated) CDRs.
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 CDRs. 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.
There are two fields identifying the CDR format: Data Record Format and Data Record Format Version.
The format of the CDRs is ASN.1 or some other format, as identified by the value of Data Record Format. The Data Record Format Version identifies the TS release and version numbers that were used for the CDR encoding.
Sequence Numbers of Released Packets IE
The Sequence Numbers of Released Packets is present if the Packet Transfer Command is 'Release Data Record Packet'. The format of the Information Element is described in the following figure:
Sequence Numbers of Canceled Packets IE
The following figure shows the sequence numbers of Canceled Packets IE that contains the IE Type, Length and the Sequence Number(s) (each 2 octets) of the canceled Data Record Transfer Request(s). It is present if the Packet Transfer Command is "Cancel Data Record Packet".
Private Extension IE
The optional Private Extension contains vendor- or operator- specific information.
Data Record Transfer Response
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:
- 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
- Sequence numbers of released/canceled packets IE incorrect
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.
Handling Error Response Cause
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.
- Mandatory IE incorrect
- Mandatory IE missing
- Optional IE incorrect
- Invalid message format
On getting the following error response causes, the request will NOT retried and the server will be marked as NOT ACTIVE immediately.
- No resources available
- Service not supported
- System failure
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).
Charging Characteristics
Whether or not the GGSN accepts charging characteristics from the SGSN, the accounting protocol can be configured on a per-APN basis based on whether the subscriber is visiting, roaming, or home.
By default, the GGSN always accepts the charging characteristics from the SGSN. They will be provided by the SGSN for GTPv1 requests for primary PDP contexts. If they are not provided for secondary PDP contexts, the GGSN re-uses those from the primary. The charging characteristics field is optional. If not provided by SGSN, the GGSN selects the locally configured values. Also, there is a provision to override the values from RADIUS as indicated in the following table.
CLI command configured on GGSN
