> GTPP Accounting Overview
> This chapter provides an overview of GTPP accounting, GGSN Call Detail Records (G-CDRs), Enhanced GGSN Call Detail Records (eG-CDRs), PDN Gateway CDRs (PGW-CDRs), and Serving Gateway CDRs (SGW-CDRs) in the Cisco ASR 5000 Series Multimedia Core Platform.
> Overview
> This section provides information on GTPP interface between Charging Gateway Function (CGF) and Cisco Systems’ licensed products running on the ASR 5000 core platforms, such as Packet Data Network (PDN) Gateway (P-GW) and Serving Gateway (S-GW) in 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 Charging Data Records (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.
> 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.
> 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.

> • | TCP as the 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 network element.
> Important: ASR 5K 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.
> GTPP Messages

> Message Type value(Decimal) | GTPP Message
> 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

> ‌
> The messages introduced by GTPP are in boldface letters. The other messages are inherited from GTPP protocol.
> The GTPP introduced the following signaling message types as Path Management Messages:

> • | Node Alive Request

> • | Node Alive Response

> • | Redirection Request

> • | Redirection Response

> Important: 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 and TV Information Element Types

> TLV Information Element Types
> 254 | Address of Recommended Node
> 253 | Requests Responded
> 252 | Data Record Packet
> 251 | Charging Gateway Address (this IE is also used in TS 29.060 [200])
> 250 | Sequence Numbers of Cancelled Packets
> 249 | Sequence Numbers of Released Packets
> TV Information Element Types
> 127 | Charging ID
> 126 | 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.
> GTPP Header
> 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.
> Important: 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:
> Node Alive Request Message

> Information Element | Presence Requirement
> Node Address | Mandatory
> Alternative Node Address | Optional
> Private Extension | Optional

> ‌
> 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, shall be sent as a response to a received Node Alive Request.
> Node Alive Response Message

> Information Element | Presence Requirement
> Private Extension | Optional

> ‌
> 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 shall only describe an intra-PLMN node containing a CGF, and not a node in any other PLMN.
> Redirection Request Message

> Information Element | Presence Requirement
> Cause | Mandatory
> Address of Recommended Node | Optional
> Alternative 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 IE, shown in the following figure, defines the IPv4 or IPv6 format address that the node is identified by in the UMTS network.
> 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.
> Redirection Response
> A Redirection Response message shall be sent as a response of a received Redirection Request.
> The information elements of this message are listed in the following table.
> Redirection Response Message

> 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.
> 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.
> Data Record Transfer Request Message

> 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

> ‌
> 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 Cancelled 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 Released Packets IE
> Sequence Numbers of Cancelled Packets IE
> The following figure shows the sequence numbers of Cancelled Packets IE that 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".
> Sequence Numbers of Cancelled Packets IE
> Private Extension IE
> The optional Private Extension contains vendor- or operator- specific information.
> Data Record Transfer Response
> The message shall 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/cancelled 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).
> GTPP Configuration
> Cisco Systems’ GGSN/P-GW/S-GW supports both GTPP- and RADIUS-based accounting. The accounting protocol is configured on a per-APN basis.
> When the GPRS Tunneling Protocol Prime (GTPP) protocol is used, accounting messages are sent to the Charging Gateways (CGs) over the Ga interface. The Ga interface and GTPP functionality are typically configured within the system's source context. As specified by the standards, a CDR is not generated when a session starts. CDRs are generated according to the interim triggers configured using the charging characteristics configured for the GGSN, and a CDR is generated when the session ends. For interim accounting, STOP/START pairs are sent based on configured triggers.
> GTPP version 2 is always used. However, if version 2 is not supported by the Charging Gateway Function (CGF), the system reverts to using GTPP version 1. All subsequent CDRs are always fully-qualified partial CDRs. GTPP version 0 is not supported.
> GTPP is configured at the routing context level. Some of the configurables associated with GTPP are Attributes, Charging Agent, Deadtime, etc. The GTPP configuration commands vary according to the services configured, for example, the commands used for GGSN might differ from what is configured for P-GW. For more information on the configuration commands, refer to the Cisco ASR 5000 Series Command Line Interface Reference.
> 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 | Sent by SGSN | Sent by AAA | CC used
> no cc-sgsn | no cc | no cc | Default
> cc | Default
> cc | no cc | SGSN
> cc | SGSN
> cc-sgsn use-ggsn | no cc | no cc | GGSN
> cc | GGSN
> cc | no cc | GGSN
> cc | GGSN
> cc-sgsn radius-returned | no cc | no cc | Default
> cc | AAA
> cc | no cc | SGSN
> cc | AAA
> cc-sgsn radius-returned use-ggsn | no cc | no cc | GGSN
> cc | AAA
> cc | no cc | GGSN
> cc | AAA

> ‌
> If the system is configured to reject the charging characteristics from the SGSN, the GGSN can be configured with its own that can be applied based on the subscriber type (visiting, roaming, or home) at the APN level. The charging characteristics consists of a string of 16 bits designated as profile index and behavior settings. The GGSN supports up to 16 profile indexes numbered 0 through 15 whereas P-GW/S-GW supports up to a maximum of 256 charging profiles.
> The profile indexes specify the criteria for closing accounting records based on specific criteria.
> When a bearer is activated, an appropriate charging profile will be selected based on the following sources of input:

> • | Downloaded AAA attribute (ONLY in P-GW)

> • | MME/HSS via charging characteristics IE

> • | Local defaults

> Following is the order of precedence when charging profile value is received from multiple sources.

> • | Profile index in the override rule on the APN

> • | Profile index in the override rule on the gateway

> • | Profile index from AAA in case of P-GW

> • | Profile index from non-override rule on the APN

> • | Profile index from non-override rule on the gateway

> For more information on the commands that configure additional GTPP accounting properties, refer to the Cisco ASR 5000 Series Command Line Interface Reference.
> GTPP Accounting Interface in ECS
> Enhanced Charging Service (ECS) supports different accounting and charging interfaces for prepaid and postpaid charging and record generation.
> GTPP accounting in ECS allows the collection of counters for different types of data traffic and including that data in a G-CDR that is sent to the CGF.
> Standard G-CDRs do not have an attribute which defines traffic counters depending upon the traffic type but they do have a field named Record Extensions where all vendor specific information can be included. ECS includes the counters for different types of data traffic in this field when sending a G-CDR.
> Charging Record Generation
> ECS provides for the generation of charging data files, which can be periodically retrieved from the system and used as input to a billing system for post-processing.
> The results of traffic analyzer are used to generate session usage data. The generated usage data are in a standard format, so that the impact on the existing billing system is minimal and at the same time, these records contain all the information required for billing based on the content.
> The accounting records also contain the information to identify the user, with Dynamic address assignment and information to obtain the URL for HTTP content request or a file-name or path from FTP request, the type of service from the first packet of the connection, and transaction termination information so that the billing system can decide transaction success or failure.
> Charging records support details of the termination such as which end initiated the termination, termination type e.g. RST, FIN, etc. and in case of HTTP 1.1, whether or not the connection is still open. ECS supports pipelining of up to 15 HTTP requests on the same TCP connection. The billing system, based on this information, decides upon the success or failure of the connection and charge or refund accordingly.
> To cover the requirements of standard solutions and at the same time, provide flexible and detailed information on service usage, ECS provides the following types of usage records:

> • | Standard GGSN Call Detail Records (G-CDRs)

> • | Enhanced GGSN Call Detail Records (eG-CDRs)

> The ASR 5000 Series Multimedia Core Platform supports multiple fields for use in G-CDRs and eG-CDRs. All G-CDRs and eG-CDRs are encoded using the ASN.1 format and are sent to the CGF using the GTPP.
> Important: The behavior for several of the fields supported in CDRs can be modified. For more information, refer to the Cisco ASR 5000 Series Command Line Interface Reference.
> Standard GGSN Call Detail Records (G-CDRs)
> G-CDRs are generated according to 3GPP TS 32.251 V6.6.0. Currently ECS supports generation of CDRs using AAAMgrs only.
> G-CDR Format
> The G-CDRs can be in ASN.1 Format.
> Enhanced GGSN Call Detail Records (eG-CDRs)
> 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.
> eG-CDR Format
> The eG-CDRs can be in ASN.1 Format.
> For more information on G-CDR and eG-CDR attributes and definitions, refer to the G-CDR and Enhanced G-CDR Field Descriptions chapter in this reference guide.
> PDN Gateway Call Detail Records (PGW-CDRs)
> PGW-CDRs are generated according to 3GPP TS 32.298 V8.5.0.
> PGW-CDR Format
> The PGW-CDRs can be in ASN.1 Format.
> Serving Gateway Call Detail Records (SGW-CDRs)
> SGW-CDRs are generated according to 3GPP TS 32.298 V8.5.0.
> SGW-CDR Format
> The SGW-CDRs can be in ASN.1 Format.
> Sample GTPP Configuration
> This section provides an example of the sample GTPP configuration applied to various products.
> Sample Configuration for GGSN/PGW
> This section provides an example of the sample GTPP configuration for GGSN and PGW.

> 1. | Configure the GTPP group and accounting context configuration in APN level and also specify the accounting-mode.

> configure
> context source
> apn apnname1.com
> accounting-mode gtpp
> gtpp group group1 accounting-context billing
> end

> 2. | Configure the GTPP group related parameters like GTPP server parameters, GTPP dictionary, and optionally CGF to support GTPP accounting:

> configure
> context source
> gtpp group group1
> gtpp charging-agent address 1.2.3.4 port 3386
> gtpp server 1.3.5.6 max msgs priority 1
> gtpp dictionary dict1
> gtpp max-cdr 255 wait-time 10
> gtpp transport-layer udp
> end
> Important: For GGSN, accounting context can also be configured in GGSN service. In this case more priority will be given to the APN level configuration. In APN level, if no accounting context is configured then accounting context configured in GGSN service shall be considered.
> configure
> context source
> ggsn-service ggsn1
> accounting context billing
> end
> Sample Configuration for SGW
> This section provides an example of the sample GTPP configuration for SGW.

> 1. | In subscriber level configure GTPP in the accounting-mode.

> configure
> context dest1
> subscriber default
> accounting-mode gtpp
> end

> 2. | Configure accounting policy in context level. This is required only for time/tariff/volume threshold configuration.

> configure
> context dest1
> policy accounting lte
> cc profile 1 interval 60
> cc profile 1 volume total 100000
> cc profile 1 tariff time 1 0 0 time 2 2 2 time 3 4 4 time 4 5 5
> cc profile 1 buckets 3
> cc profile 1 serving-nodes 4
> end

> 3. | Associate the accounting policy with the SGW service.

> configure
> context source
> sgw-service sgw1
> associate accounting-policy lte
> end

> 4. | Configure the accounting context and GTPP group in SGW service level. If accounting context is not configured in SGW service the source context and "default" GTPP group will be selected.

> configure
> context source
> sgw-service sgw1
> accounting context dest1 gtpp group sgw
> end

> 5. | Configure the GTPP group related parameters.

> configure
> context source
> gtpp group group1
> gtpp charging-agent address 1.2.3.4 port 3386
> gtpp server 1.3.5.6 max msgs priority 1
> gtpp dictionary dict1
> gtpp max-cdr 255 wait-time 10
> gtpp transport-layer udp
> end

Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883