The DCCA Server Nodal test case tests a server's capability to provide Diameter Credit Control services to a 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:
You should have a basic understanding of the test system:
Prepare the system and gather information about the SUT:
Add at least one SUT to the database if necessary
The DCCA SUT's AVP requirements
To configure a DCCA Server Nodal Capacity test:
The goal for the first test is to establish one credit session to confirm the test case definition, then to successfully execute the test with increased rates and multiple MNs.
Create a new test session... and add a DCCA Server Nodal test case... from the Basic library. The Test Case Settings window... opens to the General tab.
General Parameters — Define the NAS emulator and select the SUT
Define one Client emulator on the Client Node sub-tab. Select a Physical Interface and the first address in the pool is provisioned in Starting IP Address.
Select the DCCA tab.
In the default configuration, one SUT may be tested. Select the SUT from the IP drop-down list in the Dedicated SUTs pane.
Enter the fully-qualified Host... name of the SUT and the Realm... serviced by the SUT.
Diameter Parameters — Define the attributes that will be included in all Diameter messages in the Diameter Tab.
Modify the default Product Name if you like. The name is normally assigned by a vendor and the SUT should accept any value.
Accept the default Application ID as it is correct for DCCA.
Enter an Origin Realm... and Origin Host... for the Client node that will be acceptable to the SUT.
Modify the Vendor ID... if necessary.
If the SUT requires that IPSec is used, check the IPSec box and configure the parameters on the DCCA IPSec tab following the instructions in Adding IPSec to a Test.
Credit Control Parameters — Configure the credit request and usage reporting options.
On the MSCC 1 sub-tab, enter the Rating Group... for the credit service.
By default, update CCR messages will be sent according to the value in the Validity-Time AVP received from the server. You can clear the Use Server Validity Time box and specify the interval for update message with Update Time Interval...
Credit usage can be reported by time units, volume units, or both with the Report Time Quota... and Report Volume Quota... checkboxes. When you check one of the boxes, you can define the usage reported in every update CCR.
In the Miscellaneous Options pane, define the remaining test case parameters.
One or more Subscription-Id AVPs can be included with the Include MSISDN and Include IMSI... checkboxes.
Enter a Service Context ID... that will be acceptable to the SUT.
If the SUT requires the User-Name AVP, check the User Name box. When you enter the value, use an Auto-Increment format that will produce names acceptable to the SUT in a test with multiple sessions.
Add any other attributes required by the SUT to the AVP Configuration. Click the View/Edit button in the DCCA Client pane and follow the instructions in Using Optional Attributes.
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, the Client is connected to the SUT and your MN session is established. The Sessions Established, Attempted Session Connects, and Actual Session Connects measurements on the Test Summary tab should all show 1, as should Capabilities Exchange Request Sent, Capabilities Exchange Answer Received, and Number of Sockets on the Diameter DCCA Node tab. The DCCA tab shows the number and type of Credit Control messages sent and received, and Granted Octets, Used Octets, Granted Time, and Used Time report the amount of credit granted and usage reported by unit type. Explore the measurements displayed on the other 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 cannot be established, Sessions Pending will continue to display 1. Common causes of session failures are connectivity problems and authentication failures. If you are using IPSec, check the IPSec report tab for errors. Socket ACK Timeouts on the Diameter DCCA Node tab can indicate connectivity problems. Confirm that the SUT address is correct, and that the address assigned to the Client node does not conflict with another device in the test network. If connectivity is not a problem but Capabilities Exchange Answer Timeouts are reported, check Invalid Messages. A count there indicates that the test is not able to interpret messages from the SUT. The SUT may be rejecting requests from the Client node because it does not recognize either the client or MN credentials or because it is otherwise unable to handle the requests. Look for error result codes on the DCCA tab and correct client or MN identifiers as necessary. |
Next, increase number of MNs and the test rates. Edit the test case..., set the Number of Mobile Nodes to 100, and set the Activation Rate and Deactivation Rate to 10.
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 sessions 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 incrementing user credentials. |
Finally, customize the optional behaviors to tailor the test to your purpose.
Apply a distribution model to vary the activation and deactivation rates with the Advanced settings on the Mobile Node sub-tab.
Inject errors with the Advanced settings on the Client Node sub-tab.
Set the Client node's default failure handling mode with CCF-Handling...
Adjust the Watchdog Time...
Include a second Requested-Service-Unit AVP with the Request Service Unit at Message Level checkbox.
After you have finished the definition and successfully tested it, save the test case and the test session as "DCCA Base" or something similar.
Continue building your standard tests with other test activities and then try combining multiple test cases in one test session using linked test cases and Automation Control.
To test multiple DCCA devices:
A DCCA test can use one of two ways to select the SUT that will be requested to service an MN: dedicated or round-robin.
In dedicated mode the SUTs are defined in the Dedicated SUTs pane. All traffic is sent directly to the Primary SUT by default. You can configure the test to test up to four devices, two servers and two proxies, with the options in the Dedicated SUTs... drop-down list. When the configuration includes a primary and secondary device, the Secondary fields are enabled. If one or more proxies are included in the test, select the proxy in the IP drop-down list and enter the server's FQDN in the Host field. In order for secondary devices to be utilized, failover must be enabled by default with Default Failover... or with the CCSF AVP from the SUT. In the case of transport failure, CCFH must also support the use of a secondary device. See About Diameter Testing for more information about failover processing and the interaction with the Tx and Tw timers.
In round-robin mode, all traffic for an MN is sent to a SUT selected from a pool of SUTs defined in the SUT Pool for Round-Robin pane. To configure a round-robin test, set DCCA Distribution Mode... to Round-Robin. The SUT Pool pane is enabled and the Dedicated SUTs pane is disabled. Select the Number of DCCA Servers in Pool and a separate, numbered sub-tab is displayed for each SUT. Select a SUT from the drop-down list and define the Host and Realm on each sub-tab.