The Validation Configuration parameters are used in the CGF Node test case to define all CDR validation settings for the test case. The following lists the conditions under which the various validation attributes of the CDR Validation parameters are enabled/available (the Triggers for CDR Closure pane is always available).
|
Triggers for CDR Closure |
|||
|
General Attributes
|
|
|
|
|
Expected Change Conditions |
|||
Measurements collected for the test case are reported on the Billing, GTP', and GTP' Node report tabs.
The maximum number of Billing Records that will be maintained by the CGF node. When partial CDRs are received, they are consolidated into one Billing Record. One Billing Record should be established for every PDP context that is successfully activated. In a Capacity test, for example, one record is established for each PDP context but in a Session Loading Test, a new record is established for each PDP context every time it is activated.
When the maximum number of records is reached, an error indication is sent to the GSN if any CDRs or LDRs are received for a PDP context that does not have an established Billing Record. If you are not interested in collecting or validating records, you can check the Silently Discard Records Exceeding Max box and the node will ignore the excess Data Records .
Range: Variable1
Default: 1
1 Maximum rates, number of sessions, and number of emulated nodes vary depending on the test application and the test system's licensed capacity.
Validate that partial CDRs are generated at the proper intervals. These options are always available regardless of the Mode you selected.
When the GSN generates partial CDRs based on the number of bytes transmitted to the MN, you can use the checkbox to enable volume trigger validation. Enter the number of bytes that should trigger the generation of a partial CDR in the field provided.
Range: N/A
Default: 0
When the GSN generates partial CDRs based on the duration of the PDP context, you can use the checkbox to enable time trigger validation. Enter the number of seconds that should trigger the generation of a partial CDR in the field provided.
Range: N/A
Default: 0
Select the Condition Change Trigger checkbox to enter a value for the expected number of changes and a threshold. This selection and the value indicates that the CGF verifies the number of changes in the received CDRs against the value in the Condition Chnage Trigger and the Threshold parameters.
Clear the Condition Change Trigger checkbox to indicate that the CGF does not validate the CDRs received due to changes in charging condition (hen it reaches a maximum value at device under test).
Range: N/A
Default: 0
The CDR Validation attributes are enabled when the following conditions are met:
Select the checkbox next to the attributes you wish to validate. If you have enabled vendor-specific Type (on the Network Devices>System Under Test pane), the settings will include vendor-specific attributes in addition to the standard CDR attributes listed below.
SGSN Address — The addresses of all SGSNs that serviced the MN during the life of the context.
PDP Type — The Packet Data Protocol used by the context (IPv4, IPv6, or PPP).
PDP Address — The context's IP address.
PDP Address Ext — Supports dual stack (for PGW/SGW test cases). In the case of dual stack (supports both IPv4 and IPv6), IPv4 address is set PDP Address Ext and IPv6 address is set in PDP Address.
Dynamic Address — Whether an IP address was allocated for the PDP context.
APN — The APN associated with the context.
MSISDN — The MN's ISDN.
QOS Negotiated — The QOS associated with the context.
RAT Type — The Radio Access Technology Type information element, which identifies the RAT type used by the SGSN. (This parameter is part of SGSN Node >Gn Interface>GTP Tab>GTP Version 1 configuration and is available for GGSN as a part of PDP Context Request message from SGSN.)
MS Time Zone — The MS Time Zone information element, which enables calculation of the MN's local time. (This parameter is part of SGSN Node>Gn Interface>GTP Tab>GTP Version 1 configuration and is available for GGSN as a part of PDP Context Request message from SGSN.)
Uplink Bytes — The number of bytes transmitted by the MN. Enter the acceptable threshold in the field provided.
Downlink Bytes — The number of bytes received by the MN. Enter the acceptable threshold in the field provided.
Duration — The duration of the PDP context in seconds. Enter the acceptable threshold in the field provided.
Start Time — The time the context was established. Enter the acceptable threshold in the field provided.
EPC QoS Info — Ensures that the formats of QoS attributes (List Of Traffic Volumes) are compliant with R8. That is, ensures correct encoding for SGW CDR, Landslide SGW CDR and Landslide PGW CDR to enable back-to-back testing.
|
TIP: The duration and time reported by an SUT may differ slightly from that reported by a node since the timer on one device is triggered by an event while the timer on the other device is triggered by the receipt of a message. Latency in the network could cause validation to fail unless you use a threshold to account for the discrepancy in timers. |
The Expected Change Conditions pane allows you to select change conditions for GPRS, UMTS and LTE testing. The eG-CDR testing allows you to include both the List of Traffic Volumes and List of Service Data attributes.
The Expected Change Conditions pane is enabled when the settings are as follows.
Selecting the List of Volumes allows you to select the required change condition checkboxes. The CGF Node uses your selection of change conditions to compare the contents of the Change Condition attributes in received CDRs. If the received change conditions match one of the expected change conditions (selected), then the comparison result is considered a success. A validation failure results in the failure being reported.
TAI Change
RAI Change
Record Closure
Tariff Change
User Location Change
CGI-SAI Change
eCGI Change
DT Establishment — GTP Direct Tunnel establishment
DT Removal — GTP Direct Tunnel removal
The List of Service Data includes a list of changes in charging conditions for all service data flows within this PDP context categorized per rating group or per combination of the rating group and service id. Each change is time stamped. Charging conditions are used to categorize traffic volumes, elapsed time, and number of events, such as per tariff period. Initial and subsequently changed QoS and corresponding data values are also listed.
| NOTE: The back-to-back testing using the Change Conditions requires you to select Service Change Condition checkbox from the List of Service Data |
The Expected Causes for Record Closing pane is enabled when the following conditions are met:
Select the Validate Causes checkbox to validate the change conditions that caused record closure of the of CDRs receved.
Selecting the Validate Causes allows you to select the required closure causes checkboxes. The CGF Node uses your selection of closure causes to compare the contents of the Cause For Record Closing attribute in received CDRs. If the received closure causes match one of the expected closure causes (selected), then the comparison result is considered a success. A validation failure results in the failure being reported.
The Per-Flow attributes pane is enabled when the following conditions are met:
Per-Flow Validation is performed only if the flow was able to be classified and if the standard attributes pass validation. (The CGF compares the content of the ‘rATType’ attribute of received vendor CDRs against content of the received landslide CDRs and the comparison result is considered a success if the contents are matched. Failures are reported.)
Select the Uplink Bytes, Downlink Bytes, and duration checkboxes and enter the appropriate value for validation.
Option: 0 - 65535
When the CGF node receives both CDRs and LDRs, it can validate the content of the CDRs by comparing them to the LDRs. You can select the items to validate and acceptable variances between the values reported in the CDRs and LDRs.
|
NOTE: The IPv6 router advertisement messages sent by the GGSN may not be correctly counted (bytes sent vs bytes received), which may result in Record Validation Failures. |