NG40

Test Case Execution,

Verification and Modification
Virtual Machines

Execute a Test Case

Test case execution from CLI:

Test case name

NG40 Shell command

Company & Products

Page 2

Test Case Output

Test verdict: None (NONE, PASS, FAIL)

Prompt

End of test case execution

Company & Products

Page 3

Verify
Command verify returns statistic

All those parameters can be used for test verification (test result)
Company & Products

Page 4

Verify
-

Statistic are global values information of a complete test campaign

-> Statistic for a single test case: Reset before test case execution
1) Reset manually from CLI:
2) Reset automatically from test scenario config file

Company & Products

-> resetstat
-> callscenario.conf

Page 5

Test Case Structure

Call Model

Test Case

Test Verdict (optional)

Company & Products

Page 6

Verdict = PASS

Company & Products

Page 7

More Complex Test Verdicts

- sets
- direct comparison of messages
- equations
- absolute numbers
- bigger, smaller

Company & Products

Page 8

If a test case fails

- Leave NG40 Shell

- ls -lsrt log
- List of logfiles as depicted below

- vi log/ <logfile name>

- shift-g

->

shutdown, abort

->

Root Cause

Company & Products

Page 9

Call Model

traffic

A Call Model consists of (phases):

loop

Begin Scenario
Loop Scenario
End Scenario
Recovery Scenario (optional)

begin

end

time

Hint: Duration of the Loop Scenario is defined in the Test Case as following:
period[x].duration = <time in seconds>
period[x].duration = 0
infinite
Company & Products

Page 10

Call Model - Phases

1. Begin Scenario:
- Executed once at the beginning
- Intention is to change the state of the emulated subscriber
- From idle mode to test mode
2. Loop Scenario:
- Executed several times as defined in the Test Case
- period[x].duration = 60
[in seconds]
- period[x].duration = 0
[infinite ]
3. End Scenario:
- Executed once at the end
- Intention is to change the state of the emulated subscriber
- From test mode to idle mode

Company & Products

Page 11

Call Model - Phases

4. Recovery Scenario (optional):
- Will be executed in case of irrecoverable errors
- Intention is to bring the subscriber back into a defined state
- Recovery Scenario will be triggered after:
- Timeouts, like no Tracking Area Update Accept after Tracking Area
Update Request
- Reject Messages, like Security Mode Reject
- Abnormal Cause values, like CS domain temporary not available
- Predefined limit of message repetitions

Company & Products

Page 12

Combination of Call Models

- Every Call Model has a unique name
- Several Call Models may coexist in one Test Case

Concurrent
period[x].group[m]
period[x].group[n]
period[x].group[o]

In sequence
period[a].group[x]
period[b].group[y]
period[c].group[z]

- Typical example for concurrent call models:

- group[m] = called party
- group[n] = calling party
- Starting time and duration of the periods are defined in the test case

Company & Products

Page 13

Combination of Call Models

Learnings:
- Groups will be executed concurrently
- Periods will be executed sequentially

Company & Products

Page 14

Test Structure - Example

Groups

Call Models
Period index Group index

Name
Company & Products

Page 15

Important Design Principles

1. All groups (group[m], group[n], group[o]) are independent from each other
2. A emulated Mobile Subscriber can only belong to one group
Subscriber with IMSI = 262 01 9876543210 belongs to group[m]
Same subscriber must not belong to any other group
3. A certain group can be used only once at a time
4. Call models are subscriber-agnostic

Why?
Answer: A mobile subscriber cannot assume several roles, like Called Party and
Calling Party at the same time.

Company & Products

Page 16

Test Flow Generic Overview

period[0]
BEGIN_SCENARIO
LOOP_SCENARIO
END_SCENARIO

period[1]
BEGIN_SCENARIO
LOOP_SCENARIO
END_SCENARIO

period[2]
BEGIN_SCENARIO
LOOP_SCENARIO
END_SCENARIO

period[m]
BEGIN_SCENARIO
LOOP_SCENARIO
END_SCENARIO

time

Company & Products

Page 17

Scenarioswitchmode
Two ways how subscribers move through SCENARIOS and PERIODS:
1. concurrent

or

direct:

- All subscribers pass scenarios independently

from the remaining subscribers
- E.g. some subscribers still in END_SCENARIO,
of in period[0], while others already in
period[1] and period[2]

period[0]
BEGIN_SCENARIO
LOOP_SCENARIO
END_SCENARIO
period[1]
BEGIN_SCENARIO
LOOP_SCENARIO
END_SCENARIO
period[2]
BEGIN_SCENARIO
LOOP_SCENARIO
END_SCENARIO

Company & Products

Page 18

Scenarioswitchmode
Two ways how subscribers move through SCENARIOS and PERIODS:
2. up/down:

- All subscribers move together to the

next scenario
- Next scenario after last subscriber passed
previous scenario
- e.g. all subscribers in LOOP_SCENARIO of period[1]

period[0]
BEGIN_SCENARIO
LOOP_SCENARIO
END_SCENARIO

period[1]
BEGIN_SCENARIO
LOOP_SCENARIO
END_SCENARIO

period[2]
BEGIN_SCENARIO
LOOP_SCENARIO
END_SCENARIO

Company & Products

Page 19

Test Case Structure Summary

1. A Test Case is a series of Periods
2. Every Period is a combination of Subscriber Groups
- Subscriber Groups belonging to the same Period run concurrently
- Therefore the requirement that a certain subscriber must belong to exactly
one group
3. To every Group assigned is exactly one Call Model

This structure is depicted at the next slide.

Company & Products

Page 20

Test Case Structure Summary

Test Case = rt_ps_call

Test Case
sequentially

period[0]
Mobile Subscriber

period[1]

period[2]

group[x]

group[x]

International Roamer

Mobile Subscriber

ps_call

Period

Standard Subscriber

Mobile Subscriber

group[0]

concurrently

Group

group[y]

group[y]

Fraudulent Subscriber
group[z]

Call Model

Call Model

Call Model

loop

loop

loop

begin

end

begin

end

begin

end

Company & Products

Call Model
Page 21