Contents Telektronikk - Telenor

4.1.2 The STG overview
The purpose of the STG is to generate
traffic with properties similar to a multiplex
of independent sources where each
source has a behaviour close to real
source. The software and hardware elements
that constitute the STG sub-system
are shown in Figure 4.2.
The software runs on a SUN SPARC
under SOLARIS 2.3. It includes an Open
Windows based man machine interface
(MMI), several graphical editors, the
STG Module Handler performing the
necessary checking and compilation of
source types and scenarios and the STG
specific drivers. The system also contains
the STG database which includes various
set-ups, scenarios, source-type definitions,
etc.
4.1.3 The STG hardware
The hardware is made as a two slot Csize
VXI module. It consists of 12
FPGAs (field programmable gate arrays),
each in the range 10,000–20,000 gates
and 10 Mbit of RAM. One of the slots
serves as the VME/VXI interface, which
handles the communication with the rest
of the instrument. The other slot is the
STG kernel and handles the composite
source model. The functionality is
arranged as shown in Figure 4.3.
In the block to the left, the next time and
old/new state are found for the next state
change, cf. (3) and (4) of Table 2.1.
These are transferred to the next block,
and the block is ready for the next operation.
The FIND SOURCE block finds the
source for the state change, cf. (5) and
(6), and finds the pattern associated with
the new state. These data are sent down
to the UPDATE PATTERN block together
with the time when the pattern
should be updated. The FIND SOURCE
block also handles the activations/deactivations
sent by the software, and the long
patterns. Long patterns are handled as a
set of normal patterns resulting in a “state
change” for each new part of the long
pattern.
The UPDATE PATTERN block updates
up to 8 state changes in parallel, at the
time requested. The old patterns are
removed from the PCTP (periodic cell
transmission pattern) and the new ones
added, see Figure 2.13.
Every 2.7 microsecond a source_id is
read out from the PCTP and sent to the
ASSEMBLE CELL block. This block
uses the source_id from the PCTP as a
pointer to a cell with header and payload,
Find:
next time
old state
new state
Next time
Old state
New state
Activation
Deactivation
Find:
source
Handle:
Activation
deactivation
Long Pattern
Figure 4.3 The STG hardware block diagram
and sends this cell out to the next module
in the test tool. A cell may be transformed
into a test cell (foreground traffic)
before it ends up in the output module
(OM).
The two blocks to the left in Figure 4.3,
which handle the stochastic parts of the
model, use four Tausworthe pseudo-random
generators with primitive trinomials
between 25 and 34 bit [34, 35]. The
sequence lengths of each random generator
are mutually prime. To ensure no
correlation between the numbers, the
generators are clocked as many time as
their length between each time a number
is used.
The activation and deactivation are used
to emulate the connection level. The software
sends activation and deactivation
messages to the hardware at the time
these should take place according to the
load profiles. There will be one profile
for each pair of source type and destination
in the network, see Table 2.2 for an
example. In a profile the number of
sources for this pair will vary according
to the graph. When the level changes, the
software selects which sources to activate/deactivate.
Since the properties of
all the source of the same type toward the
same destination are identical, an arbitrary
selection of these may be chosen.
The software handles simultaneously all
profiles for all source types toward all
destinations, cf. Figure 2.14. When a profile
changes, the activation/deactivation
which corresponds to the change will be
sent to the hardware. The changes are
effectuated in the hardware as soon as
possible, which is maximum eight activations
or deactivations per 0.1 ms and, on
the average, seven at nominal load.
Next time
Next source
Next pattern ATM-cell
Update
pattern
Assemble
cell
Update Cell pointer
Periodic cell transmission pattern
4.1.4 The STG software
The software is written in C. The volume
of the executable is about 12.5 Mbytes
and on-line help, database, etc. occupy a
similar volume. An outline of the various
software elements is presented in Figure
4.2.
The Scenario editor is in many ways the
core of the STG software. For each
measurement, a scenario is defined. In
this editor the number of sources, source
types, destinations, cell headers/payloads
and load profiles are put together, see
Table 2.2. It also checks the parameters
and calculates values, like average and
maximum load, average rate of state and
pattern changes. Graphs like the expected
load as a function of time and type/destination
are also calculated and presented
to the user, see Figure 2.14.
Load profiles for activation – deactivation,
i.e. handling the connection level,
are defined in the Profile editor as a
graph of how many sources that are
active at any measurement instant. The
graphs are similar to those indicated in
Table 2.2.
The hardware is initialised and controlled
through the STG module handler. When a
measurement shall be carried out it calculates
the necessary parameters to set the
STG in a steady state for the actual load
scenario, transforms the scenario definition
to the format required by the STG
and downloads the data to the hardware.
The Source type editor allows an efficient
definition of state diagrams with a
“bubble” for each state containing name,
sojourn time and a pattern_id, arrows
between the states hold the next state
probabilities, i.e. similar to what is indi-
189