You can configure a CGF node to respond to GTP' messages received from GSN SUTs or nodes, collect data records for inspection, or to validate the timeliness and accuracy of CDRs depending on the features you purchased for your test system. This topic will guide you through configuring a CGF Node test case as a simple responder in a GGSN Nodal test case and then adding the various options. The same methodology can be used with the UMTS test case by substituting S-CDR for G-CDR and G-LDR for S-LDR.
After you have a functioning CGF node, you can add the following options:
CDR Validation (CDR Validation feature required)
You should have a basic understanding of the test system:
Prepare the system and gather information about the SUT:
Add a SUT definition for the GGSN SUT's Ga interface if necessary
The GTP' version and transport protocol used by the GSNs
In this section, we will add a CGF Node test case to a GGSN Nodal test session and configure the node to respond to GTP' messages received from the GGSN SUT. Open a functioning GGSN Nodal Capacity test session that includes Data Traffic and add a CGF Node test case from the Basic library.
GGSN Definition — Identify the SUT
Since the node will only be supporting one GGSN, accept the default selection in Number of (Peer) SUTs. A separate, numbered sub-tab is displayed for each GSN supported by the node. In this case, the GGSN is defined on sub-tab 1.
If the GGSN is configured to initiate a connection with a CGF, select Passive from the Initiate Mode... drop-down list. Otherwise, accept the Active default and then select the GGSN Ga SUT from the Peer drop-down list.
Identify the type of Data Records that the node will receive from the peer by selecting GGSN from the Type... drop-down list.
Modify the Dest Port value if the GGSN does not use port 3386 for GTP'.
Select the Transport protocol used by the GGSN. If you select TCP, the node will send periodic Node Alive messages to maintain the connection when the box is checked.
Node Definition — Configure the node's address, protocol options, and capabilities.
In the CGF Node Address sub-tab, select an Ethernet interface from the Physical Interface drop-down list and enter a Starting IP Address that is unique to the test session. Configure the GGSN to send GTP' traffic to this address if necessary.
In the GTP' pane, modify the GTP' Version... and Header Length... selections to conform with the GGSN if necessary.
In the bottom pane, select a GPRS Release... that conforms with the GGSN and set the node's processing Mode... to Statistics Only.
You are now ready to test your configuration. The parameters that have not been addressed control optional behaviors that do not affect the success of this test. Click OK to accept the test case. If any parameters fail validation, you will receive an error indicating the problem parameter. Correct the problem and when the definition is accepted, the test case is listed in the Test Session window.
When you run the test session, the CGF Node test case should start first and should not stop until after the GGSN Nodal test case is finished and the final messages have been received from the GGSN. Use Automation Control to define the test case execution sequencing. Make sure that the stop step for the node includes as a predecessor that the nodal test case has reached the STOPPED state, and add a delay time of at least 60 seconds to ensure that the GGSN has time to transmit all of the data records to the node. (See Adding Automation Control for instructions.)
Run the test session, and a validation check is performed on the test session. This validation ensures that the IP addresses used by the test case do not conflict with any other test sessions that may be running on the test server, and that the test definition does not violate rate and volume limits. You will also receive an error if you attempt to run the test session on a test server that is already running at capacity or is otherwise unable to accept a test session. See Running a Test Session for more information on handling these types of errors.
Select the Reports tab when it becomes available and then select the GTP' sub-tab. Depending on the Initiate Mode setting, you should see that 1 Node Alive request was either sent (Active) or received (Passive) and that 1 Node Alive response was either received or sent. Select the CGF Node test case from the Report View drop-down list and explore the measurements displayed on the tabs. The measurement definitions are located in the Measurement Reference. Stop the test session when you are ready to continue, and you should see that GGSN Data Records (on the Billing sub-tab) were received for each PDP context.
|
TROUBLESHOOT: If a Node Alive request or response was not received, confirm that there is connectivity between the CGF node and the GGSN's Ga interface. If you selected Active initiate mode, ensure that you selected the SUT definition for the GGSN's Ga interface rather than its Gn interface in the Peer list. |
Now that you have a functioning test case, you can customize the GTP' options that were not addressed in the initial configuration:
When you want to configure a CGF node to support multiple test sessions or to support other lab operations, you can use the test case in a standalone test session and run the session when you need CGF support.
When the node is in collection mode, it retains all of the Data Records received and includes them in the test results. If the node receives partial Data Records, they are consolidated into one record per PDP context.
Open your CGF Node test case.
Enter the total number of Billing Records that will be maintained by the node in Max Data Records... This value should match the total number of PDP contexts in your GGSN Nodal test case.
Select Collection from the Mode drop-down list.
Run your test session and you will see that Free Billing Records on the Billing report tab matches the value that you entered in Max Data Records. As Billing Records are established, Active Billing Records is incremented and Free Billing Records is decremented accordingly.
When you stop the test, an compressed file with a ".ldr.gz" extension is available in your Test Results. In the compressed file you'll find a text file that contains all of the final Data Records. Each record begins with a "Record Status" line, and in this case the status is Record Received, indicating that the records were only collected and consolidated and that no further processing was performed.
|
TROUBLESHOOT: If the node does not receive the correct number of Data Records, increase the delay time in the Stop step for the CGF Node test case. The test case may be stopping before the GGSN sends all of the G-CDRs. |
If the GGSN is configured to send partial Data Records based on the duration or throughput of the context, you can validate that the G-CDRs were generated at the appropriate times.
Open your CGF Node test case.
Check either the Volume Trigger box or the Time Trigger box depending on which method the GGSN uses to trigger partial CDR generation, and enter the triggering value, in seconds or bytes depending on the trigger type, in the field provided.
If a slight variance is acceptable, enter the tolerance level in the appropriate Threshold field.
Run your test session and the Billing report tab records the results of the validation attempts as partial CDRs are received. Look for the Partial Volume Success, Partial Volume Failed, Partial Time Success, and Partial Time Failed measurements.
In order to perform G-CDR validation, the CGF node must receive G-CDRs from the GGSN SUT and Landslide SGSN Data Records (S-LDRs) from the SGSN nodes in the GGSN Nodal test case.
CGF Node configuration — Add the SGSN peers, enable validation mode, and select the information to be validated.
Open your CGF Node test case.
Increase the Number of (Peer) SUTs to accommodate the number of SGSN nodes in your GGSN Nodal test case, and a numbered sub-tab is added for each SGSN.
Configure the new peer sub-tabs. Set the Transport, select Passive from the Initiate Mode list, and select Landslide SGSN for the record Type. If the Initiate Mode in sub-tab 1 (the GGSN) is set to Passive, check the Validate SUT box and select the GGSN's Ga interface from the Peer drop-down list. When both the GGSN and SGSNs are set to passive mode, at least one type of GSN must be validated. By validating the GGSN, you can avoid adding the SGSN nodes to the SUT database.
Ensure that Max Data Records will accommodate all PDP context activations that the GGSN Nodal test will attempt.
Select either Validation or Both from the Mode list. Both performs both the collection and validation functions and the test results will include all of the G-CDRs and S-LDRs. In Validation mode, only the G-CDRs that fail validation, and the corresponding S-LDRs, are included in the test results.
Click the CDR Validation button and use the settings in the CDR Validation window... to define the information that you wish to verify.
GGSN Nodal configuration — Enable S-LDR generation and define the SGSN node Ga interface.
Add the CGF node to the SUT database, ensuring that you use the same IP address defined in the test case.
Open your GGSN Nodal test case.
Check the Enable Billing box in the Billing sub-tab.
Set Initiate Mode to Active since the CGF node is in passive mode.
Configure the Transport setting to mirror the CGF node.
Select Landslide SGSN from the Type list.
Select your CGF Node from the drop-down list.
Select the GTP' Node sub-tab and define the Physical Interface and the IP Address for the SGSN node Ga interfaces. If your test includes more than one SGSN node, they will all share the same Ga address if you check the One GTP' Node Only checkbox in the Billing sub-tab. Otherwise, a separate node is created for each SGSN node, and the address that you entered is incremented for each node.
Run your test session and change the Report View to the GGSN Nodal test case. New measurements are available on the GTP', Billing, and GTP' Node tabs. Select the GTP' tab and you should see Node Alive requests sent by every SGSN node and an equivalent number of responses from the CGF node. When the GGSN Nodal test case deactivates a PDP context, when the test is stopping in this case, an S-LDR is sent to the CGF node. You should see Landslide SGSN Data Records counts on the Billing tab and corresponding Data Record Requests and Data Record Responses on the GTP' tab.
The CGF node validates G-CDRs when it has received both an S-LDR and a G-CDR for a context. Change the Report View to the CGF Node test case and look for Record Validation Attempts on the Billing tab. Record Validation Successes is incremented when a G-CDR passes validation and Record Validation Failures, along with other error counters, is incremented when a G-CDR fails validation. In the Data Record test results file, the "Record Status" for the Data Record includes the validation results.
|
TROUBLESHOOT:
|