Day 3RTD Tool Features and Concepts

Archives

Archives are folder locations which are mapped into RTDRTD then can locate foldersThis has several benefits for management of RTD projects Grouping of test cases Grouping of compound procedures for use in other tests Simple management of upgrades Easier integration of RTD projects into version control systems Integration into RTD workspaces

Procedure libraries

Procedure libraries are the building blocks of test casesRTD has several procedure libraries Basic L3 procedure library (UTRAN/GERAN) The following libraries can be combined for inter-RAT

• LTE low level library• UTRAN/GERAN low level library (similar to PTS)• CDMA2000 procedure library (MD8470)

RTD also has L3 libraries built from the low level libraries for LTE, UTRAN and GERAN

• These are in the form of parameterised compound procedures

Catalogues

Catalogues are used to contain sets of parameters associated with procedures. Procedures can import these parameter sets for use in test cases When imported the parameter sets can be by value or by reference By Value

• A local copy of the parameters are imported into the procedure• A link remains between the catalogue entry and the local copy but the

parameters are not automatically updated By Reference

• Parameters are for the procedure are linked and locked to the catalogue entry used to populate the procedure

• The parameters in the procedure can then no longer be modified directly in the procedure, to modify the parameters the catalogue is modified.

• If the catalogue is modified then all procedures in all tests which are linked by reference are automatically modified

CataloguesParameters can be exported to or imported from a catalogue

Catalogues

Compound procedures

Compound can be thought of like “functions”Compound procedures group library procedures into compact building blocksCompounds can contain other compound procedures “nested”Compounds can be local or exported to an archive for re-use in other tests

Compound Terminators

Compound terminators are exit points for the compound procedureUsers can define their own compound terminators to provide extra exit options

Individual SE terminators do not need to be connected to this…

…this is implied in the SE definition

All unconnected nodes are routed

here

Usually the standard output from the main

test branch of the Compound procedure

Compound procedure parameters

Parameters can be added to compound procedures to pass information in and out

Compound procedure types

Archived compound procedures can be re-used in tests in two ways By Value

• A local copy of the archive compound is made in the test• A “link” will exist between the two instances of the compound• Modifying either the test case compound or the archive compound will

not have an effect on the other copy• Test case copy can be updated with the archived copy at any time

By Reference• In this case an instance of the archived compound procedure is created

in the test• Modifying either the test case compound or the archive compound will

change both the archived instance and the test case instance• Advantage is that only the archive instance needs to be modified to

update all test cases which use this compound by reference.

Compounds by reference

Compounds can be included in a test from an archive and a link maintained between all instances of that compound, i.e. if one is edited all are changed

Workspaces

Workspaces are used to group together Archives Catalogues

By grouping these together into a workspace we can create an environment which is easier to control It allows all elements of a test suite to be groupedTypically workspaces group together archives and catalogues for a specific purpose e.g. RRC test, NAS test, L2 test, L1 testIn support we use workspaces for working with different customers as this enables us to quickly reproduce the complete environment linking all the components togetherSimilar in concept to solutions/projects in Visual studio

Declarations

The declarations window can be used to declare: Variables

• Use to store and manipulate data• Can be complex types i.e. complete message structures• Can be manipulated using simple arithmetic and operations

Timers User events Parameters (these can be for a compound procedure or a testcase)

Declarations

Local – only applicable to this test

Global – available to other tests, can be modified from within the context it was created

External – available from other tests, cannot be modified from within the current context

Variable Assignment and Evaluation

1. Assign value to Variable ‘X’2. Test value of

Variable ‘X’

3. Output path dependant on Variable ‘X’

Timers

Adding Criteria to tests

To provide objective testing we must create a pass/failThis is achieved by adding criteria to a testCriteria are designated points/nodes of interest in a test

Users can create groups of criteria and then add paths to the groupHere I have a pass and fail group each with different pathsAfter creating a path the user can then select a node to add to the pathIf the node is selected twice then the path must be executed twice for the path criteria to be satisfied.

Adding Criteria to tests

Path criteria are then combined using logic to provide an overall pass failThis is achieved by simply dragging on to the results criteria

Criteria and Results

In the results view selecting a test run will show us the criteria overview for the test runCriteria which are satisfied will show as indicated.Criteria can be added after a test is complete and the results will be updated to reflect this changeAlso when a test results are created the historical criteria are saved and can be viewed by selecting historical criteria view in this window.

Wait For Event

Wait for event is used in a test to provide a pause to wait for either Timer expiry Incoming message User event

Multiple incoming message can be connected to provide flow changes based on UE requests

User Events

1. Declare events

2. Build events into test

3. Use events at run-time

Loops

Execution View

During runtime execution is tracked using colouring of the procedures.

Runtime MSC

RTD provides a runtime MSC for real time debug of executing test casesThis MSC provides a full decode of Tx and Rx messages at every layerAll L2 PDUs are also decoded providing structure of MAC, RLC and PDCP PDUsThis view can be paused for analysis for messages or will track execution.Blue banners have also been added to indicate compound procedure boundariesThe runtime MSC is mainly used for C-Plane messagesThis MSC is also available from the results view.

Runtime MSC

Protocol analyser

Protocol analyser tool can be accessed directly from RTD for any previously executed runThe PA log consolidates all C-plane and U-plane and primitive messages, i.e. all enabled channels will be visible in the PA logThe PA log tool ass many more features such as filtering of messages, turning on and off complete layers, searching for messages based on any IE or text from the decoded messageQuick, detailed and easy to use

Protocol Analyser

Measurement, Monitor and Trace Application

MMT provides: Detailed low-level debug

• L1 and 2 statistics measurements, Phy, MAC HARQ, Throughput, CQI, RLC, PDCP etc

• Monitor of all power levels and timing errors• Runtime, real time MSC logging of all data and primitives• Runtime control of trace logging• Post process of all L1 information including DL/UL DCIs, PUCCH SRs,

CQI, PMI,RI etc.

Measurement window

Monitor Window

Trace Window

Trace post process tool

Post process of binary log for detailed DL and UL analysis

Analysis contains very detailed information on a TTI-TTI basis

Incoming Message Matching

Any receive message procedure can be populated with message match constraint based on the ASN for that messageIf the message matches the constraint then that message will be removed from the message queue and the procedure will exit on the OK nodeIf the message does not match then the procedure will exit on the IMM (Incoming Message Mismatch) node and the message will be left in the message queue for matching against another templateSame message types can be chained together to provide change in test flow based on UE messagesTypically when a message match is implemented the IMM node at the end of the chain will be a blank template to remove the queued message.

Incoming Message Matching

Double clicking on a receive procedure will open the parameter editor.Incoming message ASN is parameterised to create a message constraint.

Incoming Message Matching

Following from the example on the previous slide, since the UE does not send establishment cause emergency the RRC message does not match the first constraint and exits on the IMM nodeThis same message is then compared with the second constraint and matched so exits on the OK nodeTest flow is denoted by green procedures.

Variables by example

Variables can be of the type of a complete message or IE in a messageTo create a variable of this format: open the procedure Select the message or IE you wish to create a variable from Hit the variable by example button Give the variable a name or use the default name Apply changes The RTD will then add this variable to the declarations for the test

or compound procedureThis variable will created and will contain the structure of the message or IEYou can then assign incoming messages or IEs of the same type to the variable

Variables by example

Variable by example

Variable by example created in The declarations editor

Variable assignment from incoming message

The parameter editor for a receive message procedure has an assignment window

From here we can create assignments based on the received message using the breadcrumb notation as shown below