SIST ETS 300 658:1998
(Main)Integrated Services Digital Network (ISDN); Signalling System No.7; Transaction Capabilities (TC) version 2; Test responder specification
Integrated Services Digital Network (ISDN); Signalling System No.7; Transaction Capabilities (TC) version 2; Test responder specification
To provide a TC tester specification suitable for conformance testing and possibly inter-operability of TC
Digitalno omrežje z integriranimi storitvami (ISDN) - Signalizacija št. 7 - Druga različica transakcijskih zmožnosti (TC) - Specifikacija preskušalnega odzivnika
General Information
Standards Content (Sample)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Integrated Services Digital Network (ISDN); Signalling System No.7; Transaction Capabilities (TC) version 2; Test responder specification33.080Digitalno omrežje z integriranimi storitvami (ISDN)Integrated Services Digital Network (ISDN)ICS:Ta slovenski standard je istoveten z:ETS 300 658 Edition 13SIST ETS 300 658:1998en01-IHEUXDU-19983SIST ETS 300 658:1998SLOVENSKI
STANDARD
SIST ETS 300 658:1998
EUROPEANETS 300 658TELECOMMUNICATIONSeptember 1996STANDARDSource: ETSI TC-SPSReference: DE/SPS-02030ICS:33.080Key words:ISDN, SS7, TC, testing, ASN.1Integrated Services Digital Network (ISDN);Signalling System No.7;Transaction Capabilities (TC) version 2;Test responder specificationETSIEuropean Telecommunications Standards InstituteETSI SecretariatPostal address: F-06921 Sophia Antipolis CEDEX - FRANCEOffice address: 650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCEX.400: c=fr, a=atlas, p=etsi, s=secretariat - Internet: secretariat@etsi.frTel.: +33 92 94 42 00 - Fax: +33 93 65 47 16Copyright Notification: No part may be reproduced except as authorized by written permission. The copyright and theforegoing restriction extend to reproduction in all media.© European Telecommunications Standards Institute 1996. All rights reserved.SIST ETS 300 658:1998
Page 2ETS 300 658: September 1996Whilst 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.SIST ETS 300 658:1998
Page 3ETS 300 658: September 1996ContentsForeword.51Scope.72Normative references.73Abbreviations.84Architecture.85TC testing user Application Service Element (ASE).95.1General principles.95.2Operations and Errors.96TC test management protocol.106.1Test management protocol PDUs.106.2Command structure.106.3Abstract syntax.116.4Procedures.116.4.1Procedure at the test system side.116.4.2Procedure at the test responder side.116.4.2.1Generic rules.116.4.2.2Handling of TMP-PDUs.126.4.2.3Execution of the wait command.136.4.2.4Execution of other commands.136.4.2.5Data echo.14Annex A (normative):TC test responder Operations and Errors.15Annex B (normative):Test management protocol PDUs.17Annex C (informative):Example of use of the TC test responder.19Annex D (informative):Implementing loops using the TC test responder.22Annex E (informative):Bibliography.23History.24SIST ETS 300 658:1998
Page 4ETS 300 658: September 1996Blank pageSIST ETS 300 658:1998
Page 5ETS 300 658: September 1996ForewordThis European Telecommunication Standard (ETS) has been produced by the Signalling Protocols andSwitching (SPS) Technical Committee of the European Telecommunications Standards Institute (ETSI).Transposition datesDate of adoption of this ETS:6 September 1996Date of latest announcement of this ETS (doa):31 December 1996Date of latest publication of new National Standardor endorsement of this ETS (dop/e):30 June 1997Date of withdrawal of any conflicting National Standard (dow):30 June 1997SIST ETS 300 658:1998
Page 6ETS 300 658: September 1996Blank pageSIST ETS 300 658:1998
Page 7ETS 300 658: September 19961ScopeThis European Telecommunication Standard (ETS) defines a simple and flexible test responder whichenables the use of Abstract Test Suites (ATSs) for Transaction Capabilities (TC) independently from theactual TC-users which reside in a System Under Test (SUT).No assumption is made about the actual implementation of the interface between this function and TC.The availability of a standardized TC test responder has the following advantages:-it makes it possible to write a unique ATS which can be executed against any TC implementationwhich resides in a system where the test responder is also implemented;-it allows all the defined TC functionalities to be tested, irrespective of the sub-set of functionalitiesactually used by the TC-users which are available at the moment when an equipment is under test;-it helps to isolate faults during testing, since the proper response to a TC message or componentwill be independent of the proper execution of a real TC-user operation;-it allows the TC stack to be tested before being delivered to a customer for supporting one ore moreparticular TC-user applications;-the test responder can even be used to perform stack-to-stack interoperability testing independentlyof any particular TC-user application.2Normative referencesThis ETS incorporates by dated and undated reference, provisions from other publications. Thesenormative references are cited at the appropriate places in the text and the publications are listedhereafter. For dated references, subsequent amendments to or revisions of any of these publicationsapply to this ETS only when incorporated in it by amendment or revision. For undated references the latestedition of the publication referred to applies.[1]ETS 300 134: "Integrated Services Digital Network (ISDN); Signalling SystemNo.7; Transaction Capabilities Application Part (TCAP)".[2]ETS 300 287: "Integrated Services Digital Network (ISDN); Signalling SystemNo.7; Transaction Capabilities Application Part (TCAP) version 2".[3]ISO/IEC 8824 (1995): "Information Technology - Abstract Syntax Notation One(ASN.1)" (also published as ITU-T Recommendations X.680 (1994),X.681 (1994), X.682 (1994) and X.683 (1994)).[4]ISO/IEC 8825-1 (1995): "Information Technology - ASN.1 Encoding Rules -Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)and Distinguished Encoding Rules (DER)" (also published as ITU-TRecommendation X.690 (1994)).[5]ISO/IEC 9646-1 (1994): "Information technology - Open SystemsInterconnection - Conformance testing methodology and framework - Part 1:General concepts".[6]CCITT Recommendations Q.771-Q.775 (1988): "Specifications of SignallingSystem No.7, Transaction Capabilities Application Part (TCAP)" (Blue Book).[7]ITU-T Recommendations Q.771-Q.775 (1993): "Specifications of SignallingSystem No.7: Transaction Capabilities (TC)" (White Book).SIST ETS 300 658:1998
Page 8ETS 300 658: September 19963AbbreviationsFor the purposes of this ETS, the following abbreviations apply:AEApplication EntityASEApplication Service ElementASN.1Abstract Syntax Notation One (as specified in ISO/IEC 8824 [3])ATSAbstract Test SuiteIUTImplementation Under TestLTLower TesterPDUProtocol Data UnitSCCPSignalling Connection Control Part (SS7)SUTSystem Under TestTCTransaction CapabilitiesTMPTest Management ProtocolUTUpper Tester4ArchitectureThe TC test responder is a particular TC-user which can be implemented together with TC in any system,using several possible configurations.The communication between the TC test responder which resides in a SUT and a test system relies onthe use of a particular Application Service Element (ASE), called "TC Testing User ASE". The TC testresponder plays the role of the ASE supplier while the test system plays the role of the ASE consumer.The TC Testing User ASE can be implemented as the single component of an Application Entity (AE)located at a particular sub-system number, or it can be combined with other application layer elements inwhich case it is selected by using any application-context-name starting with the following value:{ccitt identified-organization etsi(0) 658 ac(5)}NOTE:ETS 300 009-1, Signalling Connection Control Part (SCCP) will allocate a sub-systemnumber which may be used for addressing an AE which contains the test responder(e.g. when only CCITT Blue Book [6] TC facilities are available).According to ISO/IEC 9646-1 [5], the set of data units conveyed between two instances of the testresponder and a test system can be considered as an "in-band" Test Management Protocol (TMP), whichcan be used to support co-ordinated test methods between the test responder acting as an Upper Tester(UT) and the Lower Tester (LT) functionality of the test system (see figure 1).Test systemSUTLTTest co-ordinationproceduresTMP-PDUUTTestingUserASEIUT(TC)SCCPFigure 1SIST ETS 300 658:1998
Page 9ETS 300 658: September 1996The use of this test responder does not require any access to the TC service interface within the SUT, nordoes it place any constraints on its implementation. This test responder does not provide means fortesting the behaviour of a TC implementation in response to invalid behaviour of the local TC-user.The "in-band" nature of the TMP implies that, although being under test, the TC service is reliable enoughto carry such Protocol Data Units (PDUs) and deliver them to a user. In order to overcome potentialdifficulties due to a missing or unreliable TC service, the Testing User ASE procedures are defined insuch a way that each TMP-PDU can be received in different types of messages or components.The main purpose of the TMP is to allow series of commands to be sent from the test system to the testresponder in order to provoke some behaviour in the TC Implementation Under Test (IUT). Eachcommand is either a TC service primitive to be passed by the test responder to the TC under test or theindication that the test responder should keep waiting for a subsequent event.5TC testing user Application Service Element (ASE)5.1General principlesThe TC testing user ASE can be built on top of the 1988 version (ETS 300 134 [1], based on the CCITTBlue Book [6]) or the 1993 version (ETS 300 287 [2], based on the ITU-T White Book [7]) of TC1). ThisASE can handle simultaneously several dialogues. It embodies the knowledge of seven operations; two ofthem can be invoked by the ASE consumer (i.e. the test system), five of them can be invoked by the ASEsupplier (i.e. SUT). The two operations invoked by the test responder are defined as class 1 operations.However, this has no impact on the behaviour of the test responder2).The TMP-PDUs can be conveyed in the operations arguments, operations result parameters, errorsparameters and when available, in the user information parameter of the dialogue portion.There is no specific relation between a TMP-PDU and the type of message or component which is used tocarry it.NOTE:The upper service interface of the TC Testing User ASE is not standardized. However,such an interface could be made accessible to locally trigger a particular test scenario(e.g., for interoperability testing) or enable the test responder to report to somemanagement function expiry of the timer T-Test.5.2Operations and ErrorsThe Abstract Syntax Notation One (ASN.1) module TC-Testing-User defined in annex A contains thespecification of the operations which can be invoked by the test system or the test responder duringcommunication.The local values assigned to the following operations and errors shall be considered as default values.The actual local values used for these operations and errors shall be treated as configuration parameters.class1SupplierOperationclass2SupplierOperationclass3SupplierOperationclass4SupplierOperationlocalConsumerErrorlocalSupplierError
1)It is up to the test suite designer to write the test cases in such a way that the Test Responder does not request 1993functionalities from a 1988 TC implementation.2)Whether the test responder reports an outcome for these operations depends on the commands received in the TMP PDUs.This does not violate any rule as far as TC is concerned since the class of an operation is irrelevant to the TC residing at theside where the operation is executed.SIST ETS 300 658:1998
Page 10ETS 300 658: September 19966TC test management protocol6.1Test management protocol PDUsThere are three types of TMP-PDU3):testInitThe testInit PDU requests the test responder to initiate a test session and conveys a set ofcommands to be executed sequentially by the test responder. This PDU can only be sent by thetest system.testContinueThe testContinue PDU conveys a set of additional commands to be executed sequentially by thetest responder. This PDU can only be sent by the test system.testDataEchoThe testDataEcho PDU conveys user data echoing the user data received with a particularcommand. This PDU can only be sent by the test responder.The testInit and testContinue PDUs can be conveyed in the argument of the operations invoked by thetest system, in the result or error parameter returned by the test system in response to an operationinvoked by the test responder or in the user information parameter of the dialogue portion of themessages sent by the test system.The testDataEcho PDU can be conveyed in the argument of the operations invoked by the test responder,in the result or error parameter returned by the System Under Test in response to an operation invoked bythe test system, or in the user information parameter of the dialogue portion of the messages sent by thetest responder.6.2Command structureEach command sent from the test system in a testInit or testContinue PDU indicates to the test responderthat it shall keep waiting for an external event from the local TC or that it shall issue a particular requestprimitive to the local TC.Commands indicating to the test responder that is has to wait for an external event also indicate whetherthis event shall occur on a particular dialogue or that this does not matter.Commands requesting the test responder to issue a primitive comprise up to three items:1)an indication of the type of request primitive to be passed to the local TC;2)the reference to the dialogue over which the action should be taken. If this information is notexplicitly provided, the test responder assumes that the command refers to the dialogue over whichthe TMP-PDU has been received. The dialogue reference is always chosen by the test system.Unlike transaction Ids and dialogue Ids, the dialogue reference is a common reference shared byboth sides of a dialogue.The test responder has to keep track of the one-to-one relation which exists between a dialogue-reference and the local TC dialogue-Id which has been agreed between TC and the Testing UserASE for this dialogue;3)optionally, a user data parameter to be echoed as user data associated with the service primitive tobe issued.
3)The need for a "TestEnd" PDU is for further study.SIST ETS 300 658:1998
Page 11ETS 300 658: September 19966.3Abstract syntaxThe ASN.1 module TC-TMP defined in annex B contains the specification of the TMP-PDUs.When the TMP-PDUs are conveyed in the user information parameter of the dialogue portion, thefollowing abstract-syntax-name is used as a direct-reference to identify the set of data values each ofwhich is a value of type TMP-Protocol.TMP-PDU:{ccitt identified-organization etsi(0) 658 as(4) tmp-pdus(1) version1(1)}The applicable encoding rules are the basic encoding rules defined in ISO/IEC 8825-1 [4].6.4Procedures6.4.1Procedure at the test system sideThe Testing User ASE has limited error detection and error recovery functionalities. It is up to the designerof the ATS to ensure that the sequence of commands which are sent to the test responder corresponds toa valid TC-user behaviour and does not conflict with the automatic procedures of this ASE.It is up to the Test Suite designer to choose how a TMP-PDU is conveyed to the test responder (i.e. whichmessage and which component, if any, etc.). The test system can send a TMP-PDU in any type ofmessage and component with the sole restriction that a TestInit PDU can only be sent in a Beginmessage or in a Unidirectional message.It is also the responsibility of the designer of the ATS to ensure that the TMP PDU will be delivered to theTest User ASE (i.e. it should be conveyed in a valid TC message or component).Starting a Test Case: at the beginning of each Test Case, the test system shall send a testInit PDU inorder to ensure that no resources associated with a previous test case are still active. This PDU shallinclude a sequence of commands to be executed by the test responder and optionally the value of awatch-dog timer (T-Test). If no timer value is provided, an implementation value is selected4).Continuing a Test Case: if all the commands are not sent in the testInit PDU, the test system can sendfurther commands to the test responder using the testContinue PDU which also contains a sequence ofcommands to be executed by the test responder. A TC message can convey more than one testContinuePDU.Ending a Test Case: there is no specific command nor TMP-PDU for ending a test case. It is up to thetest designer to write the test case postamble in such a way that all active dialogues are closed.6.4.2Procedure at the test responder side6.4.2.1Generic rulesThe test responder refuses any application-context-name whose object identifier value does not start withthe following root:{ccitt identified-organization etsi(0) 658 ac(5)}If the test responder accepts a 1993 dialogue (i.e. a dialo
...
SLOVENSKI STANDARD
SIST ETS 300 658:1998
01-september-1998
'LJLWDOQRRPUHåMH]LQWHJULUDQLPLVWRULWYDPL ,6'1 6LJQDOL]DFLMDãW'UXJD
UD]OLþLFDWUDQVDNFLMVNLK]PRåQRVWL 7& 6SHFLILNDFLMDSUHVNXãDOQHJDRG]LYQLND
Integrated Services Digital Network (ISDN); Signalling System No.7; Transaction
Capabilities (TC) version 2; Test responder specification
Ta slovenski standard je istoveten z: ETS 300 658 Edition 1
ICS:
33.080 Digitalno omrežje z Integrated Services Digital
integriranimi storitvami Network (ISDN)
(ISDN)
SIST ETS 300 658:1998 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
SIST ETS 300 658:1998
---------------------- Page: 2 ----------------------
SIST ETS 300 658:1998
EUROPEAN ETS 300 658
TELECOMMUNICATION September 1996
STANDARD
Source: ETSI TC-SPS Reference: DE/SPS-02030
ICS: 33.080
Key words: ISDN, SS7, TC, testing, ASN.1
Integrated Services Digital Network (ISDN);
Signalling System No.7;
Transaction Capabilities (TC) version 2;
Test responder specification
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 92 94 42 00 - Fax: +33 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 1996. All rights reserved.
---------------------- Page: 3 ----------------------
SIST ETS 300 658:1998
Page 2
ETS 300 658: September 1996
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 658:1998
Page 3
ETS 300 658: September 1996
Contents
Foreword .5
1 Scope .7
2 Normative references.7
3 Abbreviations.8
4 Architecture .8
5 TC testing user Application Service Element (ASE) .9
5.1 General principles.9
5.2 Operations and Errors .9
6 TC test management protocol.10
6.1 Test management protocol PDUs .10
6.2 Command structure .10
6.3 Abstract syntax .11
6.4 Procedures.11
6.4.1 Procedure at the test system side.11
6.4.2 Procedure at the test responder side .11
6.4.2.1 Generic rules .11
6.4.2.2 Handling of TMP-PDUs .12
6.4.2.3 Execution of the wait command.13
6.4.2.4 Execution of other commands.13
6.4.2.5 Data echo .14
Annex A (normative): TC test responder Operations and Errors .15
Annex B (normative): Test management protocol PDUs .17
Annex C (informative): Example of use of the TC test responder.19
Annex D (informative): Implementing loops using the TC test responder.22
Annex E (informative): Bibliography.23
History.24
---------------------- Page: 5 ----------------------
SIST ETS 300 658:1998
Page 4
ETS 300 658: September 1996
Blank page
---------------------- Page: 6 ----------------------
SIST ETS 300 658:1998
Page 5
ETS 300 658: September 1996
Foreword
This European Telecommunication Standard (ETS) has been produced by the Signalling Protocols and
Switching (SPS) Technical Committee of the European Telecommunications Standards Institute (ETSI).
Transposition dates
Date of adoption of this ETS: 6 September 1996
Date of latest announcement of this ETS (doa): 31 December 1996
Date of latest publication of new National Standard
or endorsement of this ETS (dop/e): 30 June 1997
Date of withdrawal of any conflicting National Standard (dow): 30 June 1997
---------------------- Page: 7 ----------------------
SIST ETS 300 658:1998
Page 6
ETS 300 658: September 1996
Blank page
---------------------- Page: 8 ----------------------
SIST ETS 300 658:1998
Page 7
ETS 300 658: September 1996
1 Scope
This European Telecommunication Standard (ETS) defines a simple and flexible test responder which
enables the use of Abstract Test Suites (ATSs) for Transaction Capabilities (TC) independently from the
actual TC-users which reside in a System Under Test (SUT).
No assumption is made about the actual implementation of the interface between this function and TC.
The availability of a standardized TC test responder has the following advantages:
- it makes it possible to write a unique ATS which can be executed against any TC implementation
which resides in a system where the test responder is also implemented;
- it allows all the defined TC functionalities to be tested, irrespective of the sub-set of functionalities
actually used by the TC-users which are available at the moment when an equipment is under test;
- it helps to isolate faults during testing, since the proper response to a TC message or component
will be independent of the proper execution of a real TC-user operation;
- it allows the TC stack to be tested before being delivered to a customer for supporting one ore more
particular TC-user applications;
- the test responder can even be used to perform stack-to-stack interoperability testing independently
of any particular TC-user application.
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 134: "Integrated Services Digital Network (ISDN); Signalling System
No.7; Transaction Capabilities Application Part (TCAP)".
[2] ETS 300 287: "Integrated Services Digital Network (ISDN); Signalling System
No.7; Transaction Capabilities Application Part (TCAP) version 2".
[3] ISO/IEC 8824 (1995): "Information Technology - Abstract Syntax Notation One
(ASN.1)" (also published as ITU-T Recommendations X.680 (1994),
X.681 (1994), X.682 (1994) and X.683 (1994)).
[4] ISO/IEC 8825-1 (1995): "Information Technology - ASN.1 Encoding Rules -
Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER)
and Distinguished Encoding Rules (DER)" (also published as ITU-T
Recommendation X.690 (1994)).
[5] ISO/IEC 9646-1 (1994): "Information technology - Open Systems
Interconnection - Conformance testing methodology and framework - Part 1:
General concepts".
[6] CCITT Recommendations Q.771-Q.775 (1988): "Specifications of Signalling
System No.7, Transaction Capabilities Application Part (TCAP)" (Blue Book).
[7] ITU-T Recommendations Q.771-Q.775 (1993): "Specifications of Signalling
System No.7: Transaction Capabilities (TC)" (White Book).
---------------------- Page: 9 ----------------------
SIST ETS 300 658:1998
Page 8
ETS 300 658: September 1996
3 Abbreviations
For the purposes of this ETS, the following abbreviations apply:
AE Application Entity
ASE Application Service Element
ASN.1 Abstract Syntax Notation One (as specified in ISO/IEC 8824 [3])
ATS Abstract Test Suite
IUT Implementation Under Test
LT Lower Tester
PDU Protocol Data Unit
SCCP Signalling Connection Control Part (SS7)
SUT System Under Test
TC Transaction Capabilities
TMP Test Management Protocol
UT Upper Tester
4 Architecture
The TC test responder is a particular TC-user which can be implemented together with TC in any system,
using several possible configurations.
The communication between the TC test responder which resides in a SUT and a test system relies on
the use of a particular Application Service Element (ASE), called "TC Testing User ASE". The TC test
responder plays the role of the ASE supplier while the test system plays the role of the ASE consumer.
The TC Testing User ASE can be implemented as the single component of an Application Entity (AE)
located at a particular sub-system number, or it can be combined with other application layer elements in
which case it is selected by using any application-context-name starting with the following value:
{ccitt identified-organization etsi(0) 658 ac(5)}
NOTE: ETS 300 009-1, Signalling Connection Control Part (SCCP) will allocate a sub-system
number which may be used for addressing an AE which contains the test responder
(e.g. when only CCITT Blue Book [6] TC facilities are available).
According to ISO/IEC 9646-1 [5], the set of data units conveyed between two instances of the test
responder and a test system can be considered as an "in-band" Test Management Protocol (TMP), which
can be used to support co-ordinated test methods between the test responder acting as an Upper Tester
(UT) and the Lower Tester (LT) functionality of the test system (see figure 1).
Test system SUT
LT Test co-ordination UT
procedures
TMP-PDU
Testing
User
ASE
IUT
(TC)
SCCP
Figure 1
---------------------- Page: 10 ----------------------
SIST ETS 300 658:1998
Page 9
ETS 300 658: September 1996
The use of this test responder does not require any access to the TC service interface within the SUT, nor
does it place any constraints on its implementation. This test responder does not provide means for
testing the behaviour of a TC implementation in response to invalid behaviour of the local TC-user.
The "in-band" nature of the TMP implies that, although being under test, the TC service is reliable enough
to carry such Protocol Data Units (PDUs) and deliver them to a user. In order to overcome potential
difficulties due to a missing or unreliable TC service, the Testing User ASE procedures are defined in
such a way that each TMP-PDU can be received in different types of messages or components.
The main purpose of the TMP is to allow series of commands to be sent from the test system to the test
responder in order to provoke some behaviour in the TC Implementation Under Test (IUT). Each
command is either a TC service primitive to be passed by the test responder to the TC under test or the
indication that the test responder should keep waiting for a subsequent event.
5 TC testing user Application Service Element (ASE)
5.1 General principles
The TC testing user ASE can be built on top of the 1988 version (ETS 300 134 [1], based on the CCITT
1)
Blue Book [6]) or the 1993 version (ETS 300 287 [2], based on the ITU-T White Book [7]) of TC . This
ASE can handle simultaneously several dialogues. It embodies the knowledge of seven operations; two of
them can be invoked by the ASE consumer (i.e. the test system), five of them can be invoked by the ASE
supplier (i.e. SUT). The two operations invoked by the test responder are defined as class 1 operations.
2)
However, this has no impact on the behaviour of the test responder .
The TMP-PDUs can be conveyed in the operations arguments, operations result parameters, errors
parameters and when available, in the user information parameter of the dialogue portion.
There is no specific relation between a TMP-PDU and the type of message or component which is used to
carry it.
NOTE: The upper service interface of the TC Testing User ASE is not standardized. However,
such an interface could be made accessible to locally trigger a particular test scenario
(e.g., for interoperability testing) or enable the test responder to report to some
management function expiry of the timer T-Test.
5.2 Operations and Errors
The Abstract Syntax Notation One (ASN.1) module TC-Testing-User defined in annex A contains the
specification of the operations which can be invoked by the test system or the test responder during
communication.
The local values assigned to the following operations and errors shall be considered as default values.
The actual local values used for these operations and errors shall be treated as configuration parameters.
class1SupplierOperation
class2SupplierOperation
class3SupplierOperation
class4SupplierOperation
localConsumerError
localSupplierError
1)
It is up to the test suite designer to write the test cases in such a way that the Test Responder does not request 1993
functionalities from a 1988 TC implementation.
)
2
Whether the test responder reports an outcome for these operations depends on the commands received in the TMP PDUs.
This does not violate any rule as far as TC is concerned since the class of an operation is irrelevant to the TC residing at the
side where the operation is executed.
---------------------- Page: 11 ----------------------
SIST ETS 300 658:1998
Page 10
ETS 300 658: September 1996
6 TC test management protocol
6.1 Test management protocol PDUs
3)
There are three types of TMP-PDU :
testInit
The testInit PDU requests the test responder to initiate a test session and conveys a set of
commands to be executed sequentially by the test responder. This PDU can only be sent by the
test system.
testContinue
The testContinue PDU conveys a set of additional commands to be executed sequentially by the
test responder. This PDU can only be sent by the test system.
testDataEcho
The testDataEcho PDU conveys user data echoing the user data received with a particular
command. This PDU can only be sent by the test responder.
The testInit and testContinue PDUs can be conveyed in the argument of the operations invoked by the
test system, in the result or error parameter returned by the test system in response to an operation
invoked by the test responder or in the user information parameter of the dialogue portion of the
messages sent by the test system.
The testDataEcho PDU can be conveyed in the argument of the operations invoked by the test responder,
in the result or error parameter returned by the System Under Test in response to an operation invoked by
the test system, or in the user information parameter of the dialogue portion of the messages sent by the
test responder.
6.2 Command structure
Each command sent from the test system in a testInit or testContinue PDU indicates to the test responder
that it shall keep waiting for an external event from the local TC or that it shall issue a particular request
primitive to the local TC.
Commands indicating to the test responder that is has to wait for an external event also indicate whether
this event shall occur on a particular dialogue or that this does not matter.
Commands requesting the test responder to issue a primitive comprise up to three items:
1) an indication of the type of request primitive to be passed to the local TC;
2) the reference to the dialogue over which the action should be taken. If this information is not
explicitly provided, the test responder assumes that the command refers to the dialogue over which
the TMP-PDU has been received. The dialogue reference is always chosen by the test system.
Unlike transaction Ids and dialogue Ids, the dialogue reference is a common reference shared by
both sides of a dialogue.
The test responder has to keep track of the one-to-one relation which exists between a dialogue-
reference and the local TC dialogue-Id which has been agreed between TC and the Testing User
ASE for this dialogue;
3) optionally, a user data parameter to be echoed as user data associated with the service primitive to
be issued.
3)
The need for a "TestEnd" PDU is for further study.
---------------------- Page: 12 ----------------------
SIST ETS 300 658:1998
Page 11
ETS 300 658: September 1996
6.3 Abstract syntax
The ASN.1 module TC-TMP defined in annex B contains the specification of the TMP-PDUs.
When the TMP-PDUs are conveyed in the user information parameter of the dialogue portion, the
following abstract-syntax-name is used as a direct-reference to identify the set of data values each of
which is a value of type TMP-Protocol.TMP-PDU:
{ccitt identified-organization etsi(0) 658 as(4) tmp-pdus(1) version1(1)}
The applicable encoding rules are the basic encoding rules defined in ISO/IEC 8825-1 [4].
6.4 Procedures
6.4.1 Procedure at the test system side
The Testing User ASE has limited error detection and error recovery functionalities. It is up to the designer
of the ATS to ensure that the sequence of commands which are sent to the test responder corresponds to
a valid TC-user behaviour and does not conflict with the automatic procedures of this ASE.
It is up to the Test Suite designer to choose how a TMP-PDU is conveyed to the test responder (i.e. which
message and which component, if any, etc.). The test system can send a TMP-PDU in any type of
message and component with the sole restriction that a TestInit PDU can only be sent in a Begin
message or in a Unidirectional message.
It is also the responsibility of the designer of the ATS to ensure that the TMP PDU will be delivered to the
Test User ASE (i.e. it should be conveyed in a valid TC message or component).
Starting a Test Case: at the beginning of each Test Case, the test system shall send a testInit PDU in
order to ensure that no resources associated with a previous test case are still active. This PDU shall
include a sequence of commands to be executed by the test responder and optionally the value of a
4)
watch-dog timer (T-Test). If no timer value is provided, an implementation value is selected .
Continuing a Test Case: if all the commands are not sent in the testInit PDU, the test system can send
further commands to the test responder using the testContinue PDU which also contains a sequence of
commands to be executed by the test responder. A TC message can convey more than one testContinue
PDU.
Ending a Test Case: there is no specific command nor TMP-PDU for ending a test case. It is up to the
test designer to write the test case postamble in such a way that all active dialogues are closed.
6.4.2 Procedure at the test responder side
6.4.2.1 Generic rules
The test responder refuses any application-context-name whose object identifier value does not start with
the following root:
{ccitt identified-organization etsi(0) 658 ac(5)}
If the test responder accepts a 1993 dialogue (i.e. a dialogue according to ETS 300 287 [2] and the ITU-T
White Book [7]), it shall use the received
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.