Parameter Features

The test system supports alternative formats that you can use when entering certain types of values. Some parameters also support methods that produce unique values based on a template that you define or can obtain values from an imported file, and others allow you to modify values while the test is running.

This topic explains the different ways in which you can define and modify parameter values:

General Formats and Values
Auto-Increment
Test Data Files
Updating Parameters on a Running Test
Context-Sensitive Help
Execute Tcl API Function

General Formats and Values

IPv4 Network masks can be entered in either decimal (255.255.255.255) or bit (/9) notations.

NOTE: IP formatted AVPs/VSAs are not validated. Also, Landslide does not support CIDR /masks less than /9 (/8 is invalid).

When an integer value is required and the field is not limited to a range of values, you can enter either decimal (128) or hexadecimal (0x80) values.

NOTE: Hex can be used in place of an integer that represents a numeric value, but not when decimal numbers are used as a string, such as in an ID.

String values are not checked for length or content. If the string entered exceeds the field's character limit, the string is truncated. The content of a string is not validated in order to allow you to inject errors by purposely using an invalid value or format.

^ Back to Top

Auto-Increment

Certain parameters require that a unique value is provisioned for each session. The test system accomplishes this through a feature that generates a sequentially incrementing value that is embedded within the parameter value. You define the base parameter value and the placement of the incrementing value, and can either define the starting point for the incremental value or let the test system choose a default starting value. If non-sequential values are desired, most test cases support the use of Test Data Files to provision parameters.

1) There are several variations in the way Landslide supports auto-incrementing parameter values. Check the details about the specific Test Case Parameter to know if it supports auto-incrementing and which format it uses.

2) See Parameter Auto-Increment Format Wizard for the newest standard way. Parameters that support this syntax usually have a “Wizard Button” , or a tooltip will indicate the details.

Certain test case parameters can activate the Auto-Increment feature by using a special format in the parameter value. (Legacy format)

A normal string value — sometext — generates the same value for every session.
If the first character in the base string is "@," the base string is appended to a generated string — spcoastn — where n is incremented for every session. The starting point for n depends on which parameter uses the value. The base string @sometext produces the incremental values spcoast1@sometext, spcoast2@sometext, etc.
When "#" is included in the base string — somete#xt, somename#@sometext, or somename@some#text — it is replaced by an incrementing value. The starting point for the increment depends on which parameter uses the value. The base string somete#xt produces the incremental values somete1xt, somete2xt, etc.
When "#(nnn)" is included in the base string — somete#(nnn)xt, somename#(nnn)@sometext, or somename@some#(nnn)text — it is replaced by an incrementing value that starts with nnn. The base string somename@some#(123)text produces the incremental values somename@some123text, somename@some124text, etc.

In the AAA Server Nodal and AAA Server Node test cases, an incrementing IP address in the format #(n.n.n.n) or an incrementing number in the format #(nnn) can be used as a User Name. A starting value of #(10.1.1.1), for example will produce 10.1.1.1, 10.1.1.2 ... 10.1.1.254, 10.1.2.1, 10.1.2.2, etc. A starting value of #(9990000000) will produce 9990000000, 9990000001, 9990000002, etc.

In HNB IPSec testing, the range indicators for the Starting IP and Ending IP addresses support auto increment for certain IP addresses by allowing you to enter a + next to the IP address on the IPSec>Tunnels> Advanced window.

NOTE: The increment flag (#) can be placed at any position in the base string, but only one flag per string is permitted.

You may also include the # character a string. For example:

User##(N0) to result in User #0, User#1, User#2, User#3, etc.
User/##(123) should result in User#123, User#124, User#125, etc.

3. Some fields, for example, TAC and Alternate TAC fields in MME Nodal testing with value 0-65535, are padded to 5 digits. the padding and the minimum/maximum values are not the common pattern for integer fields with auto-increment option. Some integer fields with auto-increment option may not be padded and may have different minimum and maximum values.

When integer fields support auto-increment option — "#(nnnnn) or #(nnnnn R/I)
- N is padded integer, 00000 to 65535 (Starting TAC)
- R is integer 0-99, # of Repeated Values
- I is integer -9 to 99, Increment.

See an exampleexample of the usage.

Padded Integer (nnnnn):

12345---->12345,12345,...

Repeated Values (0 - 99) - #(nnnnn):

#(12345)---->12345,12346,....

Increment - #(nnnnn R/I):

#(12345 0/0)=12345

#(12345 0/1)=#(12345)

#(12345 1/1)=#(12345)

#(12345 1/2)--->12345,12347,....

#(12345 2/2)--->12345,12345,12347,12347,....

#(12345 1/-1)--->12345,12344,12343,12342,....

#(12345 2/-1)--->12345,12345,12344,12344,....

You can use Auto-Increment to generate unique values for the following parameters:

Note: This is not a complete list.

^ Back to Top

Test Data Files

Test Data Files (TDFs) provide a generic way to support any type of user-provided file needed for testing. TDFs may come in many forms, but they tend to fall into a few different categories:

TDF-CSV Files for defining unique test case parameter values across each UE, Bearer/PDU/Context, eNodeB/gNodeB, DMF, etc…
Media files for user plane
Security files such as private keys, public keys, and certificates
Configurations of complicated features, devices, servers, such as DNS or LDAP
Special Cases for internal use

The most common use of TDFs in Landslide is the TDF-CSV Files. Using TDF-CSV files you can provision unique, non-sequential values for some parameters. TDF-CSV files use a comma-separated value (CSV) format to identify the parameters that will be overridden. The TDF field names closely match the UI parameter label or Tcl variable name and the values usually will be the same Values/Formats/Ranges as the GUI or Tcl API entered value. However, there are some special cases where they do not match.

The Landslide UI typically uses auto-increment fields with consecutive values for parameters that must be different between emulated UEs (for e.g., IMSIs) and fixed/same values for all UEs for parameters that can be the same between UEs. Using a TDF-CSV allows for non-consecutive values for auto-increment fields and/or unique values per UE for fixed value parameters. In a TDF-CSV, each row defines the values for a single object. Most commonly, each row is a Session or UE, as mentioned, but they may be Bearers/PDUs, DMFs, eNodeBs/gNodeBs, Tunnels etc. Our UI will provide an indication:

Within a Test Case, a TDF-CSV Parameter would be most commonly be labeled as “Apply Test Data File to <NAME> Parameters” or “Apply Test Data File to <NAME OF PANEL>”:

TDF-CSV Parameters provide an option to Generate a Stub CSV file:

The stub would contain every field/column possible to override. This same stub would also be provided to the TDF-CSV Editor to provide automatic column selection and management.

TDF-CSV files are also identified by a unique ID:

TDF-CSV files have a defined set of columns (or fields) that are expected and possible, but individually not required. Only the fields associated with the parameters to be uniquely overridden need to be included. The value in the GUI will be the default value unless overridden by the TDF-CSV.

TDF-CSV files also support auto-incrementing, such that one row in the file can represent many objects, expanded at runtime by the TS. See About Auto-Incrementing Groups.

Examples for most TDF-CSV files are provided at Example TDF-CSV Files.

For other categories of TDFs the TDF parameter will usually just indicate the file types expected:

For cases when a CSV file is expected, but it is not a TDF-CSV file, you will see the option to launch a generic version of the Standalone TDF-CSV Editor, but no Stub file Generated and not the built-in TDF-CSV Editor:

This implies that you are on your own to know the content/format of the file. Clicking F1 should bring you to documentation that provides the details.

For all TDF Parameters that support csv format, there will always be an option to Select/Create a TDF on TAS.

For all TDF Parameter types, there will always be an option to Upload a TDF to the TAS.

Managing Test Data Files – Manage Test Data Files outside the context of Test Cases
Test Data Files – Sample files
About The TDF-CSV Editor – How to use the TDF-CSV Editor

TIPS:

Use TDF-CSV Editor to edit your TDF-CSV files with wizards and column selectors and Auto-Incrementing Groups.
Both parameter names and values are case-sensitive.
The file can contain only the parameters that will be provisioned from the file. The test case setting will be used unless a parameter in included in the file.
Provision a parameter value from the test case setting rather than the file by leaving an empty string for that row/column, e.g. value,,value.

^ Back to Top

Updating Parameters on a Running Test

You can change the value of some rate and time parameters while a test is running. Changes to test case parameters take affect when you click Apply or OK the test case. Changes to a DMF Transaction Rate are applied when you commit the change; the test case can remain open or can be closed with a Cancel.

To change parameters in on a running test:

Edit the test case...

NOTES:

Only parameters that can be changed during the test are enabled while the test is running. The parameters that cannot be changed are disabled (gray).
If the test completes before you commit the changes, the changes are discarded.

Data Tuning allows adjusting of connected UEs and Data Rates, see Data Tuning Manual.

The following parameters support changes parameters on a running test:

Activation Rate Deactivation Rate	On Mobile Subscriber pane	All test cases
Start Rate Disconnect Rate	On Mobile Subscriber pane	Test Cases not using Sequencer or Command Mode Test Case has been initialized
Mobility Rate	Test Activity Settings - Test Cases using mobility Test Case has been initialized	Handoff Test Cases
Session Loading Parameters IdleTime HoldTime	Test Cases using session loading Anytime	Session Loading
Traffic Rate	Mainflow and subflow DMFs Anytime: Paused Mainflow DMFs Test Case is in RUNNING state loopCount Mainflow DMFs DMF is Paused	All test cases
Set UE % and Set % (See Traffic Mixer)	On the Traffic Mixer pane.	All test cases

On Interface tabs

Restart Counter	GTP tab
Short Data Burst	RP tab
Operator Determine Barring Aggregate Maximum Bit Rate (PDN Context pane) ARP Value (Quality of Service pane) Traffic Class	HSS Server tab	Available in HSS Node test case, during execution provided you have selected/defined these parameters before execution.
QoS Class	HSS Server \| PDN Contexts tab
Number of UE per Mobile	PGW Nodal \| Mobile Subscriber pane	Available in PGW Nodal test case, during execution provided you have selected/defined these parameters before execution.
Number of Prefixes MN-NAI Extension	PGW Nodal \| Pi-MIP tab Disable MN-NAI Extension (if selected)
Multiple SUTs	PGW Nodal \| Network Devices tab (if selected)

Tcl API Reference

Tcl API Reference guide - Landslide Tcl API Object and Perform Function Reference

Update

This function updates up to three (3) dynamic parameters for a running test. The update function only changes the parameter(s) on the TAS and test servers where the test is running. It will not affect the local parameters, i.e. that you would query using ls::get . If you want to change the local parameters, you must use ls::config, and this only affects local parameters, not the running test.

There are only a few parameters that can be modified when a test is running. For test cases, this includes the StartRate, DisconnectRate, MobilityRate, IdleTime, and HoldTime. For DMFs, you can only change the Transaction Rate; you do this via the TrafficRate variable. You can also Pause/Resume mainflow DMFs by setting the Paused variable to true or false appropriately. You can change the TotalTransactions of mainflow DMFs by setting the loopCount variable, but only when the DMF is Paused.

The update format matches that from the CLI API, where a tcl namespace, based on the test case and/or DMF instance, is used to identify the parameter: tsN::tcN::Dmf_N::subN::VARIABLE=VALUE.

Syntax

ls::perform Update [–TestSession TEST_SESSION_HANDLE | -RunId RUN_ID ] \

UPDATE1<</UPDATE2>/UPDATE3>

UPDATE format: tsX::tcY::Varname=Value, up to 10 parameters separated with /.

To change the ts0::tc1 test case's StartRate parameter and the Traffic Rate of the first subflow in the first DMF on the ts0::tc0 test case use "ts0::tc1::StartRate=55.5/ts0::tc0::Dmf_0::sub0::TrafficRate=2.0". To Pause/Start DMF traffic, you set the Paused variable, “ts0::tc0::Dmf_0::Paused=true” or “ts0::tc0::Dmf_0::Paused=false”

List of the most common updatable parameters:

Parameter	Applies to	Can be Modified When
tsX::tcY::StartRate	Test Cases not using Sequencer or Command Mode	Test Case has been initialized
tsX::tcY::DisconnectRate	Test Cases not using Sequencer or Command Mode	Test Case has been initialized
tsX::tcY::MobilityRate	Test Cases using mobility	Test Case has been initialized
tsX::tcY::IdleTime	Test Cases using session loading	Anytime
tsX::tcY::HoldTime	Test Cases using session loading	Anytime
tsX::tcY::Dmf_Z::TrafficRate txX::tcY::Dmf_Z::subA::TrafficRate	Mainflow and subflow DMFs	Anytime
tsX::tcY::Dmf_Z::Paused	Mainflow DMFs	Test Case is in RUNNING state
tsX::tcY::Dmf_Z::loopCount	Mainflow DMFs	DMF is Paused

^ Back to Top

Context-Sensitive Help

Context-sensitive Help is available for test case parameters.

F1: Select a parameter and press F1 to display the Help topic for that parameter. If you press F1 when a parameter is not selected, the main index for the test case is displayed. If a parameter level help is not available, then the relevant tab-level help will be displayed.

F2: Select a parameter and press F2 to display the Tcl Variable name for that parameter in a pop-up window.

Pop-up blockers must be disabled or the TAS IP address must be added to your "allowed" list in order to use context-sensitive Help. A Help button is also displayed in each test case. Click the button to display the main index for the test case.

^ Back to Top

Execute Tcl API Function

The Perform function executes an API function. See the Perform function under Global Commands and Perform Functions section of the Landslide Tcl API Object and Perform Function Reference for list of functions and their details.

^ Back to Top