The CGF Node Test Case
Click here to see this page in full context

The CGF Node Test Case

The CGF Node test case emulates a Charging Gateway Function in a GPRS, UMTS, and LTE test. The node can perform various functions depending on the test case settings and the type of test in which it participates:

The PDP context/EPS Bearer context charging allows the GGSN to collect charging information related to data volumes sent to and received by the UE/MS, categorized by the QoS applied to the PDP/Bearer context.

Flow Based Bearer Charging (FBC)

GGSN - PCEF: The Flow Based Bearer Charging (FBC) is supported for the GGSN and PCEF integration, which categorizes normal PDP context charging of service data flows by rating group or combination of the rating group and service ID. That is, while there is only one uplink and one downlink data volume count per PDP context in PDP context charging, FBC provides one count per each rating group or combination of the rating group and service Id.

PGW - PCEF: In LTE testing, the IP-CAN bearer charging allows the PGW to collect charging information related to data volumes sent to and received by the UE/MS (categorized by the QoS applied to the IP-CAN bearer). The FBC is supported by the PGW with PCEF, which categorized the normal IP-CAN bearer charging of the service data flows within IP-CAN bearer data traffic by rating group or combination of the rating group and service Id. That is, while there is only one uplink and one downlink data volume count per IP-CAN bearer in IP-CAN bearer charging, FBC provides one count per each rating group or combination of the rating group and service Id.

When a CDR is received for a PDP/Bearer context, the CGF node establishes a Data Record for the PDP/Bearer context . Separate Data Records are maintained for each type of CDR:

NOTE: In the G-CDR only one volume container (uplink/downlink) can be active per PDP context, and when FBC is supported, as in eG-CDR, many service data flow containers per PDP context are active simultaneously.

Test Options

At a minimum, the CGF node responds to the GTP' messages received from the configured GSNs/SGW/PGW and can send Node Alive or Echo Request messages to the GSNs/SGW/PGW. The following options may be used depending on the test configuration.

CDR Collection

The Data Records received from GSN/SGW/PGW SUTs or nodes are retained and included with the test results for manual inspection. If the node receives partial CDRs, they are consolidated into one Data Record for the PDP context and then discarded. When the test is complete, your test results directory will contain a compressed file containing the collected Data Records. The file name includes the run ID, test server index, test case index, and ends in "ldr.gz."

NOTE: Every Data Record in the file begins with a "Record Status" line and includes the record attributes and their values. In Collection mode, the status is "Record Received." If an attribute cannot be parsed, the raw hexadecimal content is included and labeled "Malformed Attribute."

CDR Validation

The information in G-CDRs received from a GGSN SUT is compared with S-LDRs received from the SGSN nodes in a GGSN Nodal test, verifying the accuracy of the G-CDRs. M-CDRs, S-CDRs received from an SGSN SUT are validated by comparing them to G-LDRs generated by a UMTS test.

In LTE Testing, the information in PGW-CDRs received from a PGW SUT is compared with SGW-LDRs received from the SGW  nodes in a PGW Nodal test, verifying the accuracy of the PGW-CDRs. SGW-CDRs received from an SGW SUT are validated by comparing them to PGW-LDRs generated by a SGW Nodal test.

You can specify which information should be validated as well as variance thresholds for uplink and downlink volume, context duration, or the number of QOS updates to account for slight differences between the LDRs and CDRs.

When the PDP/Bearer context is deleted and the final CDR and LDR are received, validation is performed and the results are reported. In addition to the validation measurements, the Record Status of each LDR/CDR pair indicates whether the CDR was validated. See CDR Validation settings for the attributes that can be validated. If any Data Records fail validation, the  failed CDR and corresponding LDR are included in the Data Record file. You can choose to include all of the Data Records in the test results by combining the collection and validation functions.

NOTE: The Enhanced Data DMFs (STC Layer 4 - 7 (Avalanche Commander) on Landslide) do not support generation of billing records.

Per-Flow Standard CDR Validation

In LTE testing, Per-Flow validation is performed by the CGF Node upon Session closure, after receiving the last CDR of the session.

Per-Flow validation is not supported for partial CDRs (eG-CDRs or PGW CDRs). This is because PGW Nodal/GGSN Nodal cannot simulate exactly those Change Conditions that are reflected by an eG-CDR or PGW CDR from a real SUT. (The CGF Node accumulates uplink, downlink, and duration on a per-flow basis until session closure.)

Per-Flow Vendor Specific Validation

A CDR may contain vendor-specific extensions that classify bearer plane traffic carried by a PDP context into flows. The definition of a flow varies by vendor but in general, a flow represents the data stream associated with a particular protocol or service. With the GGSN Vendor-Specific Per-Flow CDR Validation feature, you can extend CDR Validation to flow-level attributes and verify that the attribute values allow the flow to be correctly classified in addition to validating the attribute values. In the Data Record file, the per-flow attributes are preceded by a "Flow Start" line that indicates whether the flow was classified. If the flow was classified, Matched Flow=n indicates that the flow matched the nth template definition. No Matching Flow indicates that the flow could not be classified.

Up to 32 classification templates can be defined, and the test attempts to classify the CDRs and validate per-flow attribute values using the template definitions. When necessary, you can capture a value from a data packet and add it to the LDRs by using Auto-Fill Fields. In the example shown, the URL from an HTTP flow was captured using Extract Source Billing Reference and is displayed on the Billing Reference line.

Triggering Validation

If a GSN SUT is configured to generate partial CDRs based on volume or duration, you can verify that the SUT is generating the CDRs at the proper time. With this option, partial CDRs are inspected when they are received and the downlink volume or duration are compared to the values you specify in the test case. If the CDR values are not within the threshold, an error is reported.

NOTE: The CGF Node does not validate that it received all of the CDRs that should have been generated by a SUT; it validates the information in the CDRs that are received.

Change Condition Validation

The CGF allows you to provide an expected number of changes in charging conditions of a test network and (CGF) uses the provided information to compare with the information provided by SUT during a test.  The CGF will then notify you of the comparison result.

The Change In Condition validates whether the SUT correctly records the number of changes in charging conditions by analyzing the received CDRs, counting the charging events (in CDR’s list of volumes) and comparing the result with the provisioned target number (+/- threshold).  If the counted event is within the provisioned range (range = target+/-threshold) the validation is a success.

Failover/Prevent Duplicate CDRs

The CDR Transport by GTP' also prevents duplicate CDRs that might arise during redundancy operations. When CGF Node is configured for failover, the CDR duplication prevention function marks the potentially duplicated CDR packets and delegates the final duplicate deletion task to the primary CGF.

Due to network failure/network congestion or a temporary node failure, a CGF might not be able to send a response within the configured timeout period to a request it got from a CDF. If a CDF loses its connection to the CGF unexpectedly, it may send the CDRs to the secondary CGF/next CGF in the priority list. If the CGF changes, the CDF continues to send CDRs to a different CGF node, depending on which CGF has been configured as the receiver of CDRs for a particular service.

Test Configurations

Use the CGF Node test case in conjunction with the GGSN Nodal test case to compare the G-CDRs generated by the GGSN SUT with the S-LDRs or M-CDRs generated by the SGSN node. All validation options are available in this configuration. The CGF Node must be executed on a separate test server to utilize its full capacity.

Use the CGF Node test case in conjunction with the UMTS test case to compare the S-CDRs generated by the SGSN SUT with the G-LDRs generated by the GGSN node. All validation options are available in this configuration. The CGF Node must be executed on a separate test server to utilize its full capacity.

TIP: Use Automation Control to ensure that the CGF Node test case does not stop until after the nodal test case reaches the stopped state. Otherwise the node may not receive all of the final CDRs and LDRs.

You can also use the CGF Node test case in standalone mode to supply any type of test with a simulated CGF that will reply to messages received from an SGSN or GGSN. In this configuration, CDR Collection, Validation, and Triggering Validation are supported. However, Per-Flow validation is not supported, because S-CDR or SGW CDR do not include any per-flow information.

CGF Node Test Case with SGW/PGW

You can set up the SGW/PGW Nodal test cases to add the required billing record type and address in SUT configuration. The CDR-validation is triggered when two billing records with the same charging ID is received from both PGW and SGW.

NOTES:
  • In the above test configuration, per-flow validation does not work, as no per-flow data is available on SGW side, but traffic (Uplink/Downlink bytes) in the List of Service Data of PGW will be aggregated per bearer and this aggregated data will be compared against the traffic in the List of Traffic Volume of SGW.
  • The combination of PGW or GGSN address (not NodeId) and charging Id is used as the key for billing object.
  • S5/8 interface is used between SGW and PGW.

Example Test Configuration and CDR Validation

Landslide Emulated CGF Node validates by comparing a SGW-CDR with a PGW-CDR and indicates whether the comparison results are valid. The table below shows example CDR Validation for 3 LTE test configuration options:

 

Configure...

CDR Validation...

1.
  • Landslide CGF Node Test Case

  • Your SGW and PGW Devices Under Test

 
  • Your SGW and PGW devices unter test generate the CDRs
  • Landslide CGF compares the two different CDRs from the SUTs and validates to ensure that they are providing the same information.

2.
  • Landslide SGW Nodal with PGW emulation

  • Your SGW Device Under Test
  • Both emulated PGW and your SGW device under test generate CDRs.
  • The Landslide CGF compares the two different CDRs, one from the emulated PGW and one from your SGW  and validates to ensure that they are providing the same information.

3.
  • Landslide PGW Nodal to emulate SGW
  • Your PGW Device Under Test
  • Both emulated SGW and your PGW device under test generate CDRs.
  • Landslide CGF compares the two different CDRs, one from the emulated SGW and one from your PGW and validates to ensure that they are providing the same information.

Per-Flow Charging

Landslide includes eG-CDR/PGW-CDR to support Flow Based Charging. The following illustrates eG-CDR collection and processing in a single CGF node setup, GGSN Nodal, and PGW Nodal (PGW-CDR) testing.

The eG-CDR/PGW-CDR processing requires collection of all specified attributes:

FBC In GGSN Nodal

The GGSN Nodal test case generates and sends LDRs (SGSN Node LDRs) to CGF Node test case. The SGSN LDR includes:

The CGF Node validates the eG-CDR (from the GGSN SUT) per Flow Attributes against S-CDR (from the SGSN).

FBC in PGW Nodal

The PGW Nodal test case generates and sends LDRs (SGW Node LDRs) to CGF Node test case. The SGW LDR includes:

The CGF Node validates the PGW-CDR (from the PGW SUT) per Flow Attributes against SGW-CDR (from the SGW).

 

Test Definition

With this test case, you define:

Measurements collected for this test case include:

Learn more about:

Learn how to:

Measurements

Measurements collected for the CGF Node test case are reported on the following tabs: