Ue Criterion Editor


You can view/add/edit a criterion on the View/Edit Criterion Condition window by clicking the Add or Edit button from the Info tab (End Of Test Criteria). A Criterion defines a condition to check. You can specify up to four conditions listed below (If Field, For UE (Index), For Bearer (Index) and For UEs with Field ) and when to check the condition and what to indicate when the condition is true.

The "If Field" is the MAIN Condition that is checked and the three other fields are qualifiers. The qualifiers help to determine when the MAIN condition is checked.

NOTE: For UE Info Criteria to work properly, UE Info monitoring must be enabled, UE Info Level should be set to 10 on Test Server Configuration (or less if you know which fields are produced). Your TS/Test case will not produce UE info unless your TS UE Info Level is > 1. It can range from 1 to 10. 10 shows all possible values but it has the biggest impact on TS performance.

 

The following are the main components of the View/Edit Criterion Condition window:

The information/parameters displayed on the View/Edit Criterion Condition depends on the options you select from the various dropdown lists.


Result Type

Each Criterion has a Result Type that determines which state should be indicated if the condition is true.  The Result Types are PASS, FAIL and LOG, where the true states are PASSED, FAILED, and OCCURRED respectively and the false states are FAILED, PASSED and PENDING.

This Result Type Machine is:

^ Back to Top


If Field

The main condition is IF FIELD ( ==, !=, >, ≥, ≤, <, matches)  VALUE, this correlates to a row in the info report file.  

The "matches" operator checks for Regular Expression Match.  Vs == which is an exact EQUAL.

Additional information about Regular Expression can be found on these websites.

The >, <, ≥, ≤ operators are mathematical in nature and will not work on String values thus you must use an Integer value for the comparison.

The operator can be one of the following: >, >=, ==, !=, <, or <=, matches, in_subnet

in_subnet/IN_SUBNET will let the user fill out an IP-Address/CIDR to define a subnet. When the TAS attempts to evaluate the criterion, it will part the info_report field value into an IP Address and check if that address falls within the subnet defined by the user. If the value is not an IP Address, or not in the range, the criteria condition will be marked false and the Criterion status will be updated accordingly based on its type. Additionally we will report a new VALUE_TYPE to the TEST.CRIT file, of "IP-Address" to indicate that the TAS expects the value to be an IP-Address.

When using the "in_subnet" operator, the user can provide a Subnet definition as IP/CIDR. Matching if they are in the Subnet. If the IP-Address is in the middle of a subnet defined by the CIDR, the TAS still considers the entire subnet, it will not treat the IP-Address as a "Starting-IP-Address".  If you define the 5th IP Address in the subnet, the TAS will still treat the first four IP Addresses in the subnet as a true match. For IPv4 addresses, the network (.0) and broadcast addresses (.255) will also match.

Example:

If any UE-Bearer reports a PGW_IP == 2.2.2.2, PASS.

^ Back to Top


For UE (Index) or For Bearer (Index)

The For UE (Index) or For Bearer (Index) ( ==, !=, >, ≥, ≤, <)  VALUE, this correlates to specific UEs or UE Bearers.

  

The operator can be one of the following: >, >=, ==, !=, <, or <=

Example:

If you wanted to only check that at least one of the 5th or later UEs have an IMSI that starts with 554433:

If you wanted to check that ALL of the 5th or later UEs that have an IMSI that starts with 554422 you would negate that in a FAIL criteria:

FAIL if IMSI matches ^(?!554433.*$).* FOR UE ≥ 5  

^ Back to Top


For UEs with Field

The For UEs with Field ( ==, !=, >, ≥, ≤, <)  VALUE, this correlates to a row in the info report file.  

The "matches" operator checks for Regular Expression Match.  Vs == which is an exact EQUAL.

The >, <, ≥, ≤ operators are mathematical in nature and will not work on String values and you must use an Integer value for the comparison.

The operator can be one of the following: >, >=, ==, !=, <, or <=, matches

The "FOR UEs with Field" allows you to apply criteria to sets of UE-Bearers for that specific attribute. The Evaluator will make a first pass to store last reported value of each field for all UEs, then applies the FOR condition to filter those results, then applies the IF condition.

For example: If you only wanted to check that all UEs with an IP Address ending with .5 have a QCI of 5 on bearer 1, you might try this:

First the final values of all fields for each UE-Bearer are recorded, then a first-pass filter checks for all UE-Bearers with UE_IP ending with ".5", of those, if one is found having a QCI != 5, the Criteria will FAIL.

The "." is any character, so be careful when doing IPv4 Address matches… To find an IP address in the 10.71. network, use 10[.]71[.].*

NOTEs:

  • For checking that ALL UEs have a value, you should use a "FAIL" to check for the NOT condition.  It will FAIL on first occurrence (of bad condition), and PASS if none are met.
  • For checking that ANY UE has a value, you should use a "PASS" type to check for the condition.  It will PASS on first occurrence (of good condition), and FAIL if none are met.
  • We do not check for "ALL" and we do not check that the UE even had BEARER index 1.  If the Test did not report any QCI values, this Criteria would PASS.
  • The logic for the "For Fields" (For UE, For Bearer, etc.) is to check all reported values, not just the last.  
  • If the "In Field" has a value that has the name "STATE" in it, then all values are checked otherwise just the last.
  • The "matches" is just a plain String REGEX, UE Info Criteria does not know the context of your values, it does not do IP Address comparisons or ENUMs, etc. Fields are not context/units/types specific, they are treated as just STRINGS or NUMBERS.  

 

^ Back to Top


Condition Preview

The Condition Preview displays the Criterion that is being generated. See example:

Example of :

Content of info_report.csv File: The "Fields" are  ECGI, GUMMEI, STATE, IMSI, etc… shown under the COLCHANGED column. The "Field" is the "COLCHANGED" value.

UE_IDX,DEF_BC_IDX,LOGTIME,COLCHANGED,COLVALUE

1,1, 14:33:18.254596,STATE,ATTACH REQUEST

1,1, 14:33:18.254635,IMSI,505024101215074

1,1, 14:33:18.254639,IMEISV,5050241012150700

1,1, 14:33:18.254643,MME_IP,10.202.4.1

1,1, 14:33:18.254647,ECGI,000.000.1

1,1, 14:33:18.254652,GUMMEI,000.000.ff.ffff

The COLCHANGED fields in the info_report.csv needs to be used if they differ from the GUI drop-down. For example the drop-down POLQA_AVG, needs to be POLQA_AVG_1 to check the call IDX
When using UE(index), the value is in the UE_IDX column of the info_report.csv : 

^ Back to Top


Tcl API and RESTful API:

This is available via Tcl API.  The Tc object now has a UeInfoCriteria child object. Always have the ue_info_criteria.csv file to check and the run log.

From RESTful API, when the test ends you can get the Run Log, …info_report.txt, and …ue_info_criteria.csv file, which will all be listed in the "result files" of the completed test session. Also in the test session object, the Overall Criteria State will be indicated, but there is currently no way to natively retrieve the UE Info related items from Rest FULL API on Test Session object.

   {

   "url": "http://[fd53:5043:5000:471e:e9f3:cbe5:89e8:6067]:8080/api/runningTests/34",

   "measurementsUrl": "http://[fd53:5043:5000:471e:e9f3:cbe5:89e8:6067]:8080/api/runningTests/34/measurements",

   "criteriaUrl": "http://[fd53:5043:5000:471e:e9f3:cbe5:89e8:6067]:8080/api/runningTests/34/criteria",

   "id": 34,

   "library": 5648,

   "name": "PGW4.2.1.1.2",

   "user": "PGW",

   "criteriaStatus": "PASSED",

   "testStateOrStep": "STOPPING"

   },

If this overall criteriaStatus is FAILED and none of the main P/F Criteria are failed, it is safe to assume there must be a UE Info Criteria failure.

^ Back to Top


^ Back to Top