GTP'

Not to be confused with GTP.

GTP' (GTP prime) is an IP based protocol used within GSM and UMTS networks. It can be used with UDP or TCP. GTP' uses the same message structure as GTP (GTP-C, GTP-U), but it is largely a separate protocol. GTP' uses registered UDP/TCP port 3386.

GTP' can be used for carrying charging data from the "Charging Data Function" (CDF) of the GSM or UMTS network to the "Charging Gateway Function" (CGF). In most cases, this should mean from many individual network elements such as the GGSNs to a centralised computer which then delivers the charging data more conveniently to the network operator's billing center.

GTP' is used on the Ga interface within the 3GPP GPRS Core Network definition.

GTP' reuses aspects of GTP, although to quote 3GPP TS 32.295, "only the signalling plane of GTP is partly reused". GTP' defines a different header, additional messages, field values, as well as a synchronisation protocol to avoid losing or duplicating CDRs on CGF or SGSN/GGSN failure. Transferred CDRs, if following 3GPP standards, are encoded in ASN.1.

Header

GTP' v1 and v2 headers contain the following fields

+	Bits 0-2			3	4	5	6	7	8-15								16-31																32-47
0	Version			PT [0]	Reserved			Hdr len	Message Type								Length																Sequence Number

Version

The first header field in a GTP' packet is the 3-bit version field. For GTP' v2, this has a value of 2 (hence the name GTP' v2).

Protocol Type (PT)

a 1-bit value that differentiates GTP' (value 0) from GTP (value 1).

Reserved

a 3-bit reserved field (must be 1's).

Header Length (Hdr len)

a 1-bit value that for GTP' version 0 indicates if using a 20 byte header (value 0) (as per GTP) or this 6 byte header. This bit must be unset (value 0) for subsequent GTP' versions and in these does not indicate the header length as this must always be 6 bytes.

Message Type

An 8-bit field that states the message type. Possible values:

Message Type	Description
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

Length

A 16-bit field that states the length of the packet being encapsulated by GTP' (not including the GTP' header itself).

Sequence Number

A 16-bit field that uniquely identifies this packet and allows detection of loss or duplication

Message Types

GTP' uses the GTP Version Not Supported, Echo Request and Echo Response messages unchanged, but adds the following messages

• Node Alive Request
• Node Alive Response
• Redirection Request
• Redirection Response
• Data Record Transfer Request
• Data Record Transfer Response

Node Alive Request / Response

The Node Alive messages are used to advise other network components that a node has started service. The request is sent from the node starting and so provides a faster method to re-enable service than polling using Echo Request/Response does. This message can also be used to advise of other nodes coming back into service, and (in GTP' version 2) to advise of the IPv6 address of the CGF.

Redirection Request/Response

The Redirection messages are used to:

1. divert the flow of CDRs from the CDFs (SGSN/GGSN) to another CGF when the sender is being removed from service (for maintenance/failure).
2. advise that the CGF has lost its connection to a downstream system

In either case the CDFs are given more information about an impending or immediate failure than would be the case if the CDF was polling using Echo Request messages.

This message contains details about the cause, and optionally address(es) of an alternate CGF.

Data Record Transfer Request/Response

The Data Record Transfer messages are used to reliably transport CDRs from the point of generation (SGSN/GGSN) to non-volatile storage in the CGF.

Data Record Transfer Request

Each Data Record Transfer Request message can contain a message of one of four types:

1. Send Data Record Packet - This message contains zero or more CDRs. CDRs may be encoded in ASN.1 using BER or, less commonly, PER.
2. Send possibly duplicated Data Record Packet - This message contains one or more CDRs, and this message has previously been sent to another CGF.
3. Cancel Data Record Packet - This message orders the CGF to remove one or more Data Record Packet from the CGF "possibly duplicated" pending queue.
4. Release Data Record Packet - This message orders the CGF to write the contents of one or more Data Record Packets from the CGF "possibly duplicated" pending queue.

There is a mechanism to attempt to avoid losing or writing any duplicate CDRs. This is described in some detail in 3GPP TS 32.295. The basic premise is that every packet is sequenced and if not individually acknowledged then it will be resent until it is acknowledged by any CGF. Normal Data Record packets are immediately written to non-volatile storage (e.g. disk), but resent packets are marked as "possibly duplicated" and enter a special queue that is not immediately written to non-volatile storage—a second confirmation from the CDF is required.

The ability to send a Data Record Transfer Request containing zero CDRs is used as a test to detect the success or failure of the CGF to have already written records assigned to that sequence number and is an important part of the above mechanism.

Data Record Transfer Response

The Data Record Transfer Response acknowledges receipt of one or more Data Record Transfer messages; responses can be grouped for reasons of efficiency but must be sent more frequently than the sending CDFs timeout.

The acknowledgement includes a cause and can be a rejection of the contained records.

External links

• Direct access to the numbered 3GPP specifications
• Open source Charging Gateway Function (CGF)