About the Session Builder Tab

Test Case Table/Grid

You may view and edit parameters shared by multiple test cases in the table, with a column for each Test Case.

• Double-click on a row in the first column (parameter name) to display (popup) a vertical view of a single parameter across all viewed test cases.  

• Right-click on one or more selected rows (parameters) to display the following options:

You may Validate and Save any changes you made or Cancel, as required.

The test cases included in the session listed in a grid identifies:

Added a Notes section to the Session Builder Tab. Click on Notes for a Pop-Up window where up to 10K character size can be input and saved successfully. Tcl API "Notes" and REST API: "notes" are supported.

Cross-Reference

Use Cross-Reference to display/view Test Case Parameters shared by test cases in a test session. You may also duplicate tabs, apply auto-increment values across test cases, adjust all numerical values, apply values from other test cases to your selection, and add selection to Favorite tab. The XREF - Test Session window displays relevant test case tabs (e.g., interface tab, network devices tab, test activity tab, configuration tab, and so on) in a table format.

Use Reserve Processes to enable and assign each Group to a particular TS virtual process (for any multiple Groups of Test Cases using the same PHYs). Click Assign to virtually assign processes for your tests.

Use Traffic Mixer to build a Test Session level traffic mixer that will combine all the Data Profiles from each Test Case (TC) with a Data Profile into one master table of DMFs. Not all DMF protocols are supported by the Traffic Mixer. See this table of all DMFs and their attributes related to Traffic Mixer function and unsupported DMFs are in bold:

When the use clicks the “Traffic Mixer” button, if the Test Session contains any Network Host Test Cases, they will given these options: Client Side Only, Network Host TCs only or Both. When you have both sides in the Traffic Mixer, the data will be double, since it will be showing full traffic Tx/Rx from both sides. If you do attempt to configure the mix with both sides in the Traffic Mixer, remember everything is double. A recommendation is to work each side separately, or even just focus on Client side, save the Data Profile(s) for each Client TC that match up with each Network Host TC and just open the Data Profiles into those NH TCs.    

Definitions of rows in Traffic Mixer

The left column provides enumerated indication of what the row represents.   There are several different row types:

• Total -  The Total values for entire Test (all TCs added up)
• AVG  - The AVG UE values across entire Test. Total row divided by number of UEs in the test.  This is an AVG since each TC’s UE may run different mix. With Test Session view, each TC can have different number of UEs and different Totals.
• N-TSX:TCY  - Test Case total rows, where N is the unique Index of the TC instance within the traffic mixer and TSX:TCY is the standard Test Session identification.
•    DMF/Library/Name column= “Test Case Totals for N MNs” – Totals for a single Test Case (same as if you opened Traffic Mixer in the Test Case Editor) 
•    DMF/Library/Name column= “Per-MN Totals” – Totals for a single Test Case (same as if you opened Traffic Mixer in the Test Case Editor)
• N-X-Y – DMF specific row, where N is the TC Index, X is the Unique DMF Index within the TC, and Y is the DMF mainline index.  If you have extra Instances they can be Identified.  4-5-5 means the 4th TC in the mixer, 5th DMF instance which is the 5th Mainflow in the Profile.   The DMF/Library/Name will provide the indication of which Mainflow it is, correlated by N and Y.    

If subflows are involved :

• When you edit the cells in the top two rows, the mixer will adjust all the rates of all the DMFs to maintain the same AVG mix but increase or decrease the overall throughput.  The same as when you slide the Tx and Rx bar.
• When you edit the cells one of the two Test Case total rows, the mixer will adjust the rates of all the DMFs within that TC to maintain the Per-MN mix but increase or decrease the TC throughput, and this would also be reflected in the Total and AVG rows at the top.   Changing the TC totals can cause a change to the overall mix if each TC is doing a different Mix.
• When you edit the cells in one of the DMF rows, the mixer will recalculate the total values for the TC hosting the DMF and then the Total and AVG rows at the top.
   

See topics Traffic Rates/Mix and Data Traffic Tab for Test Case specific Traffic Mix.

Use Mobility Events to chart Events per Second from the steps defined in the Command Sequencer window. The Mobility Events button appears on Session Builder tab only if the test case uses Sequencer test activity.

For example, a sequencer test that Activates Dedicated Bearers, Modifies Default Bearers, Modifies Dedicated Bearers and Deactivates Dedicated Bearers. There need not be Mobility in the test.

This an example of a sequencer test that does S1 Handover and Tau Handover.

When licensed for CloudSure into Landslide, the CS Impairment checkbox provides the ability to delete PODs in a Kubernetes cluster, while running a Test Sessions.

From within a Test Session you can configure a CloudSure Profile which is the equivalent of a CloudSure TestCase, that only supports POD Delete by Count or Percentage of a set of Deployments or StatefulSets.

In order to run a test in CloudSure the test must first be saved. The TAS will use a base template of a CloudSure TestCase that can do POD Deletes and apply the configuration details stored in the CloudSure Test Profile.   The CS TestCase is temporary and we will give it a standard name "RID-<NNNN> Landslide Impairment". As part of final test cleanup, we will always delete the TestCase from CS. Since only one TAS will control one CS system, and since RID is unique at any given time, using RID-NNNN in the name will provide 100% uniqueness.

When a Test Session is started, the CloudSure Profile will be re-validated, querying CloudSure to make sure the configuration is still valid. Additionally if the profile is using the Delete Mode=Count, the TAS will query CloudSure to determine how many PODs are in the selected Workloads and the validation will fail unless the number of PODs >= the Delete Count.
In workloads response, we look for deployment_name, and replicas inside status to get a total number of PODs for a given list of Workloads:

{"type":"ReplicaSet","name":"open5gs-amf-db4b4c475","namespace":"csadmin","environment":"project-cloudsure-test","creation_timestamp":"2024-05-14T20:27:33Z",
"status":{"available_replicas":1,"fully_labeled_replicas":1,"observed_generation":1,"ready_replicas":1,"replicas":1},
"annotations":{"deployment.kubernetes.io/desired-replicas":"1","deployment.kubernetes.io/max-replicas":"2","deployment.kubernetes.io/revision":"1","meta.helm.sh/release-name":"open5gs","meta.helm.sh/release-namespace":"csadmin"},
"labels":{"app.kubernetes.io/instance":"open5gs","app.kubernetes.io/managed-by":"Helm","app.kubernetes.io/name":"amf","helm.sh/chart":"amf-2.1.0","pod-template-hash":"db4b4c475"},
"deployment_name":"open5gs-amf"}

If validation is successful the Test Session will be allowed to start.

Two modes are offered, Manual and Automatic.

• With Manual, once you start the test, the Start button will enable and let you choose when to start CloudSure.
• With Automatic, the CloudSure will be started as soon as the Test Session reaches the RUNNING state. This means if you are using Automation Control Steps you will need to make sure to leave the test running so steps can complete and the test can reach RUNNING state.  NOTE: The ability to add a Step in automation control is expected very soon.

The TAS will connect one single CloudSure endpoint and login with one username global to they system, app to app.

When you execute CloudSure, the only feedback you get is in the Run Log, where the is a log when starting CloudSure and then querying status shows three details, the Status, the Results, and the Message. They are only reported when one of them changes.

In this example the CloudSure Impairment worked and did not report any issues.

Currently API supports configuring things, but you cannot manually start CS from API.
 

Setup:
License is required.

CloudSure must be setup with: The User, Organization, Project, Cluster Profile (new CS feature, if ready in time), Environment Profile, Credential Manager.

Setup CloudSure with the required settings:
Landslide will use the Default Organization
Landslide will expect a project named “landslide”, create that project
Landslide will expect a dedicated username/password.
Configure the TAS Settings to connect with CloudSure:

CloudSure global settings will be via TAS Settings for now:

aion_endpoint   http://10.71.20.12:37022  --  
cs_endpoint http://foo.bar:32442/
cs_email_username  [email protected]
cs_password  Password12!
For example on the CLI:
set-tas-setting cs_email_username "[email protected]"
set-tas-setting cs_password "Like I would tell you"
set-tas-setting aion_endpoint "http://notreally.com:32277/"
set-tas-setting cs_endpoint "http://notreally.com:32442/"
 

Use the right-click options on a test case to display a drop-down list with these options: