1. Day 3 RTD Tool Features and Concepts

2. Archives Archives are folder locations which are mapped into RTD RTD then can locate folders This 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

3. Procedure libraries Procedure libraries are the building blocks of test cases RTD 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

4. 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

5. Catalogues Parameters can be exported to or imported from a catalogue

6. Catalogues

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

8. Compound Terminators Compound terminators are exit points for the compound procedure Users 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

9. Compound procedure parameters Parameters can be added to compound procedures to pass information in and out

10. 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.

11. 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

12. 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 grouped Typically workspaces group together archives and catalogues for a specific purpose e.g. RRC test, NAS test, L2 test, L1 test In support we use workspaces for working with different customers as this enables us to quickly reproduce the complete environment linking all the components together Similar in concept to solutions/projects in Visual studio

13. 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)

14. 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

15. Variable Assignment and Evaluation 1. Assign value to Variable ‘X’ 2. Test value of Variable ‘X’ 3. Output path dependant on Variable ‘X’

16. Timers

17. Adding Criteria to tests To provide objective testing we must create a pass/fail This is achieved by adding criteria to a test Criteria are designated points/nodes of interest in a test Users can create groups of criteria and then add paths to the group Here I have a pass and fail group each with different paths After creating a path the user can then select a node to add to the path If the node is selected twice then the path must be executed twice for the path criteria to be satisfied.

18. Adding Criteria to tests Path criteria are then combined using logic to provide an overall pass fail This is achieved by simply dragging on to the results criteria

19. Criteria and Results In the results view selecting a test run will show us the criteria overview for the test run Criteria 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 change Also when a test results are created the historical criteria are saved and can be viewed by selecting historical criteria view in this window.

20. 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

21. User Events 1. Declare events 2. Build events into test 3. Use events at run-time

22. Loops

23. Execution View During runtime execution is tracked using colouring of the procedures.

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

25. Runtime MSC

26. Protocol analyser Protocol analyser tool can be accessed directly from RTD for any previously executed run The PA log consolidates all C-plane and U-plane and primitive messages, i.e. all enabled channels will be visible in the PA log The 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 message Quick, detailed and easy to use

27. Protocol Analyser

28. 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.

29. Measurement window

30. Monitor Window

31. Trace Window

32. 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

33. Incoming Message Matching Any receive message procedure can be populated with message match constraint based on the ASN for that message If the message matches the constraint then that message will be removed from the message queue and the procedure will exit on the OK node If 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 template Same message types can be chained together to provide change in test flow based on UE messages Typically 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.

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

35. 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 node This same message is then compared with the second constraint and matched so exits on the OK node Test flow is denoted by green procedures.

36. Variables by example Variables can be of the type of a complete message or IE in a message To 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 procedure This variable will created and will contain the structure of the message or IE You can then assign incoming messages or IEs of the same type to the variable

37. Variables by example Variable by example Variable by example created in The declarations editor

38. 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