Integrated Services Digital Network (ISDN); Signalling System No.7; Message Transfer Part (MTP) protocol Tester (MT)

T/S 43-04 [CE]

Digitalno omrežje z integriranimi storitvami (ISDN) - Signalizacija št. 7 - Preskuševalec protokola (MT) sporočilno-prenosnega dela (MTP)

General Information

Status
Published
Publication Date
07-Oct-1997
Current Stage
12 - Completion
Due Date
10-Oct-1997
Completion Date
08-Oct-1997

Buy Standard

Standard
ETS 300 346:1998
English language
40 pages
sale 10% off
Preview
sale 10% off
Preview
e-Library read for
1 day

Standards Content (Sample)

SLOVENSKI STANDARD
SIST ETS 300 346:1998
01-oktober-1998
'LJLWDOQRRPUHåMH]LQWHJULUDQLPLVWRULWYDPL ,6'1 6LJQDOL]DFLMDãW
3UHVNXãHYDOHFSURWRNROD 07 VSRURþLOQRSUHQRVQHJDGHOD 073
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)
SIST ETS 300 346:1998 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------

SIST ETS 300 346:1998

---------------------- Page: 2 ----------------------

SIST ETS 300 346:1998
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: secretariat@etsi.fr
Tel.: +33 4 92 94 42 00 - Fax: +33 4 93 65 47 16
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: 3 ----------------------

SIST ETS 300 346:1998
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: 4 ----------------------

SIST ETS 300 346:1998
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: 5 ----------------------

SIST ETS 300 346:1998
Page 4
ETS 300 346: October 1997
Blank page

---------------------- Page: 6 ----------------------

SIST ETS 300 346:1998
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: 7 ----------------------

SIST ETS 300 346:1998
Page 6
ETS 300 346: October 1997
Blank page

---------------------- Page: 8 ----------------------

SIST ETS 300 346:1998
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: 9 ----------------------

SIST ETS 300 346:1998
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: 10 ----------------------

SIST ETS 300 346:1998
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: 11 ----------------------

SIST ETS 300 346:1998
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: 12 ----------------------

SIST ETS 300 346:1998
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: 13 ----------------------

SIST ETS 300 346:1998
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: 14 ----------------------

SIST ETS 300 346:1998
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: 15 ----------------------

SIST ETS 300 346:1998
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
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.