U.S. patent application number 09/775842 was filed with the patent office on 2001-08-23 for creation of a protocol stack.
Invention is credited to Kittan, Jens, Lenz, Dirk-Holger.
Application Number | 20010015984 09/775842 |
Document ID | / |
Family ID | 8167942 |
Filed Date | 2001-08-23 |
United States Patent
Application |
20010015984 |
Kind Code |
A1 |
Lenz, Dirk-Holger ; et
al. |
August 23, 2001 |
Creation of a protocol stack
Abstract
An apparatus for creating a protocol stack has at least one
protocol layer with at least one standardized interface and an
instance for the administration of the protocol stack. The protocol
stack is created by making available the protocol layer(s),
randomly compiling the protocol stack from the protocol layer(s),
and making available an instance for the administration of the
protocol stack using a graphical user interface.
Inventors: |
Lenz, Dirk-Holger;
(Brieselang, DE) ; Kittan, Jens; (Schwante,
DE) |
Correspondence
Address: |
Francis I. Gray
TEKTRONIX, INC.
P.O. Box 500, MS 50-LAW
Beaverton
OR
97077
US
|
Family ID: |
8167942 |
Appl. No.: |
09/775842 |
Filed: |
February 1, 2001 |
Current U.S.
Class: |
370/469 |
Current CPC
Class: |
H04L 9/40 20220501; H04L
69/03 20130101; H04L 69/32 20130101 |
Class at
Publication: |
370/469 |
International
Class: |
H04J 003/16; H04L
012/28 |
Foreign Application Data
Date |
Code |
Application Number |
Feb 23, 2000 |
EP |
00 103 797.7 |
Claims
What is claimed is:
1. An apparatus for creating a protocol stack comprising: a
protocol layer with a standardized interface; and an instance for
the administration of the protocol stack that contains the protocol
layer.
2. The apparatus as recited in claim 1 wherein the protocol layer
comprises a description file in which a characteristic of the
protocol layer is described.
3. The apparatus as recited in claim 2 further comprising means for
linking the description files of components of the protocol layer
with each other.
4. The apparatus as recited in claim 1 wherein the instance
comprises: a local emulation manager that is assigned to the
protocol layer; and a global emulation manager that is linked to
the local emulation manager.
5. The apparatus as recited in claim wherein the protocol layer has
a Service Access Point, with the Service Access Point having an
input and/or an output to another Service Access Point.
6. The apparatus as recited in claim 4 wherein the protocol layer
comprises an input and an output to connect with the local
emulation manager.
7. The apparatus as recited in claim 1 wherein the protocol layer
is configured to be connected with at least two higher protocol
layers and at least two lower protocol layers.
8. The apparatus as recited in claim 2 wherein the characteristic
comprises: a description of a Service Access Point as a list of
primitives that may be exchanged via the Service Access Point; and
parameters of the protocol layer; and actions of the protocol
layer.
9. The apparatus as recited in claim 8 wherein the primitives are
shown as standardized structures and standardized coding.
10. The apparatus as recited in claim 8 further comprising a
communication function for giving the Service Access Point the same
form as the instance.
11. The apparatus as recited in claim 1 further comprising an
interaction element via which a user interacts with the protocol
layer.
12. The apparatus as recited in claim 11 further comprising a
script interpreter that is incorporated by the interaction element
into the protocol stack so that the user acts on the protocol
stack.
13. The apparatus as recited in claim 1 further comprising a
graphical user interface for putting together the protocol
stack.
14. The apparatus as recited in claim 13 wherein
protocol-layer-specific information is made available via the
graphical user interface.
15. The apparatus as recited in claim 14 wherein the
protocol-layer-specific information comprises: adjustable and
constant parameters of the protocol layer; and actions of the
protocol layer, the parameters and actions being modifiable by the
user.
16. A method of creating a protocol stack comprising the steps of:
making available a protocol layer with a standardized interface;
randomly compiling the protocol stack containing the protocol
layer; and making available an instance for the administration of
the protocol stack.
17. An apparatus for creating a protocol stack comprising: a
plurality of local emulation managers, each local emulation manager
being coupled to a protocol layer emulation with the protocol layer
emulation having a standardized interface; a global emulation
manager linked to the local emulation managers to form an
administration instance; and means for interacting with the
administration instance to provide administrative commands for
loading and connecting elements including the protocol layer
emulations to create the protocol stack.
Description
BACKGROUND OF THE INVENTION
[0001] The present invention relates to protocol testing, and more
particularly to a method for creating a protocol stack and to a
protocol tester using the method.
[0002] The field of protocol measurement technology is a highly
innovative one. After each new or further development of
telecommunication or network protocols, manufacturers and operators
of network and telecommunication equipment face the problem of
having to check the functioning and conformance of the new systems.
Because of competition each manufacturer tries to launch its
product on the market as early as possible. This pace of
development places special demands on manufacturers of protocol
testers.
[0003] In order to keep testing times for their systems as short as
possible and minimize the scope of protocol knowledge that test
personnel need to have, manufacturers often use protocol emulations
on their protocol test systems. In practice emulations of a
protocol are often prepared so that the emulations copy individual
protocol layers. Connecting the individual protocol layers to form
an emulation system thus allows copying entire protocol stacks or
selected parts of a protocol stack. The individual protocol layers
are viewed abstractly and in this way transmit data from layer to
layer. To this end so-called primitives are often used in protocol
specifications to describe the communication between protocol
layers. Creating such protocol emulations involves a great deal of
work.
[0004] In may cases new protocol stacks consist entirely or almost
entirely of protocol layers already known. But also in these cases
it is necessary to compile a new application for the protocol test
system. At this point a great deal of flexibility is desired for as
simple a procedure as possible for the modification of protocol
stacks.
[0005] According to the state of the art it has, until now, been
standard practice for protocol systems that have the capability of
simulating and using protocol emulations for this purpose to offer
static applications, i.e., the user calls up and uses ready-made
applications. In this connection reference is made to the ISO/IEC
10731:1994 Open Systems Interconnection (OSI) reference model, the
contents of which are herein incorporated by reference. In this
case it is not possible for the user to modify the protocol stack
by adding, replacing or removing protocol layers. Preparing a new
application, i.e., putting together existing protocol layer
emulations, requires special system know-how and knowledge of
communication mechanisms used, and usually is only done by the
manufacturer. For the protocol tester this creates the problem that
the tester will only encounter a limited number of applications,
each with a specific constellation of protocol emulations.
[0006] Other solutions, such as stream concepts, have not prevailed
in protocol test systems. Stream concepts may only be used where
there is an exact layering system with one protocol layer location
on top of another. As soon as there are several protocols on the
same level and cross relationships between different levels become
necessary or relationships extend beyond two levels, this
technology may no longer be applied.
[0007] What is desired is a method that allows a user of a protocol
tester to put together existing emulations of protocol layers in a
flexible and simple manner to form a protocol stack so that the
user requires little previous knowledge of the protocols.
BRIEF SUMMARY OF THE INVENTION
[0008] Accordingly the present invention is a method of creating
protocol stacks that has at least one protocol layer with at least
one standardized interface and has an instance for the
administration of the protocol stack which contains such a protocol
layer. A standardized, generic emulation environment is made
available that allows a user to integrate protocol layer emulations
as required into a protocol stack and/or connect the protocol layer
emulations with other protocol layer emulations, script
interpreters or control components. Equipping protocol layers with
standardized interfaces creates the possibility of connecting
protocol layers with each other in a simple manner or connecting
protocol layers with script interpreters or control components.
Standardization of the interfaces also makes it possible for a user
to require only little previous knowledge to put together a
protocol stack.
[0009] In the process each protocol layer and/or each script
interpreter is assigned a description file in which at least one
characteristic of the protocol layer and/or script interpreter is
described. When a protocol stack is put together, the description
files are automatically linked with one another. This is done by
the above instance for the administration of the protocol stack or
by a separate device. In this process the instance or separate
device provides a generic communication and administration
mechanism for the protocol emulations. The instance preferably has
at least one local emulation manager that is assigned to at least
one protocol layer and a global emulation manager that is linked to
each local emulation manager.
[0010] Each protocol layer preferably features at least one
so-called Service Access Point (SAP), with each SAP providing an
input and/or output to another SAP. SAP is the logical point of
access to a protocol layer into which data flow (receiving) or from
which data are made available (sending) by the protocol tester.
When applied to protocol emulation the inputs and outputs of the
emulations are referred to as SAPs. Depending on the functions of
these inputs and outputs, different types of information are
expected. Two protocol emulations are linked by connecting the
appropriate SAPs of these emulations. In these links a sending SAP
of one emulation is connected to a receiving SAP of the other
emulation. Both SAPs handle the same kind of data.
[0011] Each protocol layer preferably features an input and an
output to connect with the instance, particularly to the local
emulation manager. It is possible to configure a protocol layer so
that it may be connected with at least two higher protocol layers
and/or at least two lower protocol layers. The characteristics
stored in the description files have a description of the SAP,
particularly by way of a list of primitives that may be exchanged
via the relevant SAP, and have adjustable and/or constant protocol
layer parameters as well as protocol layer actions. To minimize the
amount of previous knowledge a user needs to have, in an especially
preferred embodiment the primitives of each protocol layer are
allowed to be illustrated by way of standardized structures and
standardized coding. The SAPs take on the same form as the instance
by using communication functions.
[0012] In a preferred embodiment an interaction element, i.e., a
script interpreter, is used via which a user may interact with at
least one protocol layer. A graphical user interface (GUI) may be
used via which the user may put together the protocol stack. The
GUI provides protocol layer-specific information, with the user
being able to modify in particular adjustable and/or constant
parameters of the protocol layer and/or actions of the protocol
layer. The modifications made by the user are taken into account in
the description files. After entry by the user, the current
description files are put together by the instance or an additional
device as desired to form the protocol stack without requiring any
further action on the part of the user.
[0013] Therefore a method for creating a protocol stack involves in
a first step a protocol stack with at least one standardized
interface being made available. In a second step the protocol stack
having at least one such protocol layer is randomly put together.
In a third step an instance for the administration of the protocol
stack is made available.
[0014] The objects, advantages and other novel features of the
present invention are apparent from the following detailed
description when read in conjunction with the appended claims and
attached drawing.
BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING
[0015] FIG. 1 is a block diagram view representing the interaction
of specific components of a protocol tester according to the
present invention.
[0016] FIG. 2 is a block diagram view representing an interface
board of the protocol tester according to FIG. 1.
[0017] FIG. 3 is a schematic diagram view representing an emulation
management layer according to the present invention.
[0018] FIG. 4 is a schematic diagram view representing possible
outputs and inputs of an emulation according to the present
invention.
[0019] FIG. 5 is a plan view of a first user interface of a
protocol stack editor according to the present invention.
[0020] FIG. 6 is a plan view of a second user interface of the
protocol stack editor according to the present invention.
[0021] FIG. 7 is a block diagram view representing a protocol stack
that may be realized according to the present invention.
[0022] FIG. 8 is a detailed flow diagram view representing the
interactions of the protocol stack according to FIG. 7.
DETAILED DESCRIPTION OF THE INVENTION
[0023] Referring now to FIG. 1 components of a protocol tester are
shown, including a personal computer (PC) board 10, such as an
Intel Pentium 133 central processing unit (CPU) with a Windows NT
4.0 operating system, a random access memory (RAM) and a hard disk.
The protocol tester also includes a graphical user interface (GUI)
12 and an application board 14, such as an application processor
card having a Motorola 68040 CPU with a vxWorks realtime operating
system and a RAM. The application board 14 contains a global
emulation manager 16, analyzer bubbles 18 and a local and a global
pipeline manager 20, 22. The protocol tester further contains
several, preferably six, interface boards 24a-24n, for example for
E1/T1, S0/U2B1Q/V/X and ATM interface standards, which interface
boards may use either a Motorola 68040 or an Intel 960 CPU with a
vxWorks operating system. Each interface board 24 features a local
emulation manager 26, a remote transfer layer 28 and a driver 30.
All boards 10, 14, 24 communicate via a VME bus 31. An emulation
management layer 33 is formed from the local emulation managers 26
and the global emulation manager 16. The emulation management layer
33 serves to control cooperation, installation and configuration of
a protocol stack. To enable easy compilation of the protocol stack
and to be independent from the operating system, the interface
boards 24 have a uniform, standardized configuration.
[0024] FIG. 2 shows an interface board 24 with a local emulation
manager 26 having an emulation interface layer 32 that constitutes
an abstraction layer between the operating system and each
emulation 34a-34c. It provides an interface for logical
communication paths to the emulations 34 using external queues for
their implementation. The emulation interface layer 32 provides the
emulations 34 with functions to assign storage, allocate buffers,
start and stop timers, and send sequence tracking messages. Only
for the installation and deinstallation of the emulations 34 does
emulation interface layer 32 import functions to initialize and
deinitialize the emulations and to start the emulation.
[0025] Administrative queries to the global emulation manager 16
serve the purpose of creating or deleting an emulation 34 within a
specified protocol stack, i.e., viewed at the emulation level
within an emulation pipeline configuring or querying parameters of
the emulation, querying a menu system for emulation parameters and
connecting communication paths between emulations. Each
administrative query to the local emulation manager 26 is carried
out by a function call and an ASCII string, which is easily
readable. Administrative queries from the user side to local
emulation managers 26 are handled, as far as possible, without any
interruption of the emulation 34. Generally one such emulation 34
may have one or several protocol layers.
[0026] FIG. 3 shows a local emulation manager 26 that is connected
to the emulation interface layers 32 of the individual emulations
34 via an input 38, and to the global emulation manager 16 via an
input 40 for taking over functions, for installing and configuring
the protocol stack, and for events that come from outside, i.e.,
from the user. Via an output 42 the emulation manager 26 may
initialize, deinitialize and start an emulation.
[0027] FIG. 4 shows an emulation 34 that may have one or several
protocol layers. Via standardized SAPs links to an interface
located at a higher level via line 44, to an interface located at a
lower level via line 46, and to the emulation management layer 33
via line 48 are possible. Here interface is understood as further
protocol layers, emulations 34 and script interpreters.
[0028] The SAPs of the individual interfaces may be connected by
the user in any way. For details of the realization of the link,
see below. Administrative commands to the administration instance,
i.e., the emulation management layer 33 formed from the global and
local emulation managers 16, 26, are formulated by readable ASCII
strings. The following keywords are defined for a request
string:
[0029]
create<emulname>[,<createname>[,<searchpath>]]
[0030] This keyword is used to request the interface layer 32 to
load an emulation 34 known as <emulname>. If the parameter
<createname> is given, the emulation gets this name within
the emulation pipeline, else the emulation has the name
<emulname> within the pipeline. No emulation has a name with
a digit as the first character because this is an identification
for an output or input link to a physical interface. If the
parameter <searchpath> is given, an object module is searched
within the directory of the given search path.
[0031] unload<emulname>
[0032] Within the emulation pipeline an emulation, which is named
in the pipeline by the given name <emulname>, is searched
for. If the emulation is found, it is deleted from the pipeline
[0033]
connect<emulname1>.<output1>,<emulname2>.<inpu-
t2>
[0034]
connect<logical_link_identifier>,<emulname2.<input2>
[0035]
connect<emulname1>.<output1>,<logical_link_identifie-
r>
[0036]
connect<boardnumber1>.<boardlink1>,<emulname2>.&l-
t;input2>
[0037]
connect<emulname1>.<output1>,<boardnumber2>.<b-
oardlink2>
[0038]
connect<boardnumber1>.<boardlink1>,<logical_link_ide-
ntifier>
[0039] connect<logical_link_identifier>,
<boardnumber2>.<bo- ardlink2>
[0040] The connect keyword is used to make connections between:
[0041] an output of an emulation and an input of another
emulation;
[0042] a logical link of a physical interface (referenced by the
logical input link identifier as a number) to an input of an
emulation;
[0043] an output of an emulation to a logical output link of a
physical interface (referenced by the logical link identifier as a
number);
[0044] an interboard connection (that has the local board number
and a link number 0 . . . 31 of the board);
[0045] an output of an emulation to an interboard connection
(having the local board number and a link number for the
board);
[0046] an interboard connection (having the local board number and
a link number to the board) to a logical output link of a physical
interface (referenced by the logical link identifier as a
number);
[0047] a logical link of a physical interface (referenced by a
logical input link identifier as a number) to an interboard
connection (having the local board number and a link number of the
board).
[0048] Note that no emulation has a name with a digit as the first
character because this is an identification for an output or input
link to the physical interface.
[0049] disconnect<emulname>.<output>
[0050] disconnect<logical_link_identifier>
[0051] disconnect<boardnumber>.<boardlink>
[0052] The disconnect keyword is used to remove an existing
connection which is outgoing from
[0053] one emulation, e.g. going to another emulation;
[0054] a logical link referenced by a logical link identifier as a
number;
[0055] an interboard connection by the number of the board and the
interboard link.
[0056] Only the originator of the connection has to be given.
[0057]
config<emulname>.<parametername>=<value>
[0058] This keyword is used to configure an emulation. The name of
the emulation is given by <emulname>, the parameter of the
emulation that has to be configured is given by
<parametername>, and the value to be put into the parameter
is given by <value>.
[0059] query<emulname>.<parametername>
[0060] This keyword is used to ask the emulation management layer
33 for the value of a parameter that is used by the given
emulation. The name of the emulation is given by <emulname>
and the name of the parameter is given by <parametername>.
The emulation management layer sends a response message consisting
of an ASCII string to the querying application.
[0061] list
[0062] The list keyword is used to request the emulation management
layer 33 to send back a list of emulation pipelines. The emulation
management layer sends the response message consisting of a
readable ASCII string to the asking application.
[0063] show[<emulname>]
[0064] This command is used to get information concerning one
emulation pipeline. It is possible to give the name of an emulaton
<emulname> of the pipeline, then the response information is
reduced to the one emulation. The response to this command has the
following format:
[0065] <modulename> loaded as <emulationname>
[0066] <outputname1>.fwdarw.<destination1>
[0067] . . .
[0068] <inputname1>.rarw.<source1>
[0069] . . .
[0070] The emulation that is running using the module of the name
<modulename> is named a <emulationname> within the
pipeline.
[0071] The emulation has several output links and input links.
These links are named <outputname1> . . . <outputnameX>
and <inputname1> , , , <inputnameX>. Each output is
concatenated to a destination. The destination is declared with
<destination1> . . . <destinationX>. Each input link is
concatenated with a source line. These source lines are names
<source1> . . . <sourceX>.
[0072] The definition of a destination may have one of the
following syntax formats:
[0073] <destinationemulation>.<destinationinput>
[0074] LDD (=Logical Data Destination)
[0075] AP (=application that may be connected)
[0076] If the destination of the output link is an emulation, then
the name of the remote emulation (destinationemulation> and the
name of the remote input <destinationinput> are given. If the
output link is directly coupled to the application or the logical
data destination, this is given by he words LDD or AP.
[0077] The definition of a source may have one of the following
syntax formats:
[0078] <sourceemulation>.<sourceoutput>
[0079] LDS (=Logical Data Source)
[0080] AP
[0081] If the source to the input link is an emulation, then the
name of the remote emulation <sourceemulation> and the name
of the remote output <sourceoutput> are given. If the input
link is directly coupled to the application or the logical data
source, this is given by the words LDS or AP.
[0082] menu<emulname>
[0083] This command is used to get information concerning the
configuration and query functionalities of the emulation with the
name <emulname>. The given information may be used to show a
comfortable menu structure to the user. The responses to this
command define variables and submenus. Variables or submenu
declarations are separated into lines. The responses to this
command have the following keywords:
[0084] <name>:
[0085] type=int<min> . . . <max>;
[0086] access=<access>;
[0087] default=<default>;
[0088] The variable is of type integer. The name of the variable is
given by <name>. The integer value of the variable is in the
range of <min> to <max>.
[0089] <name>:
[0090] type=enum<value1>/<value2>/ . . . ;
[0091] access=<access>;
[0092] default=<default>;
[0093] The variable is of type enumerate. The name of the variable
is given by <name>. The possible values of the variable are
given with the list of <value1>, <value2>, etc.
[0094] <name>:
[0095] type=string<length>;
[0096] access=<access>;
[0097] default=<default>;
[0098] The variable is a string of ASCII characters. The name of
the variable is given by <name>. The length of the string is
given by <length>.
[0099] <name>:
[0100] type=numbers<length>;
[0101] access=<access>;
[0102] default=<default>;
[0103] The variable is a string of number (`0` . . . `9`)
characters. The name of the variable is given by <name>. The
length of the string is given by <length>.
[0104] <name>:
[0105] type=hexnumbers<length>;
[0106] access=<access>;
[0107] default=<default>;
[0108] The variable is a string of hexadecimal number (`0` . . .
`9`,`a` . . . `f`) characters. The name of the variable is given by
<name>. The length of the string is given by
<length>.
[0109] <name>:
[0110] type=telnumbers<length>;
[0111] access=<access>;
[0112] default=<default>;
[0113] The variable is a string of telephone number (`0` . . .
`9`,`a` . . . `z`,`#`,`*`) characters. The name of the variable is
given by <name>. The length of the string is given by
<length>.
[0114] <name>:
[0115] type=bitstring<length>;
[0116] access=<access>;
[0117] default=<default>;
[0118] The variable is a number of bits. Each bit is modified by
one digit (`0` or `1`) of a given string. The length of the string
is given by <length>.
[0119] Each variable is associated with an access class
<access> of the type `rd` (read only), the type `wr` (write
only) or the type `rdwr` (read and write) that is given as a
parameter after the variable type declaration. Every variable may
be arranged as a field. In this case the name of the variable is
extended by an index declaration. Each index declaration is
enclosed in brackets `[`and`]`. The type of an index specification
may be a normal integer number or an enumeration number.
Definition:
[0120] <namestring>[int<min> . . . <max>]:
[0121] In this case the index to the variable name
<namestring> is of the type integer. The range of the
variable is given by <min> . . . <max>.
[0122] <namestring>[enum<value1>/<value2>/ . . .
]:
[0123] In this case the index to the variable of the name
<namestring> is of the type enumerate. The possible values of
the index are given as a list of <value1>, <value2> . .
.
[0124] It is possible to allocate a structure of submenus into the
menu. The syntax for a submenu is of the following format:
[0125] <name>: {
[0126] [<variabledeclarations>]
[0127] [<menudeclarations>]
[0128] }
[0129] The name of the submenu is given by <name>. The
variables of further submenus belonging to the actual declared
submenu are enclosed into brackets `{`and`}`.
[0130] bindreq<emulname>.<input>[, <data>]
[0131] This command is used to pass a bind request primitive to an
input of an emulation. The emulation is given by its name
<emulname> and by its input link <input>. The primitive
is filled with data of the optional parameter <data> in
hexadecimal format.
[0132]
sendreq<emulname>.<input>,<primid>[,<data>]
[0133] This command is used to pass a primitive to an input of an
emulation. Ths emulation is given by its name <emulname> and
by its input link <input>. It generates a primitive with the
given identifier <primid> and the primitive is filled with
data of the optional parameter <data> in hexadecimal
format.
[0134] exec<filename>
[0135] This command is used to request the emulation management
layer 33 to read the command string for the upper interface from
the file given by the <filename>.
[0136] board<boardnumber>:<request>
[0137] This command is used to route a request <request> to
the board given by <boardnumber>.
[0138] As mentioned above the administration instance formed by the
local and global emulation managers 16, 26, hereinabove also
referred to as the emulation management layer 33, provides a
generic communication and administration mechanism for emulation.
The purpose of this administration instance is to load into an
abstract structure, i.e., the emulation pipeline, the protocol
emulations, the script interpreters and the control components
required for the protocol stack or the desired part of the protocol
stack and to connect them. This loading and connecting may be
controlled by the user at the protocol tester independently and
without in-depth knowledge of the protocol system structure. For
this control a GUI or text file may be used.
[0139] The description files assigned to the protocol layers or
protocol emulations allow the GUI to display information on the
protocol emulations. This information includes:
[0140] a general description of the protocol emulation, the script
interpreter or the control component;
[0141] the names of all existing SAPs for the input and output
directions;
[0142] a description of each individual SAP;
[0143] a list of the primitives that may be exchanged via each
individual SAP;
[0144] a description of all primitives;
[0145] a list of the parameters for each individual primitive;
[0146] a description of all parameters used in primitives;
[0147] a description of the variables, constants and actions that
may be set, queried or started within the protocol emulation, with
this description also enabling the grouping into menus, submenus
and fields;
[0148] and additional details for statistical functions.
[0149] The generic concept of the administration instance and the
information from the description files allow the user to put
together in a comfortable manner on the test system modules for the
desired applications. This flexibility increases the use value of
the protocol test system for many applications, saves considerable
development efforts, and reduces delays in the test progress.
[0150] The information made available in the description files may
also be used by other tools in the protocol tester to better guide
the user and support the user with protocol-specific knowledge when
the test cases are created. The description file that is available
for each protocol emulation, for each script interpreter and for
each control element is in the text format. The following is an
excerpt from such a file, the contents of which are easily
disclosed to an expert in the field of the present invention:
[0151] [GENERAL]
[0152] Name=ss7isup1;
[0153] Description="ISDN User Part";
[0154] Type=Emulation;
[0155] {STATISTIC]
[0156] Statistic Module: type=enum ON/OFF; access=rdwr;
default=OFF;
[0157] Statistic Interval: type=int 1 . . . 3600; access=rdwr;
default=10;
[0158] [MENU]
[0159] General: {
[0160] Version: type=string 80; access=rd; comment="";
statistic=N/A;
[0161] default="SS7 ISUP V1.00";
[0162] State: type=enum NOT_LOADED/IDLE/ACTIVE/WARNING/ERROR/NO_A
NSWER;
[0163] access=rd; comment=""; statistic=N/A;
default=NOT_LOADED;
[0164] State Description: type=string 256; access=rd; comment="";
statistic=N/A; default=emulation not loaded;
[0165] Standard: type=enum White Book ISUP; access=rdwr;
comments="";
[0166] statistic=N/A; default=White Book ISUP;
[0167] }
[0168] Networks: {
[0169] Network nat0: {
[0170] use: type=enum no/yes; access=rdwr; comment="";
statistic=N/A; default=no;
[0171] NI: type enum nat0/nat1/int0/int1; access=rd; comment="";
statistic=N/A; default=nat0;
[0172] OPC: type=int 0 . . . 16383; access=rdwr; comment="";
statistic=N/A; default=0;
[0173] }
[0174] [SAPs]
[0175] Network nat0: mode=in; location=lower; comment="";
asps=UDAT_IND
[0176] Network int1: mode=in; location=lower; comment="";
[0177] Call Terminal: mode=in; location=upper; comment="";
asps=DATA_REQ;
[0178] Maintenance Terminal: mode=in; location=upper; comments="";
asps=RESET_REQ, RESET_RES, CONTRECHECK_REQ, STOP_REQ, BLOCKING_REQ,
BLOCKING_RES, UNBLOCKING_REQ, UNBLOCKING_RES;
[0179] Network nat0: mode=out; location=lower; comment="";
asps=UDAT_REQ;
[0180] Network int1: mode=out; location=lower; comment="";
asps=UDAT_REQ;
[0181] Call Terminal: mode=out; location=upper; comment="";
asps=DATA_IND;
[0182] Maintenance Terminal: mode=out; location=upper; comment="";
Asps=RESET_IND, RESET_CNF, CONTRECHECK_CNF, STOP_CNF, BLOCKING_IND,
BLOCKING_CNF, UNBLOCKING_IND, UNBLOCKING_CNF, STARTRESET_IND,
CALLFAILURE_IND, MAINTENANCE_IND;
[0183] [ASPs]
[0184] RESET_REQ: id=0X0001; comment=""; para1=N1; para2=DPC;
para3=CIC;
[0185] RESET_RES: id=0x0002; comment=""; para1=N1; para2=DPC;
para3=CIC;
[0186] CONTRECHECK_REQ: id=0x0003; comment=""; para1=N1; para2=DPC;
para3=CIC;
[0187] [PRMs]
[0188] N1: comment=""; size=2; values=nat0=2/nat1=3/int0=0/int1=1;
default=2
[0189] DPC: comment=""; size=2;
[0190] OPC: comment=""; size=2;
[0191] CIC: comment=""; size=2;
[0192] As part of the GUI of the embodiment example an editor is
made available that supports a user in putting together the
protocol stack. FIG. 5 shows a first user interface screen of the
editor, the so-called Diagram View screen, as an example of a
generically functioning user interface. On the right-hand side of
the user interface screen the user may select control functions
with which a protocol stack may be created. On the left-hand side
of the user interface screen one may see a protocol stack, with the
layer ss7isup1 having two layers arranged above it in a parallel
fashion, namely layers wss7isupterm1 and ss7isupmaint1.
[0193] FIG. 6 shows a second user interface screen of the protocol
stack editor, which is the Parameter View user interface screen.
Here variables, constants and actions of protocol layer emulations
may be processed. The window in the left part of the screen shows
first a stack directory that has various protocol layers, such as
ss7mtp2a, ss7mtp3a, ss7isup1, etc. arranged at a lower level.
Within each layer several directories may be selected, such as
General that covers general aspects, Timers for time markers and
Actions for specific actions. For layer ss7mtp3a the individual
SAPs are in the layer 4 sub-directory. Under layer ss7isupmaint1
primitives may be selected. The two partial windows on the
right-hand side show information of SAP(0) of layer 4 of the
protocol layer ss7mtp3a.
[0194] FIG. 7 shows another representation of the protocol stack.
From top to bottom the following layers are linked:
[0195] TCP/IP 50;
[0196] SNDCP (subnet dependent convergence protocol) 52;
[0197] LLC (logical link layer) 54;
[0198] In parallel with SNDCP 52 and LLC 54: GMM/SM (GPRS mobility
management and session control) 56;
[0199] BSSGP (bay station system GPRS protocol) 58;
[0200] NS (network service) 60;
[0201] FR (frame relay) 62.
[0202] The protocol stack shown is taken from the Gb interface of
GPRS. Protocol layers FR, NS, BSSGP and LLC are grouped together on
the protocol tester within a single emulation named
LLC/BSSGP/NS/FR. Protocol layer GMM/SM is simulated by way of a
FORTH script. The TCP/IP packets are stored in a load generator
that is capable of continuously sending packets.
[0203] FIG. 8 shows in more detail the interactions of the
individual protocol layers of the protocol stack shown in FIG. 7.
To create the protocol stacks of FIGS. 7 and 8 one only has to give
the following administrative commands to the administration
instance:
[0204] create LLC1
[0205] create SNDCP
[0206] create LOAD
[0207] create FORTH1197, FORTH
[0208] connect LOAD.Load,SNDCP.SNDCPuser
[0209] connect SNDCP.SNDCPuser,LOAD.Load
[0210] connect LOAD.Ctrl,FORTH.In2
[0211] connect FORTH.Out2,LOAD.Ctrl.
[0212] connect SNDCP.LLC,LLC1.LLuser0
[0213] connect LLC1.LLuser0,SNDCP.LLC
[0214] connect SNDCP.SNSM,FORTH.In1
[0215] connect FORTH.Out1,SNDCP.SNSM
[0216] connect LLC1.MMuser0,FORTH.In0
[0217] connect FORTH.Out0,LLC1.MMuser0
[0218] connect LLC1.Lower,1
[0219] connect 0,LLC1.Lower
[0220] Thus the present invention provides a method of creating
protocol stacks that is flexible and does not require extensive
knowledge by the user of the protocols involved.
* * * * *