IE Validation Tool

IE Validation Tool Introduction

IE Validation is enabled via the Port Capture tab. Select for UI based IE Validation for 4G Core, 5G Core, ORAN and Service Based Interfaces. This is a licensed feature.

The mandatory IE for each supported message is searched as defined in protocol template csv files and is Compliance Tested. The existence of mandatory IEs is checked, and if needed, compared to the value of the mandatory IE with the expected result. It verifies IE's in Messages, not Messages in Sequences.

IE Validation will report its validation result as fail in IEV log only when:
•   Any of the messages that are found do not match compliance rules.
•   PCAP is empty (no messages which IEV can validate in pcap file).
•   The user defined EXPECTED values rules are not found or mismatched.

The IEV validation final results are captured by pass/fail criteria in the test session - Monitoring the Test Progress. The Test Log includes "criteria:" entries for each IEV check/log - About Test Logs.

The IE Validation can be modified / controlled from the APIs. See the updated API reference documents for the schema, and you can also see the required Tcl API calls via Save-As-Tcl. Supported by RESTFul API - Using the RESTFul API contains reference information about the Landslide RESTFul API system. Refer to Swagger UI on Landslide Home Page, it contains the latest most accurate information for anything it covers. Landslide Tcl API Object and Perform Function Reference.

Available in AMF Nodal, AMF Node, gNB CU SA Nodal, gNB CU Node, MME Nodal, MME Node, PGW Nodal, PGW Node, RIC Nodal, RIC Node, Service Based Nodal, Service Based Node, SGW Nodal, SGW Node, SMF Nodal, SMF Node and UPF Nodal, UPF Node, IMS Node , HSS Node. For list of supported Interfaces for each Test Case, please refer to this list.

The following 5G interfaces are covered - N1, N2, N4, N5, N7, N8, N10, N11, N12, N13, N15, N22, N26, N28, N29, N35, N36, N40, A1 (A1-P, A1-EI)

The Current support Protocols in the Phase 1:

IE Validation: [NGAP/NAS, PFCP, S1AP, GTPv2, Diameter, F1AP, E2AP]

SBI Validation: [N5, N7, N8, N10, N12, N11, N13, N15, N22, N28, N29, N35, N36, N40, A1 (A1-P, A1-EI) ]

For list of messages that are currently supported, please refer to the message table.

For list of supported SBI Version per Interface, refer to this SBI Supported Version table. If you choose an SBI version which is not supported by that interface, the TAS will notify you via msg box indicating “SBI Version is not allowed”, Allowed Version are:"

The "Stop Triggers" panel is replaced with "IE Validation" panel, since PCAP will not be allowed to stop when performing IE Validation:

The IE Validation editor's Protocol / Messages /IE Fields / IE Field selectors are populated with only the interfaces / protocols that are being used on the selected port.

If the selected port does not have any Test Cases that support IE Validation, the "ethX protocols (…)" label would say "ethX protocols (none supported)" and no table will be populated.

If the selected port has multiple test cases that use the same interface, you will see “ethx has conflicting test cases”. Compliance testing is allowed but expected value checking will not be performed.

If the selected port has multiple test cases using the same protocol, this will also be flagged and not allowed.

If you select Enable IE Validation, it means ALL listed protocols will be Compliance Tested. You can optionally add more rules to the tables of the respective tabs.

For SBI validation tab, the columns of configuration index "#", "SBI Service", "Request URI", "Method", "REQ/RESP", "Response Status", "IE/Field Path", "IE/Field Type", "Expected Value" will be available:

# - Configuration index number

SBI Service - Options : Nudm_SDM, Nudm_UECM, Nudm_UEAU, Nudm_EE, Nudm_PP, Nausf_UEAuthentication, Nausf_SoRProtection, Nausf_UPUProtection,

Npcf_PolicyAuthorization, Npcf_SMPolicyControl, Npcf_AMPolicyControl, Npcf_UEPolicyControl, Nnssf_NSSAIAvailability,

Nnssf_NSSelection, Nchf_SpendingLimitControl, Nchf_ConvergedCharging

Request URI - Possible options : /{supi}, /{supi}/sm-data, /{ueId}/registrations/smsf-3gpp-access, etc

Request Method - Options : GET, PUT, DELETE, PATCH, POST

REQ/RESP - Options : REQ , RESP

Response Status - Options : 200, 201, etc

IE/Field Path - Options : JSON Pointer path of IE

IE/Field Type - Options : String, Number (includes decimal), Bool. Object , etc ( Each type matches what the standard JSON would support. For SBI only.)

Expected Value - Options : true, 5, DNN 1, etc

When a test completes, the IE Validation will occur as part of the normal Report Generation after all results and pcaps are retrieved from the Test Servers. The TAS will have to determine which ports are performing IE Validation, find the correct PCAP files, generate default.csv/configuration.csv files then call the IE Validation Tool, one at a time for each PCAP, providing the user's configuration.csv.

The TAS will check for the stdout from the iev script if it contains "PASS" then we know the validation passed otherwise we assume it failed.

Example passed output:

OVERALL RESULT: PASSED

The TAS will also check for the return value from the iev script to be 0 and that the expected result log is produced.

If the result log is missing, or if iev script returns non-0, OR if the iev_debug TAS-SETTING is ON, the TAS will write a file to the results area containing the stdout from the iev script execution.

The detailed Results files out from iev script will be put into the Results Website with the usual naming prefixing, e.g. ts1_eth2_capture_iev.log above.

The live GUI will only show summary results in the run log, i.e. if the IE validation tool returns an single PASS/FAIL output, we can put this in the run log:

IE Validation for eth2 PASSED
IE Validation for eth4 FAILED

Example with iev_debug turned on:

log: 12/02 13:51:01.588:TAS: Generating Results
log: 12/02 13:51:01.607:TAS: Generating IE Validation Output
log: 12/02 13:51:03.708:TAS: IE/SBI Validation for ts1_eth2 IEV executed successfully
warning: 12/02 13:51:03.709:TAS: DEBUG output printed to file
log: 12/02 13:51:03.709:TAS: IE/SBI Validation for ts1_eth2 Passed
log: 12/02 13:51:03.709:TAS: Generating TAS Results
log: 12/02 13:51:04.095:TAS:Test is completed, result files

Limitations:

Only one subscriber is allowed for each Test Case.
Object and array will return only 1 pass, but it will show failed values in different lines for each child.
Parameters with unexpected value can’t be verified pass using IEV tool, e.g. "id-AMF-UE-NGAP-ID", Timestamp, etc.
If you configure the same IE with different values in IE Validation/SBI Validation tab, only the last one will be checked, the others will be ignored.
If multiple same message types exist in the pcap file, the IEV tool will use the same "expected value" to validate them, as a result, one of them would validate as pass and the rest would be failure. e.g. NGAP "Uplink NAS Transport", “PDU Establishment Request”, etc.
Support PFCP version 15.6 or newer due to the decoding ability of Wireshark.
If the selected port has multiple test cases using the same protocol, this will also be flagged and not allowed.
To perform IEV, test cases with UE / Session configurations are limited to 1 UE. Some test cases without UE configuration will be allowed, but IEV can still only work with 1 UE being tested". For example, there is no UE concept in a situation, like NSSF and NRF, they do provide services regardless of the number of UEs that initiating request.

IEV is a protocol IE (Information Element) validation tool based on csv inputs (by TCL API) - is no longer supported. Please use the new tool available above.

NOTE:

IE Validation tool (by TCL API) will no longer be supported. Please use the new tool available above.
tshark is directly callable by “sms” and not by “cfguser”, to dissect but not capture.

Supports parsing of pcap files by:

the pcap file in the schedule list is translated to xml format by tshark
the mandatory IE for each supported message is searched by XPath as defined in protocol template csv file
the existence of mandatory IEs is checked, and if needed, compared to the value of the mandatory IE with the expected result

Supports running the test sessions in the schedule list. And one by one, the session is running by Landslide TCL API and the pcap is retrieved by TCL API. Then analyze the retrieved pcap as above.

Currently S1AP, GTPv2 and Diameter protocols are supported

System Requirements and Prerequisites:

NOTE: IE Validation tool (by TCL API) will no longer be supported. Please use the new tool available above.

1.Operating System

Currently only Linux is supported. IEV is a 32 bits program and install of 32 bits libs is required for 64 bits OS.

2. tshark installation is required

Configure tshark path in the config.tcl

3. Landslide TCL API

Landslide TCL API is required if running sessions from TAS library.

Please refer to http://TASIP/tclapiinstall.html for installation

4. License

IEV is a licensed product. When running, it will connect to the TAS for license validation therefore connection to the TAS is required.

Installation

Extract IEValidation.tar.gz to the working directory.

If running Landslide test sessions, install Landslide TCL API first (see above) and then extract IEV to the Landslide TCL API directory.

tar xvf IEValidation.tar.gz

There are 4 directories:

./csv

./lib # all the dependency libraries

./pcap # pcap files to analyze

./script # config file

Test Preparation -

NOTE: IE Validation tool (by TCL API) will no longer be supported. Please use the new tool available above.

1. config.tcl

Change the settings in config.tcl and below are some of the required parameters.

1.1 Trigger

The trigger could be either PCAP which runs pcap files in pcapCSV or SESSION which runs sessions from TAS listed in sessionCSV.

set sessPcapTrigger PCAP

#set sessPcapTrigger SESSION

#### set the sessions and pcaps list csv

set sessionCSV "session.csv"

set pcapCSV "pcap.csv"

1.2 defaultCSV

May change default.csv which are general settings defined by user.

set defaultCSV "default.csv"

1.3 protocolList

to specify the test protocol

set protocolList [list gtpv2]

set protocolList [list gtpv2 diameter]

set protocolList [list s1ap gtpv2 diameter]

1.4 stateReady

The expected status of the test server. In normal cases, it should be ready, but in some cases, it may be running.

set stateReady "READY 0/3"

set stateReady "RUNNING [1] 1/4"

2. default.csv

2.1 three layers csv files

There are 3 layers of csv files for data input.

The bottom layer is protocol template csv which includes the definition of XPath, which is hidden. Cannot see it or modify it.
The middle layer is default.csv which includes EXP and CHECK columns; it is used for general settings for all pcap files in the list or for all sessions in the list.
The top layer is specified csv which includes special settings for a single pcap or a single session. Defined by users.

The priority is: The hidden template csv is overwritten by default.csv and the default.csv is overwritten by specified csv.

Priority:

Top layer Specified csv -> special settings
Middle layer Default csv -> common settings
Bottom layer Protocol template csv -> invisible to users (protected)

2.2 Items in default.csv

The default csv contains the general settings and is located in ./csv folder.

Sample description below:

Protocol: S1AP, GTPv2 and Diameter are supported

Message: Messages currently supported, please refer to the message table . When adding a new IE, the name should be exactly the same as the name in the message table.

IE Name: IE name description. Not used by Filter. XPath is the key to filter IE.

XPath: In most of cases, XPath is empty in default csv since these are predefined in the lower layer hidden templates. If the user wants to rewrite the XPath, or a new IE is added, it’s required.

EXP: expected value

CHECK: Used to indicate whether the IE is checked or skipped. N means check, Y and “” means skip.

2.3 Specified csv files

The specified csv files are in ./csv/session folder. Single pcap or single session supported. The items are exactly the same as default.csv (2.2), but given higher priority.

2.4 Scheduled list

pcapCSV

If the trigger is PCAP, pcapCSV will be used as the scheduled list.

pcap: pcap name with relative path or absolute path

csvFile: if there is no special setting, use DEFAULT, which means use default.csv to check the messages. If there is a specified csv in csvFile, this specified file will overwrite default.csv as we described in 2.1.

sessionCSV

If the trigger is SESSION, sessionCSV will be used as the schedule.

library: sessions are kept in which library on TAS

session: session name

csvFile: the same as above

How to execute IEV

NOTE: IE Validation tool (by TCL API) will no longer be supported. Please use the new tool available above.

1. Two ways to execute IEV:

1.1 Run ./ls_iev independently in linux shell

1.2. Install Landslide TCL API first and then run ./ls_iev inside Landslide TCL API if sessions need to run

Note:

- Sessions used for this tool can be stopped automatically (Defined in Automation Control)
- Port Capture -> OnStart checkbox is required to be checked.
- Test Server name and Port name for port capture need to be configured in config.tcl

2. Arguments

The arguments have higher priority and will override the parameters of config file, like trigger or the list csv files.

2.1 Session running based arguments

-session -list sessionList.csv

-session -lib library -ts sessionName

-session -lib library -ts sessionName -csv specified.csv

2.2 pcap based arguments

-pcap -list pcapList.csv

-pcap -p pcap/s1ap.pcap

-pcap -p pcap/s1ap.pcap -csv specified.csv

Notice: -p pcapfile needs relative path or absolute path, such as, -p pcap/tau.pcap; others only need file name

2.3 help

Result and Log

1. result.txt

General pass/fail will be kept in result.txt

2. error file

Detailed error strings for each test will be kept in .err

3. all.log

All logging will be kept in all.log

Limitations

NOTE: IE Validation tool (by TCL API) will no longer be supported. Please use the new tool available above.

Supported Messages

Currently support S1AP, GTPv2 and Diameter protocols in general.

For S1AP messages, a list is provided. Currently, we do not support several negative messages, because landslide does not provide a trigger. If missing messages are required, provide us with a pcap sample and we can attempt to add template in the next release.

For GTPv2 messages, there are some IE we cannot trigger like some overload control messages. If required, provide us with a pcap sample and we can attempt to add template in the next release.

For Diameter message, now we support Gx and S6a interfaces.

Multiple subscriber

IEV is designed for only 1 subscriber, but if check the existence of IE or the value of IE doesn’t change, IEV can verify. If the value of IE is different for multiple subscribers, the case cannot be supported at this time.

Optional IE

We only support mandatory IE, if the user wants to add optional IE, the user can add information in the default csv.

How to get IE’s XPath for this tool

NOTE: IE Validation tool (by TCL API) will no longer be supported. Please use the new tool available above.

1. Open pcap file, find expected message, filter it out and export it as PDML XML file

2. Find expected IE in the message and get its name in XML

Take Protocol discriminator as an example; its name in XML would be “gsm_a.L3_protocol_discriminator”.

3. Open exported XML, find XML node and generate XPath;

Get IE’s XPath via any text editor. Some tools which support XML, can help to get it easier.

4. Revise draft XPath to use it in the tool

Draft XPath is shown below (Notes: there may be slight difference if using different Wireshark version):

/pdml/packet/proto[@name='s1ap']/field[@name='s1ap.S1AP_PDU']/field/field[@name='s1ap.value_element']/field/field[@name='s1ap.protocolIEs']/field[@name='']/field[@name='s1ap.ProtocolIE_Field_element']/field[@name='s1ap.value_element']/proto/field[@name='gsm_a.L3_protocol_discriminator']/@value

Revise it to be more accurate and the tool can use it:

{string(./packet[$i]/proto[@name='s1ap']/field[@name='s1ap.S1AP_PDU']/field/field[@name='s1ap.value_element']/field/field[@name='s1ap.protocolIEs']/field[@name='']/field[@name='s1ap.ProtocolIE_Field_element']/field[@name='s1ap.value_element']/proto[@name='nas-eps']/field[@name='gsm_a.L3_protocol_discriminator']/@value)}

5. Use contains() to improve XPath’s compatibility

There may be slight difference if using different Wireshark version, such as, for /field[@name='s1ap.value_element'], if using different Wireshark versions, may get /field[@name='s1ap.value'];

We will use function contains(@attribute, 'value') to all string which include “_element”;

New Xpath shown below:

{string(./packet[$i]/proto[@name='s1ap']/field[@name='s1ap.S1AP_PDU']/field/field[contains(@name,'s1ap.value')]/field/field[@name='s1ap.protocolIEs']/field[@name='']/field[contains(@name,'s1ap.ProtocolIE_Field')]/field[contains(@name,'s1ap.value')]/proto[@name='nas-eps']/field[@name='gsm_a.L3_protocol_discriminator']/@value)}

6. Sample has been added into default.csv

s1ap,Paging,Criticality(id-UEIdentityIndexValue),"{string(./packet[$i]/proto[@name=""s1ap""]/field[contains(@name,""s1ap.S1AP_PDU"")]/field[contains(@name,""s1ap.initiatingMessage"")]/field[contains(@name,""s1ap.value"")]/field[contains(@name,""s1ap.Paging"")]/field[@name=""s1ap.protocolIEs""]/field[contains(@show,""id-UEIdentityIndexValue"")]/field[contains(@name,""s1ap.ProtocolIE_Field"")]/field[@name=""s1ap.criticality""]/@showname)}",,