The GGSN Nodal test case tests a GGSN's capability to service MNs in a simulated GPRS network. This topic will guide you through configuring and running a basic Capacity Test, and then expanding the basic test with the optional behaviors available in the test case.
After you have a functioning test session, you can build tests using other test activities and options:
CDR Generation (GGSN G-CDR Validation feature required)
You can also test a GGSN in a VPN or VPRN configuration:
Using IPSec (Dynamic IPSec feature required)
You should have a basic understanding of the test system:
Prepare the system and gather information about the SUT
Add the SUT to the database if necessary
The GGSN SUT's GTP requirements
To configure a GGSN Nodal Capacity test:
The goal for the first test is to establish one PDP context with the GGSN to confirm the test case definition, then to successfully execute the test with increased rates and multiple sessions, and finally, to customize the more advanced protocol, MN, and test case behaviors.
Create a new test session... and add a GGSN Nodal test case... from the Basic library. The Test Case Settings window... opens to the Test Configuration tab.
Test Configuration Tab — Select PDP Type, Number of MS, Primary PDP Contexts, Activation Rate, and Deactivation Rate
Network Devices Tab — Identify the SUT and define the SGSN emulator
On the Network Devices tab, select the GGSN SUT.
Define one SGSN emulator on the Control Node sub-tab. Select a Physical Interface and configure the Ethernet settings.
GTP Node Parameters — Define the GTP interface between the SGSN node and the SUT
Select the GTP Node tab.
Select the GTP Version... that will be used by the SGSN node, and the parameters applicable to the version are enabled.
The combination of Starting IMSI... and Starting NSAPI... uniquely identifies a PDP context. A unique IMSI value is provisioned for each Mobile Subscriber, and NSAPI increments for each PDP context associated with a subscriber. Configure the Starting IMSI to produce a range of values acceptable to the SUT.
Confirm the GGSN and SGSN GTP Ports...
Selection Mode... can determine whether APN access is permitted. Configure a value that is compatible with the SUT.
Configure the ISDN attributes: MS ISDN Nature of Address..., MS ISDN Numbering Plan Indicator..., and Starting MS ISDN Number... The ISDN number is incremented for each Mobile Subscriber. Configure the starting value to produce a range of values acceptable to the SUT.
Starting Access Point Name... can be provisioned to provide a unique APN for each primary PDP context associated with a subscriber. Use the Auto-Increment feature to configure unique APNs.
Define the QOS Profile.
If RAI is required by the SUT, check the Include Routing Area Identity Code... and define the information elements.
GTP-V1 Parameters — If you selected GTP-V1, define the following attributes as required by the SUT.
Complete the test case by configuring the PDP protocol.
IPV4/IPV6 Parameters — Define the PDP address and Protocol Configuration Option (PCO)
Accept the Dynamic selection in PDP Address Type.
Configure the Protocol Configuration Options required by the SUT.
PPP Parameters — Define the synchronization mode, control protocol, and authentication
Modify the default Magic Number... if necessary. You can provision hex or decimal values.
If the SUT requires that authentication is performed, select the Authorization type and configure the User Name and Password... The Auto-Increment feature gives you the ability to provision a unique User Name for each MN.
Configure the AAA server that the SUT will use for authentication to accept the range of names that the test will produce when multiple MNs are used.
Select the Synchronization Mode, and configure ACCM if you select Async.
Enable Van Jacobson Compression... if it is required and select a compression option.
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 a session. 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.
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. Ideally, your MN session is established and the Sessions Established, Attempted Session Connects, and Actual Session Connects measurements on the Test Summary tab are all 1. 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.
|
TROUBLESHOOT: If the MN session fails to connect, Attempted Session Connects will increment but no connections are recorded. Eventually, Session Errors will accumulate as the connection is retried. Common causes of session failures are connectivity problems and authentication failures. Create Request Timeouts on the GTP tab reports GTP connectivity problems. Confirm that the SUT address is correct, and that the address assigned to the SGSN node does not conflict with another device in the test network. You can also SSH to the test server as cfguser and ping the SUT. If Create Responses are being received, look at the GTP error counters for more information. |
Next, increase the PDP contexts and the test rates. Edit the test case... and set the PDP Context Connect Rate and PDP Context Disconnect Rate to 10. Set the Number of Mobile Nodes (Mobile Node tab) to 20 and Number of Primary PDP Contexts per MS (GTP tab) to 5, which will result in 100 total PDP contexts.
OK the change, and Run the test session again. This time you should be able to see the MN sessions establish over 10 seconds (10 PDP contexts each second).
|
TROUBLESHOOT: If all of the MN sessions fail to establish, Attempted Session Connects will be larger than Actual Session Connects and Sessions Established. The most likely reason is a problem with parameter values that increment for each MN session:
|
NOTE: Sometimes, when running a GGSN Nodal test with 1 MN set at high Activation Rate (i.e., 1000/second), Data traffic does not start. It is recommended that you use the following settings:
|
Finally, customize the optional behaviors to tailor the test to your purpose.
General options:
You can apply a distribution model to vary the activation and deactivation rates with Advanced Settings... on the Mobile Subscriber pane of Test Configuration tab.
You can introduce errors in an Ethernet SGSN node using the Advanced... options on the Network Devices>Control Node sub-tab.
Use separate interfaces for control and bearer plane traffic by enabling a User Node.
GTP options:
IPV4/IPV6 options:
PPP options:
Error Inject... (with asynchronous PPP)
After you have finished the definition and successfully tested it, save the test case and the test session as "GGSN Base" or something similar.
Continue building your standard tests with other test activities or Data Traffic, and then try combining multiple test cases in one test session using linked test cases and Automation Control.
Three types of VPN access models are supported with GPRS: IPSec, L2TP, and VPRN. After you have successfully built and run a basic GGSN Nodal test, you can configure it for any of the supported models.
IPSec VPN
Add Data Traffic to the test and use Data IPSec to encrypt the traffic. This option is also supported with L2TP VPN configurations.
L2TP VPN — Define a Security Gateway emulator, the PDP context addresses, and the L2TP and PPP/L2TP settings
On the General tab, check the Security Gateway box (just under the Test Activity pane). The PPP-L2TP and L2TP tabs are added to the test case, and the remaining L2TP VPN settings are enabled.
Select the Security Gateway sub-tab and define a gateway node.
In an L2TP VPN, the Security Gateway assigns IP addresses to the PDP contexts. Define the address pool in Starting IP Pool Address... on the Mobile Node sub-tab.
Select the PDP tab and ensure that the PDP Type is set to PPP. These parameters define the PPP session that terminates on the GGSN's Gn interface (see the basic instructions above for this PPP configuration).
Select the PPP-L2TP tab and configure the PPP sessions that will be set up between the GGSN's Gi interface and the Security Gateway through the L2TP tunnel. The Magic Number must be different that the one used on the PPP tab.
Select the L2TP tab and define the Security Gateway end of the L2TP tunnel.
Confirm that the SUT L2TP Port Number is compatible with the SUT, and modify it if necessary.
If authentication is used, check the Enable Tunnel Authentication box and enter a Password. When challenge-response authentication is used, check the Require Authentication box and set the Send Challenge Size.
Complete the L2TP definition by defining the following parameters according to the provisioning of the GGSN SUT that terminates the L2TP tunnel:
VPRN — Add a GGSN LAC to an L2TP VPN test
Configure an L2TP VPN test following the instructions above.
Select the General tab and check the L2TP box in the System Under Test pane. Select the LAC SUT from the drop-down list. The PDP contexts will be established with the GGSN SUT and the L2TP tunnel will be terminated by the L2TP SUT.
When you run the test, additional measurement tabs are available depending on the protocols used:
IPSec records IKE Phase I and Phase II activity.
L2TP records L2TP tunnel and L2TP session activity.
L2TP Node displays the throughput measurements for the Security Gateway.
If a Billing sub-tab is displayed under the Gal tab of the test case, the SGSN nodes can generate CDRs towards a CGF. If your test includes a physical CGF, the SGSN nodes can generate S-CDRs. If the test includes a CGF Node test case, the SGSN nodes can generate S-LDRs that are used by the CGF node to validate the G-CDRs received from the GGSN SUT.
Follow the instructions in the G-CDR Validation section of Setting Up a CGF Node to configure the Billing settings. To generate S-CDRs rather than S-LDRs, select SGSN rather than Landslide SGSN from the Type drop-down list.