About CGF Emulation

The CGF Emulation feature allows you to add a virtual Charging Gateway Function (CGF node) to your GPRS, UMTS, or LTE test environment. The CGF node can accept and respond to Charging Data Records (CDRs) and may be able to validate the accuracy or timeliness of the CDRs received depending on the test configuration.

When describing CGF Emulation, the following definitions are used:

Mobile Subscriber (MS) — The mobile subscriber unit.
Serving GPRS Support Node (SGSN) — The SGSN serves as the mobile subscriber's access point to the GPRS network, and may reside in either the subscriber's home PLMN or a visited PLMN. It is primarily responsible for network access control and mobility management. An SGSN can generate S-CDRs and M-CDRs.
Gateway GPRS Support Node (GGSN) — The GGSN provides interworking with packet data networks, and is connected with SGSNs. A GGSN can generate G-CDRs.
Serving Gateway Node (SGW) — The SGW provides interworking with packet data networks, and is connected with PGWs. A SGW can generate SGW-CDRs.
PDN Gateway Node (PGW) — The PGW provides interworking with packet data networks, and is connected with SGWs. A PGW can generate PGW-CDRs.
GPRS Support Node (GSN) — A generic term that can refer to either an SGSN or GGSN when a distinction between the two is not necessary.
Charging Gateway Functionality (CGF) — The CGF collects and processes CDRs received from SGSNs and GGSNs and interfaces with the network's billing system.
Network Host — An application server with which the MN can exchange bearer plane traffic.
Landslide Data Record (LDR) — A data record generated by the test system containing the same information elements as a CDR generated by a GSN.

As the MN establishes PDP contexts and sends and receives bearer plane packets, the MN's SGSN and GGSN may generate CDRs tracking the MN's uplink and downlink volume among other information. The SGSN collects charging information related to radio network usage, while the GGSN collects charging information related to packet data network usage. Both GSNs collect information related to Core Network resource usage. The GSNs forward the charging information to the CGF for processing via the Ga interface using the GTP' (GTP Prime) protocol. The CGF processes the CDRs received and forwards the information to the network's billing system (interaction between the CGF and a billing system is beyond the scope of this document).

A general GPRS network model is shown in the diagram below.

The CGF Node test case takes the place of a physical CGF. When used in conjunction with the GGSN Nodal and UMTS Nodal test case, the CGF node can collect G-CDRs from a GGSN and LDRs generated by the SGSN node (SGSN node emulated either by GGSN Nodal or UMTS Nodal test case) . When used in conjunction with the UMTS test case, the CGF node can collect S-CDRs or M-CDRs from an SGSN and LDRs generated by the GGSN node. The test can collect CDRs and LDRs for manual comparison, validate selected information in the CDRs based on the information received in LDRs, or both. When used in standalone mode, the CGF Node test case can collect CDRs from SGSNs and GGSNs for manual inspection, or be used to simply respond to messages received from a GSN, alleviating the need for a physical CGF in a test network.

Learn more about the CGF Node test case

A general LTE network model is shown in the diagram below.

Similar to GPRS and UMTS testing, the CGF Node test case takes the place of a physical CGF. When used in conjunction with the SGW Nodal and PGW Nodal test case, the CGF node can collect SGW-CDRs from a SGW and LDRs generated by the PGW node. When used in conjunction with the PGW test case, the CGF node can collect PGW-CDRs from an PGW and LDRs generated by the SGW node. The test can collect CDRs and LDRs for manual comparison, validate selected information in the CDRs based on the information received in LDRs, or both. When used in standalone mode, the CGF Node test case can collect CDRs from SGSNs and GGSNs for manual inspection, or be used to simply respond to messages received from a SGW/PGW, alleviating the need for a physical CGF in a test network.

Protocols

GTP' (versions 0— 2 supported): GTP' performs the following functions:

Transfer CDRs between the CDF and the CGF.
Redirection of CDRs to another CGF.
Detect communication failures between the communicating peers, using echo messaging.
Advertise to peers about its CDR transfer capability (e.g., after a period of service downtime).
Prevent duplicate CDRs that might arise during redundancy operations. When configured, the CDR duplication prevention function marks potentially duplicated CDR packets, and, delegates the final duplicate deletion task to a CGF or the Billing Domain (instead of handling the possible duplicates solely by GTP' messaging).

Emulators

Testing with a CGF

The Ga interface supports GTP' over either UDP or TCP. When the test begins, the CGF node alerts the selected GSNs that it is available to receive CDRs. When TCP is used, the CGF node establishes a TCP connection with the GSN. When UDP is used, the CGF node sends a Node Alive Request to the GSNs to notify them that it is available (optional with TCP). A GSN responds to a Node Alive Request with a Node Alive Response, confirming connectivity between the devices.

The GSN records PDP context activity for MSs including uplink and downlink volume, MN-initiated QOS updates, the duration of the context, the addresses of the SGSNs that have serviced the context, and other information such as APN and MS ISDN. Depending on its provisioning, a GSN may generate one CDR for a PDP context when the context is deleted or it may generate multiple partial CDRs for a context during its lifetime. Generation of partial CDRs can be triggered by time or volume, and a final CDR is sent when the context is deleted. In either case, the GSN transmits CDRs to the CGF using a Data Record Transfer Request message with a Send Data Packet indicator and it may bundle multiple CDRs in one transfer message.

When the CGF node receives a Data Record Transfer Request message, it processes the GTP' header first, then the CDRs contained in the message, and responds to the GSN with a Data Record Transfer Response message indicating that the CDRs were successfully processed or that an error was encountered. Error indications include but are not limited to duplicate GTP' sequence number, GTP' version not supported by the CGF, malformed packet, or missing mandatory information.

At any point during the test, the GSN may send an Echo Request or Node Alive Request message to the CGF. The CGF node supports these messages and will reply with the appropriate response message. You can also configure the CGF node to send periodic Echo Requests. When a GTP'/TCP test is stopped, the CGF node closes the TCP connections.

NOTES:

G-CDRs (generated by a GGSN), S-CDRs and M-CDRs (generated by an SGSN), SGW-CDR (generated by SGW), PGW-CDR (generated by PGW), and eG-CDR are supported. S-SMO-CDRs, S-SMT-CDRs, LCS-MT-CDRs, LCS-MO-CDRs, and LCS-NI-CDRs are not supported at this time.
Supports failover simulation to prevent GTP’ duplicate packet detection.

Failover Simulation

Landslide supports GTP' messaging of Data Record Transfer Request/Response messaging related CDR handling under normal packet transfer, connection (CDF-CGF) breaks after successful CDR transfer and connection (CDF-CGF) breaks before successful CDR transfer. The latter two scenarios trigger the failover mechanism to prevent duplicate CDRs.

Under the normal CDR packet transfer conditions, the CDF sends a successful CDR packet to the CGF, and the CDF receives a response (Request Accepted) for the Data Record Transfer Request.

When the CDF-CGF connection breaks, it triggers the duplicate CDR prevention mechanisms.

The CDF-CGF connection breaks after a successful CDR reception

In this case, the CDR sent by the CDF is received correctly by the CGF and moved to its non-volatile memory (or even to the next NE in the communication chain). However, the CDF-CGF communication stops working before the CDF gets the positive response (Data Record Transfer Response: Request Accepted). Hence, no acknowledge is received to indicate that the CGF received the CDR packet.

The CDF-CGF connection breaks before a successful CDR reception

In this case the CDR packet sent by the CDF is lost before it is received by the CGF. (The loss might be caused by a link failure).

Duplicate CDR Prevention

Landslide supports a mechanism that prevents sending more than one copy of a given CDR to BD (Billing Domain) during failover situations. The CDF (Charging Data Function) component can send a copy of CDR to a secondary CGF2 (Charging Gateway Function) if CGF1 failed after the CDR has been sent to this primary server.

Landslide simulates both CDF and CGF:

CFG as the SUT is the GGSN device with CDF functionality embedded
CDF to test the Duplicate CDR Prevention mechanism.

Ga — The reference point between a CDF and the CGF for CDR transfer.
Bx — The reference point between any (generic) 3G domain, subsystem or service CGF and the BD.

CGF Redirection

The CGF Redirection supports a mechanism of changing designated CGF enroute, for example, from the CGF1 to CGF2, by sending a GTP’ Redirection Request from CGF1 to CDF. The GTP’ Redirection Request message specifies the IP Address of the new designated CGF (CGF2). Once the message has been received by CDF, it stops sending the CDRs to CGF1, launches the CDF – CGF2 connection, and, as soon as the connection has been established sends the CDRs toward CGF2. In turn, the CGF2 can send the “Redirect” message to the CDF redirecting the billing traffic from CGF2 to another CGF (for example, to CGF1).

If connection has been made with CGF2, the current connection could be kept alive even when the active path is switched to another CGF.

NOTE: Testing the CGF Redirection functionality requires you to use separate CGF Node Test Cases: one per CGF. Configuring separate CGF Node TC allows you to observe/track measurements for each CGF. A maximum of 4 CGF may be configured.