SIST ETS 300 346:1998

• Abstract:

  T/S 43-04 [CE]

• Status: Published
• Publication Date: 30-Sep-1998
• ICS: 33.080 - Integrated Services Digital Network (ISDN)
• Technical Committee: SPS - Signalling protocols and switching
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 01-Oct-1998
• Due Date: 01-Oct-1998
• Completion Date: 01-Oct-1998
• Ref Project: ETSI ETS 300 346 ed.1 (1997-10) - Integrated Services Digital Network (ISDN); Signalling System No.7; Message Transfer Part (MTP) protocol Tester (MT)

SIST ETS 300 346:1998 is the Slovenian adoption of ETS 300 346 Edition 1 from ETSI. It specifies the Message Transfer Part (MTP) protocol Tester (MT) used to support testing of Signalling System No.7 (SS7) in Integrated Services Digital Network (ISDN) environments. In practice, it tells implementers and testers how the MT behaves, how it exchanges test messages, and how it reacts during setup, test execution, and termination.

What does SIST ETS 300 346:1998 specify?

SIST ETS 300 346:1998 specifies an MTP protocol tester for use when testing the MTP of SS7. The document is written as a guide for testing MTP implementations and for generating and checking test traffic between two signalling points.

The scope is limited to MTP implementations conforming with ETS 300 008-1, provided they expose the equivalent MTP primitives and support the Service Indicator (SI) used by the MT. The document also notes that applicability to broadband MTPs according to EN 301 004-1 is outside its scope.

The standard is organized into six clauses:

• Clause 1 gives the scope.
• Clause 2 lists normative references.
• Clause 3 gives a definition.
• Clause 4 lists abbreviations.
• Clause 5 gives the general architectural background.
• Clause 6 contains the MT functions, procedures, state transition matrix, message formats, timer values, and interface requirements.

Annex A gives procedure SDL diagrams, and Annex B gives a bibliography.

What are the key requirements of SIST ETS 300 346:1998?

SIST ETS 300 346:1998 defines how the MT generates, turns around, checks, and terminates test traffic. The most important practical point is that the tester is not just a message sender - it is a controlled test function with defined setup, supervision, and shutdown behavior.

The MT has two roles: generator and turn-around

Clause 6.1 defines two functional roles. In the generator role, the tester creates TEST TRAFFIC messages and checks the returned traffic for loss, duplication, missequencing, and possibly corruption. In the turn-around role, the tester receives messages, verifies them, and sends them back.

This matters because the same tester can support both sides of a test, but each side has different responsibilities. A buyer or engineer needs to know whether the implementation supports both roles and how it reports results.

One test sequence is tied to one remote point and one local SAP instance

Clause 6.1.5 identifies a test sequence by the remote Point Code (PC) and the local MTP Service Access Point (SAP) instance. The same clause says only one test at a time is possible between two signalling points.

That means the tester is intended for controlled point-to-point verification, not multiple simultaneous tests between the same pair of signalling points. This affects lab planning, acceptance testing, and operational use.

Test traffic uses fixed sequencing rules and a single SLS value

Clause 6.1.6 states that all test traffic messages in one test sequence use the same Signalling Link Selection (SLS) value. The purpose is to keep delivery in sequence through the MTP and to restrict the sequence to one link from each linkset used.

In practice, the test setup must consider the effect on available message rate, because the sequence is intentionally constrained. The standard also notes that the return path may use different links or linksets, depending on implementation.

Test setup, acceptance, and refusal are explicitly controlled

Clause 6.2.1 defines the setup procedure. The generator starts with a test request, initializes counters, starts timer T1, and sends a TEST REQUEST. The turn-around side checks whether a test is already running, asks its Control Function, and then either sends TEST ACCEPTANCE or TEST REFUSAL.

This matters because setup is not automatic. The implementation must handle clashes, local refusal conditions, and congestion handling instructions from the Control Function.

The tester reacts to pauses, resumes, and status indications

Clause 6.2.4 describes reactions to MTP-PAUSE, MTP-RESUME, and MTP-STATUS. If the destination becomes unavailable, the generator may pause the test, stop generating messages, and wait for recovery. When MTP-RESUME arrives, a held test resumes. For MTP-STATUS, the cause can include signalling network congestion or remote user inaccessible, unequipped, or unknown.

This is important for real networks, because tests can be suspended or terminated by network state. The Control Function also decides whether congestion should terminate the test or be reported and ignored.

Control messages and TEST TRAFFIC messages have defined headers

Clause 6.4 defines header codes and message groups. The standard separates test control messages from TEST TRAFFIC messages, and it specifies the control message types TEST REQUEST, TEST ACCEPTANCE, TEST REFUSAL, TEST TERMINATION REQUEST, and TEST TERMINATION ACKNOWLEDGE.

For implementers, this means the tester must encode and decode the right message family and respond consistently to each control message. Clause 6.4 also defines the TEST TRAFFIC format, including the serial number and optional generator-dependent information.

Timers and interface signals are part of the behavior

Clause 6.4.2 defines timers T1, T2, T3, and T4 for setup, test duration, termination, and turn-around guard timing. Clause 6.4.3 then outlines the interface signals between the MT and the Control Function, including test request, acceptance, refusal, termination, error indication, and traffic error indication.

In practice, these signals are what an operator or test system uses to start, supervise, and document the test.

What terms does SIST ETS 300 346:1998 define?

• MTP Service Access Point instance (SAPi) - the interface between an MTP user and the MTP used to access a particular MTP network.
• Message Transfer Part (MTP) - the SS7 part that carries signalling messages between network points.
• Message Signal Unit (MSU) - the message unit used by MTP to carry signalling information.
• Point Code (PC) - the addressing code for a signalling point in SS7.
• Generating Point Code (GPC) - the PC of the tester performing the generator role.
• Turn-around Point Code (TPC) - the PC of the tester acting in the turn-around role.
• Signalling Link Selection (SLS) - the parameter used to select the signalling link for the test traffic sequence.
• Service Indicator (SI) - the indicator that identifies the MTP user part carried by the message.

Who uses SIST ETS 300 346:1998?

SIST ETS 300 346:1998 is used by telecom engineers, signalling test specialists, and network operators working with ISDN and SS7. It is relevant when testing MTP implementations, checking routeing and bidirectionality, or running validation and compatibility tests between implementations.

Quality teams and buyers use it to judge whether a tester or test function supports the message formats, timers, control signals, and network-state reactions needed for SS7 MTP testing. It is also relevant where TMN and OMAP control functions supervise tests and collect results.

What changed in SIST ETS 300 346:1998 from the previous edition?

SIST ETS 300 346:1998 is identical with ETS 300 346 Edition 1.

Which standards are used with SIST ETS 300 346:1998?

• ETS 300 008-1 - provides the MTP protocol specification that the tester is built to support.
• ITU-T Recommendation Q.750 - provides the management architecture background for the relationship between the MT and SS7 management.
• ETS 300 008 - is cited in the scope as the source for MTP specification and architectural context.
• ITU-T Recommendation I.320 - provides the ISDN protocol reference model mentioned in the general background.
• ITU-T Recommendation I.321 - provides the B-ISDN protocol reference model mentioned in the general background.

What does the SIST ETS 300 346:1998 document contain?

The document contains the MT architectural model, functional roles, setup and termination procedures, and the state transition matrix that governs behavior in each test state. It also includes the message groups, header codes, message formats, and timer values used by the tester.

Table 1 gives the state transition matrix, and Table 2 summarizes the interface requirements between the MT and the Control Function. Annex A provides SDL diagrams of the procedures, which are useful for implementation and conformance work. Annex B lists related references for background and interpretation.

SLOVENSKI STANDARD
01-oktober-1998
'LJLWDOQRRPUHåMH]LQWHJULUDQLPLVWRULWYDPL,6'16LJQDOL]DFLMDãW
3UHVNXãHYDOHFSURWRNROD07VSRURþLOQRSUHQRVQHJDGHOD073
Integrated Services Digital Network (ISDN); Signalling System No.7; Message Transfer
Part (MTP) protocol Tester (MT)
Ta slovenski standard je istoveten z: ETS 300 346 Edition 1
ICS:
33.080 Digitalno omrežje z Integrated Services Digital
integriranimi storitvami Network (ISDN)
(ISDN)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN ETS 300 346
TELECOMMUNICATION October 1997
STANDARD
Source: SPS Reference: T/S 43-04 [CE]
ICS: 33.020
Key words: ISDN, SS7, MTP, testing
Integrated Services Digital Network (ISDN);
Signalling System No.7;
Message Transfer Part (MTP) protocol Tester (MT)
ETSI
European Telecommunications Standards Institute
ETSI Secretariat
Postal address: F-06921 Sophia Antipolis CEDEX - FRANCE
Office address: 650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCE
X.400: c=fr, a=atlas, p=etsi, s=secretariat - Internet: [e-mail]
Tel.: [phone] - Fax: [phone]
Copyright Notification: No part may be reproduced except as authorized by written permission. The copyright and the
foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 1997. All rights reserved.

Page 2
ETS 300 346: October 1997
Whilst every care has been taken in the preparation and publication of this document, errors in content,
typographical or otherwise, may occur. If you have comments concerning its accuracy, please write to
"ETSI Editing and Committee Support Dept." at the address shown on the title page.

Page 3
ETS 300 346: October 1997
Contents
Foreword .5
1 Scope .7
2 Normative references.7
3 Definitions.7
4 Abbreviations.7
5 General.8
6 MTP Tester (MT).10
6.1 Functions .10
6.1.1 Objectives and scope.10
6.1.2 Main functions .11
6.1.3 Architectural model.11
6.1.4 Functional roles .11
6.1.4.1 Generator role.11
6.1.4.2 Turn-around role.11
6.1.5 Identification of test sequences at a node.11
6.1.6 Message rate considerations .12
6.2 Procedures.12
6.2.1 Test set-up .12
6.2.1.1 Test request.12
6.2.1.2 Test acceptance .12
6.2.1.2.1 By the turn-around tester .12
6.2.1.2.2 By the generator .13
6.2.1.3 Test refusal.13
6.2.1.4 Timer T1 expiry.13
6.2.2 Procedures during the test .13
6.2.2.1 At the generator.13
6.2.2.2 At the turn-around tester.13
6.2.2.3 Response to missequencing .13
6.2.3 Test termination.14
6.2.3.1 By the generator .14
6.2.3.2 By the turn-around tester.14
6.2.3.3 Test termination acknowledgement.14
6.2.4 Reaction to MTP management primitives and MTP restart .14
6.2.4.1 MTP-PAUSE caused by unavailability of a destination.14
6.2.4.1.1 At the generator side.14
6.2.4.1.2 At the turn-around side .15
6.2.4.2 MTP-RESUME.15
6.2.4.3 MTP-STATUS.15
6.3 State transition matrix .15
6.4 Formats and codes.24
6.4.1 Header codes.24
6.4.1.1 Test control.24
6.4.1.2 Test traffic.24
6.4.2 Timers .25
6.4.3 Interface requirements .25
Annex A (informative): Procedure SDL diagrams .26
Annex B (informative): Bibliography.39
History.40

Page 4
ETS 300 346: October 1997
Blank page
Page 5
ETS 300 346: October 1997
Foreword
This European Telecommunication Standard (ETS) has been produced by the Signalling Protocol and
Switching (SPS) Technical Committee of the European Telecommunications Standards Institute (ETSI).
This ETS details exceptions and clarifications to ITU-T Recommendation Q.755 defining the protocol
testers to be used as an aid when performing validation testing of an implementation or compatibility
testing between implementations.
Transposition dates
Date of adoption: 19 September 1997
Date of latest announcement of this ETS (doa): 31 January 1998
Date of latest publication of new National Standard
or endorsement of this ETS (dop/e): 31 July 1998
Date of withdrawal of any conflicting National Standard (dow): 31 July 1998

Page 6
ETS 300 346: October 1997
Blank page
Page 7
ETS 300 346: October 1997
1 Scope
This European Telecommunication Standard (ETS) specifies the Message Transfer Part (MTP) protocol
Tester (MT) to be used as an aid when testing the MTP of Signalling System No.7.
This tester applies to all MTP implementations conforming with ETS 300 008-1 [1] regardless of its date of
issue, as long as they provide the equivalent of the MTP primitives, and the Service Indicator (SI) of the
MT is supported.
This ETS draws upon ITU-T Recommendation Q.750 [2] for architectural considerations of the
relationship between the MT and Signalling System No.7 management (OMAP), and upon
ETS 300 008 [1] for the specification of the MTP.
NOTE: The applicability of the MTP tester to broadband MTPs according to EN 301 004-1 is
outside the scope of this ETS.
2 Normative references
This ETS incorporates by dated and undated reference, provisions from other publications. These
normative references are cited at the appropriate places in the text and the publications are listed
hereafter. For dated references, subsequent amendments to or revisions of any of these publications
apply to this ETS only when incorporated in it by amendment or revision. For undated references the latest
edition of the publication referred to applies.
[1] ETS 300 008-1: "Integrated Services Digital Network (ISDN); Signalling System
No.7; Message Transfer Part (MTP) to support international interconnection
(Part 1: Protocol specification)".
[2] ITU-T Recommendation Q.750 (1993): "Overview of Signalling System No.7
management".
3 Definitions
For the purposes of this ETS, the following definition applies:
MTP Service Access Point instance (SAPi): The interface between an MTP user and the MTP, used to
access a particular MTP network.
4 Abbreviations
For the purposes of this ETS, the following abbreviations apply:
AE Application Entity
ASE Application Service Element
CF Control Function
DPC Destination PC
GPC Generating PC
ISDN Integrated Services Digital Network
ISUP ISDN User Part
LME Level Management Entity
LMI Level Management Interface
MAP Mobile Application Part
MIB Management Information Base
MSU Message Signal Unit
MT MTP protocol Tester
MTP Message Transfer Part
OMAP Operations, Maintenance and Administration Part
OMASE OMAP ASE
OPC Originating PC
OSI Open Systems Interconnection
PC Point Code
Page 8
ETS 300 346: October 1997
SAP Service Access Point
SAPi SAP instance
SCCP Signalling Connection Control Part
SDL Specification and Description Language
SI Service Indicator
SIF Signalling Information Field
SLS Signalling Link Selection
SP Signalling Point
SSNo.7 Signalling System No.7
TC Transaction Capabilities
TMN Telecommunications Management Network
TPC Turn-around PC
TUP Telephony User Part
5 General
The protocol tester may be used as an aid when testing the Message Transfer Part (MTP) of Signalling
System No.7 between two implementations. The tester's main function is simulation of an ordinary user
part, as seen from the MTP, for the generation of test traffic.
ITU-T Recommendations I.320 and I.321 specify the ISDN protocol reference model to be used. User
plane (U-plane), Control plane (C-plane) and Management plane (M-plane) are identified. The layering
principles apply in each of these planes. The U-plane provides the user information flow transfer with
associated controls. The C-plane handles the call and connection control information. The M-plane is
divided into two portions, the Layer Management functions and the Plane Management functions. Plane
Management performs management functions related to a system as a whole, it provides co-ordination
between all the planes and has no layered structure. The Layer Management part of the M–plane contains
Layer Management Entities (LMEs). Each of these entities provides management functions relating to
resources and parameters residing in its associated protocol layer. Layer Management handles the
operation and maintenance information flows. The interface between adjacent layers within a plane and
between the Layer Management Entity and its associated layer have to be defined in terms of service
primitives. The interface between the Layer Management Entities and Plane Management does not need
to be specified, it is implementation dependent.
For Signalling System No.7, the Level Management Entity is defined by analogy with the Layer
Management Entity of ITU-T Recommendations I.320 and I.321. This is to account for the different
positions of the boundaries between Signalling System No.7 lower layers and those of Open Systems
Interconnection (OSI) (e.g. the upper part of the MTP is level 3 in Signalling System No.7, the SCCP is
level 4, but both would be within layer 3 if the OSI model strictly applied). For Signalling System No.7
MTP, the term LME is taken to mean "Level Management Entity".
Thus the MT is contained in the LME of the MTP (MTP LME).
In this ETS, the service primitives between MTP LME and the MTP are described, as well as the
procedures, the messages and the MT substructure. It is necessary to define the information flow across
the interface between the Plane Management (MIB) and the MT (shown as the lowest Level Management
Interface (LMI) in figure 1) and so this is done in terms of signals which are required to control the
concerned testing functions and report results (see figure 1, which is a copy of figure 5/Q.750).

Page 9
ETS 300 346: October 1997
AMI
AMI
SS N o. 7 M anagem ent P rocess e.g. Call Control
+ O M ASE-U ser MAP application services
S M S I O M -prim
AE
AE
TUP
ISD N
O
UP
LMI TT
M
LMI
A
ASEs
S
LMI
MIB
E
LME LME
LMI
TC TC LM E LM E
ASE ASE
LM I
(Note 6) (Note 6)
x
ST
SCCP (Level 4)
LME
LMI
y
MT
MTP
(Levels 1-3)
LME
LMI
T1158410-93/d07
For com m unication betw een
CCITT SS No. 7 nodes
NOTES
1  Dotted lines (but not boxes) denote direct management interfaces. Only the SMSI [see note 5 below  ] is realized with

primitives.
2    The LMI (Level Management Interface) is not a subject for standardization.
3    The AMI (Application Management Interface) is not a subject for standardization.
4    The items managed by OMAP can be regarded as conceptually resident in the MIB.
5    The SMSI is the systems management service interface, the OM primitives are defined for use over it for managed
object functions defined in Recommendation Q.753.
6    OSI layers 4, 5 and 6 are null in SS No. 7. TC forms the bottom of OSI layer 7, SCCP the top of OSI layer 3
(but is in SS No. 7 le.vel 4).
7    Interface x uses sub-system number to test the SCCP using the SCCP Tester (ST), interface y uses SIO to test the MTP
using the MTP Tester (M    The TC Test Responder (TT) has its own SSN, conceptually it resides in the OMAP LME.T).
8    The LME (Level Management Entity) is defined for management of and within each level of SS No. 7. This is
conceptually where each managed item resides as far as the level is concerned.
Figure 1: Signalling System No.7 management and internal configuration of a Signalling Point (SP)

Page 10
ETS 300 346: October 1997
6 MTP Tester (MT)
The MT is connected to the MTP as a user part, i.e. it is identified by a service indicator. It generates test
traffic messages (TEST TRAFFIC) containing a serial number (and possibly additional information) by using
MTP-TRANSFER request primitives, and the MTP converts these into Message Signal Units (MSUs), with
the TEST TRAFFIC in the Signalling Information Field (SIF). On reception of these messages a check is
performed to verify that the messages are delivered correctly (e.g. without loss, corruption, missequencing
or duplication).
Control function of OMAP in MIB (CF)
information flow denoted by lower case
Test Control MT
Message Message Turnaround
Generator Verification Function
MTP Specific Portion
Local MTP SAP instance
information flow denoted by upper case
MTP
NOTE 1: This model is not intended to constrain implementation.
NOTE 2: The Control Function (CF) of OMAP provides the management interface for the MT. It is used
to define the test traffic message contents, to start and stop tests, to determine the action on
congestion, and receive test results.
Figure 2: Architectural model of the MT
6.1 Functions
6.1.1 Objectives and scope
The main use of the MT is:
- a tool for performing routeing and bidirectionality tests for Signalling System No.7 in networks which
are in service. If such verification in the international network should be needed, the MT would be
the preferred message traffic generator.
The MT is also:
- a possible tool for validation testing when traffic generation is needed whilst performing tests.
However, other traffic generators may be used if required when performing validation tests;
- the possible message traffic generator for compatibility tests between different network operators.
NOTE: Caution is necessary in the case of a request to generate message traffic that might
cause an overload.
Page 11
ETS 300 346: October 1997
6.1.2 Main functions
The main function is the generation of bi-directional message test traffic, giving the possibility at the
receiving node of analysing the received test traffic (i.e. detection of missequencing, duplication or loss of
messages - verification of transfer delays and detection of message corruption is only possible on the
generating side). Errors may be introduced in the Signalling System No.7 network (only by external means
to the testers) during the transmission of message test traffic.
NOTE: Undefined or unexpected messages with SI = "MTP tester" received are discarded,
optionally with a report. For the purposes of this ETS, an unexpected message is one
that is not shown as input in a particular state in the Specification and Description
Language (SDL) diagrams or the state transition matrix.
6.1.3 Architectural model
The OMAP architectural model is as given in figure 1, the MT model is shown in figure 2.
The MT functions are located in the MTP Level Management Entity (LME), control of the MT is located
within the Management Information Base (MIB) (see ITU-T Recommendation Q.750 [2] for the network
management aspects).
6.1.4 Functional roles
There are two functional roles which are defined for the MTP tester:
- the tester generating the test traffic messages; and
- the tester turning them around.
It is possible for a tester to be generating test traffic messages towards one signalling point whilst
performing the turn-around role in another test to a different signalling point.
6.1.4.1 Generator role
When performing the generator role, a node uses the services of the various functional blocks within the
MT (see figure 2) in the following way. The Test Control function confirms that the remote end is ready
and able to start a test, then controls the duration and termination of the test. The Message Generator
function generates the appropriate TEST TRAFFIC messages at the rate requested in the test set-up
procedure. It also controls the compatibility between message length and the message rate requested.
The Message Verification function receives the TEST TRAFFIC messages returning from the turn-around
node and checks them for loss, missequencing and duplication. The generator role may also include a
check for message corruption and other generator node dependent checks. The MTP Specific Portion
deals with generating the MTP transfer primitives and handling the incoming MTP primitives. The Control
Function of OMAP in the MIB handles test requests from TMN, test supervision and control, and the
presentation and interpretation of test results.
6.1.4.2 Turn-around role
When performing the turn-around role, a node uses the services of the various functional blocks within the
MT (see figure 2) in the following way. The Test Control function controls the acceptance and supervision
of a test. TEST TRAFFIC messages arriving from the remote generator node are checked by the Message
Verification function before being returned to the generator via the Turnaround function. The MTP Specific
Portion again deals with the sending and receiving of MTP primitives. The Control Function of OMAP in
the MIB deals with the test acceptance, test control and the presentation and interpretation of results.
6.1.5 Identification of test sequences at a node
A particular test sequence is identified by the remote Point Code (PC) and local MTP Service Access
Point (SAP) instance. Thus it is only possible to have one test at a time running between two signalling
points. The Generating Point Code (GPC), the PC corresponding to the MTP SAP instance of the
generating tester, is included in the test messages as an additional security feature. Checks of the GPC
are for further study.
Page 12
ETS 300 346: October 1997
6.1.6 Message rate considerations
To secure delivery in sequence via the MTP all test traffic messages of the test sequence use the same
code value for the Signalling Link Selection (SLS) parameter. Thus they will use only one link from each
linkset utilized. This should be considered when defining the actual message rate. Although the same
value for the SLS parameter is used by the Turnaround function, it may or may not define the same link(s)
or linkset(s) in the backward direction as in the forward direction, as the load-sharing key is
implementation dependent.
6.2 Procedures
6.2.1 Test set-up
There are two phases during test set-up:
- test request; and
- either test acceptance or test refusal.
6.2.1.1 Test request
Once a test request has been received by the tester from the OMAP Control Function a check shall be
made to ensure that no test already exists between the GPC and Turn-around Point Code (TPC) in either
direction. If a clash is detected an error indication shall be returned to the Control Function with an
appropriate reason, the test already in place shall not be affected. A local test request may also be
refused due to local conditions (this is implementation dependent). If a valid request is received then the
necessary counters (messages sent counter and messages received counter) shall be initialized to zero,
and a guard timer T1 started to control the test set-up. A TEST REQUEST message shall then be sent to the
TPC.
The information provided by the Control Function shall include an indication of the required response to
the receipt of an MTP-STATUS, which has as its cause "network congestion". The required response may
be to terminate the test.
The Control Function might specifically request to report congestion indications, but continue the test. The
indication shall be passed in the TEST REQUEST message.
NOTE 1: The procedure to continue despite congestion should only be used with extreme
caution.
NOTE 2: In the event of a test request from the Control Function clashing with receipt of a TEST
REQUEST message, the first request to be processed by the MT shall determine the
action: if the test request from the Control Function is processed before the TEST
REQUEST message, both requests shall be refused; if the TEST REQUEST message is
processed first, the request from the Control Function shall be refused and the MT
shall wait for the response to the TEST REQUEST message from the Control Function.
6.2.1.2 Test acceptance
6.2.1.2.1 By the turn-around tester
On reception of a TEST REQUEST message a check shall be performed to ensure that a test with the
originating tester is not already in progress. If a test is found to be in progress then a TEST REFUSAL
message shall be sent, a test termination procedure shall be activated for the test already running, and a
report shall be made to the Control Function.
If no test is found to be in progress then the turn-around tester shall request the Control Function to start a
test with the respective PC. On receiving a negative response from the Control Function (e.g. due to local
conditions), a TEST REFUSAL message shall be sent. A positive response shall initiate the sending of a TEST
ACCEPTANCE message, test duration timer T4 to be started and the messages received counter to be
initialized to zero. The Control Function’s response can additionally request to terminate the test on
congestion, even though the test request message indicated to continue despite congestion.

Page 13
ETS 300 346: October 1997
6.2.1.2.2 By the generator
The reception of a TEST ACCEPTANCE message by the generator shall cause the termination of the set-up
timer T1. The Control Function shall be informed that a test is in progress, the generation of test traffic
shall begin and timer T2 shall be started. The action on congestion shall be to terminate the test if either
the local OMAP Control Function so requested, or it was indicated in the TEST ACCEPTANCE message.
6.2.1.3 Test refusal
If a TEST REFUSAL message is received then the set-up timer T1 shall be stopped. Any resources initialized
shall be released and a report made to the Control Function.
6.2.1.4 Timer T1 expiry
If timer T1 expires then any resources initialized shall be released and a report made to the Control
Function. It is assumed that the TEST REQUEST or TEST ACCEPTANCE or TEST REFUSAL were lost.
6.2.2 Procedures during the test
6.2.2.1 At the generator
On receipt of a TEST ACCEPTANCE message the test duration timer T2 shall be started and TEST TRAFFIC
messages shall be generated according to the rate information supplied by the Control Function. This is
modelled by a timer Tt in the state transition matrix and in the SDL diagrams. Before each message is
sent, the messages sent counter shall be incremented. The value of the count shall be given as the serial
number field within the TEST TRAFFIC message. The generating tester may place further information (e.g. a
time stamp) in the generator dependent information of the TEST TRAFFIC message, which shall be padded
to give the overall message length as requested during test set-up by the Control Function.
When TEST TRAFFIC messages are received at the generator, the messages can be checked by
comparing the GPC value with the tester's own PC. As messages are terminated at the MT the messages
received counter shall be incremented, and the message serial number checked as a means of sequence
validation (see also subclause 6.2.2.2). Any further checking may be done using the information in the
generator dependent information.
6.2.2.2 At the turn-around tester
A check is made to verify if a current test to the relevant PC is running for the incoming message’s
Originating Point Code (OPC) and the local MTP SAP instance. The GPC can be examined. If these
checks are successful, the message shall be turned around, otherwise the message shall be discarded.
The messages received counter shall be incremented and the serial number of the incoming message
checked for missequencing (e.g. against an expected sequence number variable, which is set to the last
received sequence number + 1). The generator dependent information shall not be modified.
The OPC and Destination Point Code (DPC) of the MTP-TRANSFER indication primitive shall then be
swapped, the SLS field and generator dependent information copied and the message formed into an
MTP-TRANSFER request primitive.
6.2.2.3 Response to missequencing
If, on checking the message serial number, an error is detected, a report shall be made to the Control
Function which shall include the message serial number, the expected serial number and its additional
information (if any).
Page 14
ETS 300 346: October 1997
6.2.3 Test termination
The test termination procedure shall be activated at the generator or turn-around node by either:
- the expiry of T2 (where the value of T2 was specified during test set-up by the Control Function); or
- a congestion indication, if the Control Function or the TEST REQUEST message or TEST ACCEPTANCE
message have instructed it not to be ignored (see subclause 6.2.1.2.2, last sentence); or
- a specific request from the Control Function; or
- the expiry of T4 (where the value of T4 was derived from T2 in the TEST REQUEST message).
The test termination procedure shall involve the sending of a TEST TERMINATION REQUEST message and the
starting of a test termination timer T3.
If a TEST TERMINATION REQUEST message is received then a TEST TERMINATION ACKNOWLEDGEMENT
message shall be sent and the test results and reason for its ending shall be sent to the Control Function.
6.2.3.1 By the generator
On receipt of a TEST TERMINATION ACKNOWLEDGEMENT message the test results and reason for the test
ending shall be sent to the Control Function and the counters cleared. If timer T3 expires then the Control
Function shall be informed and local resources released.
6.2.3.2 By the turn-around tester
After sending a TEST TERMINATION REQUEST the turn-around tester shall continue in its turn-around role
until either it receives a TEST TERMINATION ACKNOWLEDGEMENT or T3 expires. If T3 expires, the local
Control Function shall be informed and local resources released.
6.2.3.3 Test termination acknowledgement
Upon receipt of a TEST TERMINATION REQUEST, the local test shall be stopped and a TEST TERMINATION
ACKNOWLEDGEMENT sent.
6.2.4 Reaction to MTP management primitives and MTP restart
When the MTP restart procedure is terminated, the MTP indicates the end of MTP restart to all local MTP
users showing each signalling point's accessibility or inacc
...