SIST ETS 300 287-1:1998
(Main)Integrated Services Digital Network (ISDN); Signalling System No.7; Transaction Capabilities (TC) version 2; Part 1: Protocol specification [ITU-T Recommendations Q.771 to Q.775 (1993), modified]
Integrated Services Digital Network (ISDN); Signalling System No.7; Transaction Capabilities (TC) version 2; Part 1: Protocol specification [ITU-T Recommendations Q.771 to Q.775 (1993), modified]
Add an informative annex containing the TCAP protocol spec in ASN.1 us ing the 93 notation
Digitalno omrežje z integriranimi storitvami (ISDN) - Signalizacija št. 7 - Druga različica transakcijskih zmožnosti (TC) - 1. del: Specifikacija protokola (preoblikovana priporočila ITU-T Q.771 do Q.775 (1993))
General Information
Standards Content (Sample)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.URWRNRODIntegrated Services Digital Network (ISDN); Signalling System No.7; Transaction Capabilities (TC) version 2; Part 1: Protocol specification [ITU-T Recommendations Q.771 to Q.775 (1993), modified]33.080Digitalno omrežje z integriranimi storitvami (ISDN)Integrated Services Digital Network (ISDN)ICS:Ta slovenski standard je istoveten z:ETS 300 287-1 Edition 23SIST ETS 300 287-1:1998en01-IHEUXDU-19983SIST ETS 300 287-1:1998SLOVENSKI
STANDARD
SIST ETS 300 287-1:1998
EUROPEANETS 300 287-1TELECOMMUNICATIONNovember 1996STANDARDSecond EditionSource: ETSI TC-SPSReference: RE/SPS-02035ICS:33.080Key words:ISDN, SS7, TCAPIntegrated Services Digital Network (ISDN);Signalling System No.7;Transaction Capabilities (TC) version 2;Part 1: Protocol specification[ITU-T Recommendations Q.771 to Q.775 (1993), modified]ETSIEuropean 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 4 92 94 42 00 - Fax: +33 4 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 287-1:1998
Page 2ETS 300 287-1: November 1996ForewordThis second edition European Telecommunication Standard (ETS) has been produced by the SignallingProtocols and Switching (SPS) Technical Committee of the European Telecommunications StandardsInstitute (ETSI).The second edition of ETS 300 287 covering the Signalling System No.7 Transaction Capabilities (TC)version 2 is structured as a multi-part standard (of which this ETS forms part 1) as described below:Part 1:"Protocol specification [ITU-T Recommendations Q.771 to Q.775 (1993), modified]";Part 2:"Protocol Implementation Conformance Statement (PICS) proforma specification";Part 3:"Abstract Test Suite (ATS) and partial Protocol Implementation eXtra Information for Testing(PIXIT) proforma specification".Transposition datesDate of adoption8 November 1996Date of latest announcement of this ETS (doa):28 February 1997Date of latest publication of new National Standardor endorsement of this ETS (dop/e):31 August 1997Date of withdrawal of any conflicting National Standard (dow):31 August 1997Endorsement noticeThe text of ITU-T Recommendations Q.771, Q.772, Q.773, Q.774 and Q.775 (1993) was approved byETSI as an ETS with agreed modifications as given below.NOTE:New or modified text is indicated using sidebars. In addition, underlining and/or strike-out are used to highlight detailed modifications where necessary.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.SIST ETS 300 287-1:1998
Page 3ETS 300 287-1: November 1996Global modifications to ITU-T Recommendations Q.771 to Q.775Insert the following two clauses (scope and normative references):ScopeThis first part of ETS 300 287 defines the Transaction Capabilities1) (TC) signalling protocol to be used inand between networks, for non-circuit related services which use Signalling System No.7 for inter-networkdialogues. Only those parts of TC which are used by the above services need to be provided.The support of TC by terminal equipment is outside the scope of this ETS.This ETS covers only TC for use over a network layer consisting of Signalling System No.7 MessageTransfer Part (MTP) plus Signalling Connection Control Part (SCCP).NOTE:This is valid for both 1988 and 1993 versions.Normative 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]CCITT Recommendation X.219 (1988): "Information Technology - OpenSystems Interconnection - Association Control Service Element (ACSE)".[2]ITU-T Recommendation X.680 (1994): "Information Technology - AbstractSyntax Notation One (ASN.1): Specification of Basic Notation".[3]ITU-T Recommendation X.880 (1994): "Information Technology - RemoteOperations - Concept, Model and Notation".[4]ITU-T Recommendation X.881 (1994): "Information Technology - OSIRealisations: Remote Operations Service Element (ROSE) Service Definition".
1)For historical reasons, the terms Transaction Capabilities (TC) and Transaction Capabilities Application Part (TCAP) areused interchangeably.SIST ETS 300 287-1:1998
Page 4ETS 300 287-1: November 1996Modifications to ITU-T Recommendation Q.771Page 9, subclause 3.1.2.1, first bullet itemReplace the definition of "Abort Reason" with the following:-"Abort Reason" - Indicates whether a dialogue is aborted because the received application contextname is not supported and no alternative one can be proposed (abort reason = application contextnot supported), because the dialogue cannot be established for any other user reason (abortreason = dialogue refused) or because a user abort situation has been encountered (abortreason = user specific).Modifications to ITU-T Recommendation Q.772Pages 4 and 5, subclauses 3.7.2.3, 3.7.3.3 and 3.7.4.5 "mistyped parameter"The definition of "mistyped parameter" provided in subclauses 3.7.2.3, 3.7.3.3 and 3.7.4.5 shall also covererror conditions such as ENUMERATED error, value range error, size constraint error, value constrainterror and presence constraint error.Page 7, subclause 4.2.5 "result source diagnostic"Modify the first sentence of the last paragraph as follows:The "dialogue service user" can further qualify the result with a diagnostic with values "null" or "no reasongiven" (for the case where no diagnostic is offered) or "application-context-name-not-supported" (for thecase when the dialogue is refused because the application context is not supported).Modifications to ITU-T Recommendation Q.773Page 1, subclause 3.1NOTE:This correction does not change the transfer syntax.Replace the EXPORTS statement by:EXPORTS OPERATION, ERROR, MessageType, Component, InvokeIdType;Pages 2 and 4, subclause 3.1NOTE:This correction does not change the transfer syntax.Add a range constraint of "(0.127)" to all unconstrained INTEGERs, i.e., the following shall be modified:P-AbortCauseGeneralProblemInvokeProblemReturnResultProblemReturnErrorProblemWhen a value, which is not assigned but is within the specified range, is received, this value should beignored. Values out of range may lead to a syntax error.Pages 4 and
5, subclause 3.2NOTE:This correction does not change the transfer syntax.Add a size constraint of "(1.10)" to "user-information" when carried within AARQ-apdu, AARE-apdu,RLRQ-apdu, RLRE-apdu and ABRT-apdu:user-information[30] IMPLICIT SEQUENCE SIZE (1.10) OF EXTERNAL OPTIONALSIST ETS 300 287-1:1998
Page 5ETS 300 287-1: November 1996Page 5, subclause 3.2NOTE:This correction does not change the transfer syntax.Add a range constraint of "(0.127)" to all unconstrained INTEGERs, i.e., the following shall be modified:ABRT-sourceAssociate-resultdialogue-service-userdialogue-service-providerRelease-request-reasonRelease-response-reasonWhen a value, which is not assigned but is within the specified range, is received, this value should beignored. Values out of range may lead to a syntax error.Page 29, subclause 4.2.3.1, table 46/Q.773The Result Tag shall be coded 1010 0010.Page 32, subclause 4.2.3.1, tables 55/Q.773 and 56/Q.773The integer element shall be “mandatory”.Page 32, subclause 4.2.3.1, table 57/Q.773The Dialogue Service Provider Tag shall be coded 1010 0010.The Dialogue Service User Tag shall be coded 1010 0001.SIST ETS 300 287-1:1998
Page 6ETS 300 287-1: November 1996Modifications to ITU-T Recommendation Q.774Page 10, table 3/Q.774, note 3Insert at the end of note 3:or "dialogue-refused".Page 12, subclause 3.2.1.2, "Dialogue End"Replace the penultimate paragraph "If the . described in 3.2.2" by:When a TC-User has received a TC-BEGIN indication primitive including some user information it findsunacceptable, it may issue a TC-U-ABORT request primitive with the "Abort Reason" parameter set to"dialogue-refused". This causes a Dialogue Response (AARE) APDU to be formatted. The setting of thevalues for various fields in the AARE APDU are as follows: the "application-context-name" is identical tothe received one, the result field is set to "reject-permanent", and the "result-source-diagnostic" is"dialogue-service-user (null)" or "dialogue-service-user (no-reason-given)".If the "Abort reason" parameter in the TC-U-ABORT request primitive is absent or has a value other than"application-context-name-not-supported" or "dialogue-refused", this describes an abnormal termination ofthe dialogue and is described in subclause 3.2.2.Page 41, figure A.5 (sheet 6 of 11)Insert in the second decision box before the question mark:or "dialogue-refused"Modifications to ITU-T Recommendation Q.775No modifications identified.SIST ETS 300 287-1:1998
Page 7ETS 300 287-1: November 1996Annex ZA (informative):Realizing the X.880 generic ROS model using TCZA.1IntroductionZA.1.1OverviewITU-T Recommendation X.880 [3] defines a generic model for interactive communication betweenobjects, where the basic interaction involves the invocation of an operation by one object (the invoker) andits performance by another (the performer). This model comes with a set of ASN.1 information objectclasses to be used by protocol designers in the specification of ROS-based applications.ITU-T Recommendation X.880 [3] recognizes that there are multiple possible realizations of this model, asfar as communication is concerned. The purpose of this annex is to demonstrate that TC can beconsidered as one of these realizations, by providing a mapping of the generic concepts onto TC services.ZA.1.2Notation and concept for the generic ROS modelITU-T Recommendation X.880 [3] defines several information object classes that are useful in thespecification of ROS-based application protocols. Such classes can be used by designers of TC-Userapplications, as an alternative to the methodology described in ITU-T Recommendation Q.775. Theseobject classes are defined using the information object specification ASN.1 notation defined in ITU-TRecommendation X.881 [4].The OPERATION class is used to define an operation. It is equivalent to the OPERATION MACROdefined in CCITT Recommendation X.219 [1] and ITU-T Recommendation Q.773 as modified by thisETS.The ERROR class is used to define an error. It is equivalent to the ERROR MACRO defined in CCITTRecommendation X.219 [1] and ITU-T Recommendation Q.773 as modified by this ETS.The OPERATION-PACKAGE class is used to define a set of operations which may only be invoked by aROS-object assuming the role of "consumer", the operations which may only be invoked by a ROS-objectassuming the role of "supplier", and the operations which may be invoked by both ROS-objects. Whenusing the communication services of SS7 or OSI, an operation package is realized as an ApplicationService Element (ASE).The CONNECTION-PACKAGE class is used to define the bind and unbind operations used to establishand release an association. When realized using the communication services of SS7, a connectionpackage is realized as the procedures that use the structured dialogue handling services of TC.Application contexts which do not require the explicit invocation of bind and unbind operations can still beconsidered as including a connection package which uses the emptyBind and emptyUnbind pre-definedoperations.The CONTRACT class is used to define an association contract in terms of a connection package andone or more operation packages. When specifying the contract, those packages in which either only theassociation initiator assumes the role of consumer, or only the association responder assumes the role ofconsumer, or either may assume the role of consumer, are identified. When using the communicationservices of SS7 or OSI, a contract is realized as an application context.The ROS-OBJECT-CLASS class is used to define a set of common capabilities of a set of ROS-objects interms of the (association) contracts they support as initiators and/or responders. When realized using TCor OSI, a ROS-object maps to an application process and a contract to an application context.SIST ETS 300 287-1:1998
Page 8ETS 300 287-1: November 1996ZA.1.3Communication modelThe realization of ROS involves the selection of a suitable medium to convey invocations and repliesbetween a pair of ROS-objects.The possible media can be classified in two broad categories:a)those required when the invoker and the performer are to be implemented in a single physicalequipment;b)those required when the invoker and the performer are to be implemented in separated physicalequipment.Category a) can be further divided into message-passing and procedure-calling facilities.The medium in category b) depends on the type of network which interconnects the two objects and onsome Quality of Service (QoS) criteria.ITU-T Recommendation X.880 [3] models the medium as being composed of two stub objects (one forthe invoker, one for the performer) and one information transfer object (see figure ZA.1). The informationtransfer object capabilities also includes the association control functionalities which might be required toset up an association between the application entities involved in the communication.ROSobjectStubStubROSobjectInformationtransferMediumFigure ZA.1: Generic ROS communication modelThe role of each stub object is merely to transform invocations and replies into protocol data units (andvice-versa) they exchange using the information transfer object. For a given type of stub objects there areseveral possible types of information transfer objects.In the context of OSI, the stub objects are realized by the Remote Operation Service Element (ROSE)while several information transfer realizations are available, using suitable combination of AssociationControl Service Element (ACSE), Reliable Transfer Service Element (RTSE) and the presentation service.The stub objects are realized by the Component Handling Block (CHA) of the TC Component Sub-Layer(CSL, see ITU-T Recommendation Q.774 as modified by this ETS) together with a collection of operation-specific ASEs (the TC-User ASEs). The CHA whose services are defined in subclause 3.1.3 of ITU-TRecommendation Q.771 as modified by this ETS drives the generic protocol required to invoke and reportreturns of arbitrary operations.Each TC-User ASE embodies knowledge of the definitions of the specific operations involved in someoperation package. Collectively, the CSL and the TC-User ASEs have knowledge of all the operations ofthe association contract.SIST ETS 300 287-1:1998
Page 9ETS 300 287-1: November 1996O-ASEsStubComponentsub-layerApplication EntityROS objectApplication processO-ASEsStubComponentsub-layerApplication EntityROS objectApplication processTransaction sub-layerMediumInformation transferDHADHACHACHAFigure ZA.2: TC realization of ROSZA.2Remote operation service realizationZA.2.1Basic services (Stub)The TC CSL provides the necessary services for supporting the invocation of operations and reportingresponses. It also provides additional local services for cancelling operation (TC-U-CANCEL request,TC-L-CANCEL indication) or reporting locally detected protocol error (TC-L-REJECT indication).NOTE:The following restrictions apply:-whether an operation is synchronous or not is not taken into account (from a TCpoint of view operations are always considered as being asynchronous.However, the TC-User might behave in a synchronous manner);-the set of allowed InvokeIds is restricted to the integer range (-128 to 127);-the priority field is ignored2).ZA.2.2Bind and unbind operationsNOTE:In order to minimize the impact of Bind and Unbind operations on TC specifications,this annex assumes that the TC-User constructs the bind and unbind APDUs andtransfers them to TC as if it would be ordinary user information. As a consequence, TCis not aware that these operations are being invoked and cannot check that they areused consistently with respect to the dialogue service and component handling service(e.g. it cannot verify that no operation is requested after an unbind operation has beeninvoked).
2)This might evolve as the studies on priority handling in SS7 will progress.SIST ETS 300 287-1:1998
Page 10ETS 300 287-1: November 1996ZA.2.2.1Bind operationWhen an application context definition includes a connection package, the initiating TC-User invokes abind operation to be executed as part of the dialogue establishment procedure, prior to the execution ofany other operation. Failure of the execution of this operation leads to the rejection of the dialogue.If the TC-User does not really need to invoke an explicit bind operation, it is assumed that it uses theemptyBind pre-defined operation.ZA.2.2.1.1Invoking a bind operationThe TC-User can invoke a bind operation using the TC-BEGIN request primitive. If the definition of thebind operation includes an &ArgumentType field, the TC-User constructs a bind-invoke PDU from thisinformation and transfers it as the first (or only part) of the user-information parameter of the TC-BEGINrequest primitive. Otherwise no bind-invoke PDU is sent.NOTE:This should ensure that the bind-request PDU will be included in the first external fieldof the user-information element of the Dialogue Request APDU (AARQ).ZA.2.2.1.2Responding to a bind operationThe TC-User reports the outcome a bind operation using the first dialogue handling primitive it issues.Successful execution of the bind operation is reported using a TC-CONTINUE request primitive or aTC-END request primitive if there is no need to continue the dialogue. In the latter case it needs also toinvoke an unbind operation.NOTE:Use of the TC-END request primitive at this stage places restriction of the use ofunbind operations. It implies that only the responder can unbind and that the unbindoperation definition does not include an &ResultType field and that the def
...
SLOVENSKI STANDARD
SIST ETS 300 287-1:1998
01-september-1998
'LJLWDOQRRPUHåMH]LQWHJULUDQLPLVWRULWYDPL ,6'1 6LJQDOL]DFLMDãW'UXJD
UD]OLþLFDWUDQVDNFLMVNLK]PRåQRVWL 7& GHO 6SHFLILNDFLMDSURWRNROD
SUHREOLNRYDQDSULSRURþLOD,7874GR4
Integrated Services Digital Network (ISDN); Signalling System No.7; Transaction
Capabilities (TC) version 2; Part 1: Protocol specification [ITU-T Recommendations
Q.771 to Q.775 (1993), modified]
Ta slovenski standard je istoveten z: ETS 300 287-1 Edition 2
ICS:
33.080 Digitalno omrežje z Integrated Services Digital
integriranimi storitvami Network (ISDN)
(ISDN)
SIST ETS 300 287-1:1998 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
SIST ETS 300 287-1:1998
---------------------- Page: 2 ----------------------
SIST ETS 300 287-1:1998
EUROPEAN ETS 300 287-1
TELECOMMUNICATION November 1996
STANDARD Second Edition
Source: ETSI TC-SPS Reference: RE/SPS-02035
ICS: 33.080
Key words: ISDN, SS7, TCAP
Integrated Services Digital Network (ISDN);
Signalling System No.7;
Transaction Capabilities (TC) version 2;
Part 1: Protocol specification
[ITU-T Recommendations Q.771 to Q.775 (1993), modified]
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 1996. All rights reserved.
---------------------- Page: 3 ----------------------
SIST ETS 300 287-1:1998
Page 2
ETS 300 287-1: November 1996
Foreword
This second edition European Telecommunication Standard (ETS) has been produced by the Signalling
Protocols and Switching (SPS) Technical Committee of the European Telecommunications Standards
Institute (ETSI).
The second edition of ETS 300 287 covering the Signalling System No.7 Transaction Capabilities (TC)
version 2 is structured as a multi-part standard (of which this ETS forms part 1) as described below:
Part 1: "Protocol specification [ITU-T Recommendations Q.771 to Q.775 (1993), modified]";
Part 2: "Protocol Implementation Conformance Statement (PICS) proforma specification";
Part 3: "Abstract Test Suite (ATS) and partial Protocol Implementation eXtra Information for Testing
(PIXIT) proforma specification".
Transposition dates
Date of adoption 8 November 1996
Date of latest announcement of this ETS (doa): 28 February 1997
Date of latest publication of new National Standard
or endorsement of this ETS (dop/e): 31 August 1997
Date of withdrawal of any conflicting National Standard (dow): 31 August 1997
Endorsement notice
The text of ITU-T Recommendations Q.771, Q.772, Q.773, Q.774 and Q.775 (1993) was approved by
ETSI as an ETS with agreed modifications as given below.
NOTE: New or modified text is indicated using sidebars. In addition, underlining and/or strike-
out are used to highlight detailed modifications where necessary.
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 287-1:1998
Page 3
ETS 300 287-1: November 1996
Global modifications to ITU-T Recommendations Q.771 to Q.775
Insert the following two clauses (scope and normative references):
Scope
1)
This first part of ETS 300 287 defines the Transaction Capabilities (TC) signalling protocol to be used in
and between networks, for non-circuit related services which use Signalling System No.7 for inter-network
dialogues. Only those parts of TC which are used by the above services need to be provided.
The support of TC by terminal equipment is outside the scope of this ETS.
This ETS covers only TC for use over a network layer consisting of Signalling System No.7 Message
Transfer Part (MTP) plus Signalling Connection Control Part (SCCP).
NOTE: This is valid for both 1988 and 1993 versions.
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] CCITT Recommendation X.219 (1988): "Information Technology - Open
Systems Interconnection - Association Control Service Element (ACSE)".
[2] ITU-T Recommendation X.680 (1994): "Information Technology - Abstract
Syntax Notation One (ASN.1): Specification of Basic Notation".
[3] ITU-T Recommendation X.880 (1994): "Information Technology - Remote
Operations - Concept, Model and Notation".
[4] ITU-T Recommendation X.881 (1994): "Information Technology - OSI
Realisations: Remote Operations Service Element (ROSE) Service Definition".
1)
For historical reasons, the terms Transaction Capabilities (TC) and Transaction Capabilities Application Part (TCAP) are
used interchangeably.
---------------------- Page: 5 ----------------------
SIST ETS 300 287-1:1998
Page 4
ETS 300 287-1: November 1996
Modifications to ITU-T Recommendation Q.771
Page 9, subclause 3.1.2.1, first bullet item
Replace the definition of "Abort Reason" with the following:
- "Abort Reason" - Indicates whether a dialogue is aborted because the received application context
name is not supported and no alternative one can be proposed (abort reason = application context
not supported), because the dialogue cannot be established for any other user reason (abort
reason = dialogue refused) or because a user abort situation has been encountered (abort
reason = user specific).
Modifications to ITU-T Recommendation Q.772
Pages 4 and 5, subclauses 3.7.2.3, 3.7.3.3 and 3.7.4.5 "mistyped parameter"
The definition of "mistyped parameter" provided in subclauses 3.7.2.3, 3.7.3.3 and 3.7.4.5 shall also cover
error conditions such as ENUMERATED error, value range error, size constraint error, value constraint
error and presence constraint error.
Page 7, subclause 4.2.5 "result source diagnostic"
Modify the first sentence of the last paragraph as follows:
The "dialogue service user" can further qualify the result with a diagnostic with values "null" or "no reason
given" (for the case where no diagnostic is offered) or "application-context-name-not-supported" (for the
case when the dialogue is refused because the application context is not supported).
Modifications to ITU-T Recommendation Q.773
Page 1, subclause 3.1
NOTE: This correction does not change the transfer syntax.
Replace the EXPORTS statement by:
EXPORTS OPERATION, ERROR, MessageType, Component, InvokeIdType;
Pages 2 and 4, subclause 3.1
NOTE: This correction does not change the transfer syntax.
Add a range constraint of "(0.127)" to all unconstrained INTEGERs, i.e., the following shall be modified:
P-AbortCause
GeneralProblem
InvokeProblem
ReturnResultProblem
ReturnErrorProblem
When a value, which is not assigned but is within the specified range, is received, this value should be
ignored. Values out of range may lead to a syntax error.
Pages 4 and 5, subclause 3.2
NOTE: This correction does not change the transfer syntax.
Add a size constraint of "(1.10)" to "user-information" when carried within AARQ-apdu, AARE-apdu,
RLRQ-apdu, RLRE-apdu and ABRT-apdu:
user-information [30] IMPLICIT SEQUENCE SIZE (1.10) OF EXTERNAL OPTIONAL
---------------------- Page: 6 ----------------------
SIST ETS 300 287-1:1998
Page 5
ETS 300 287-1: November 1996
Page 5, subclause 3.2
NOTE: This correction does not change the transfer syntax.
Add a range constraint of "(0.127)" to all unconstrained INTEGERs, i.e., the following shall be modified:
ABRT-source
Associate-result
dialogue-service-user
dialogue-service-provider
Release-request-reason
Release-response-reason
When a value, which is not assigned but is within the specified range, is received, this value should be
ignored. Values out of range may lead to a syntax error.
Page 29, subclause 4.2.3.1, table 46/Q.773
The Result Tag shall be coded 1010 0010.
Page 32, subclause 4.2.3.1, tables 55/Q.773 and 56/Q.773
The integer element shall be “mandatory”.
Page 32, subclause 4.2.3.1, table 57/Q.773
The Dialogue Service Provider Tag shall be coded 1010 0010.
The Dialogue Service User Tag shall be coded 1010 0001.
---------------------- Page: 7 ----------------------
SIST ETS 300 287-1:1998
Page 6
ETS 300 287-1: November 1996
Modifications to ITU-T Recommendation Q.774
Page 10, table 3/Q.774, note 3
Insert at the end of note 3:
or "dialogue-refused".
Page 12, subclause 3.2.1.2, "Dialogue End"
Replace the penultimate paragraph "If the . described in 3.2.2" by:
When a TC-User has received a TC-BEGIN indication primitive including some user information it finds
unacceptable, it may issue a TC-U-ABORT request primitive with the "Abort Reason" parameter set to
"dialogue-refused". This causes a Dialogue Response (AARE) APDU to be formatted. The setting of the
values for various fields in the AARE APDU are as follows: the "application-context-name" is identical to
the received one, the result field is set to "reject-permanent", and the "result-source-diagnostic" is
"dialogue-service-user (null)" or "dialogue-service-user (no-reason-given)".
If the "Abort reason" parameter in the TC-U-ABORT request primitive is absent or has a value other than
"application-context-name-not-supported" or "dialogue-refused", this describes an abnormal termination of
the dialogue and is described in subclause 3.2.2.
Page 41, figure A.5 (sheet 6 of 11)
Insert in the second decision box before the question mark:
or "dialogue-refused"
Modifications to ITU-T Recommendation Q.775
No modifications identified.
---------------------- Page: 8 ----------------------
SIST ETS 300 287-1:1998
Page 7
ETS 300 287-1: November 1996
Annex ZA (informative): Realizing the X.880 generic ROS model using TC
ZA.1 Introduction
ZA.1.1 Overview
ITU-T Recommendation X.880 [3] defines a generic model for interactive communication between
objects, where the basic interaction involves the invocation of an operation by one object (the invoker) and
its performance by another (the performer). This model comes with a set of ASN.1 information object
classes to be used by protocol designers in the specification of ROS-based applications.
ITU-T Recommendation X.880 [3] recognizes that there are multiple possible realizations of this model, as
far as communication is concerned. The purpose of this annex is to demonstrate that TC can be
considered as one of these realizations, by providing a mapping of the generic concepts onto TC services.
ZA.1.2 Notation and concept for the generic ROS model
ITU-T Recommendation X.880 [3] defines several information object classes that are useful in the
specification of ROS-based application protocols. Such classes can be used by designers of TC-User
applications, as an alternative to the methodology described in ITU-T Recommendation Q.775. These
object classes are defined using the information object specification ASN.1 notation defined in ITU-T
Recommendation X.881 [4].
The OPERATION class is used to define an operation. It is equivalent to the OPERATION MACRO
defined in CCITT Recommendation X.219 [1] and ITU-T Recommendation Q.773 as modified by this
ETS.
The ERROR class is used to define an error. It is equivalent to the ERROR MACRO defined in CCITT
Recommendation X.219 [1] and ITU-T Recommendation Q.773 as modified by this ETS.
The OPERATION-PACKAGE class is used to define a set of operations which may only be invoked by a
ROS-object assuming the role of "consumer", the operations which may only be invoked by a ROS-object
assuming the role of "supplier", and the operations which may be invoked by both ROS-objects. When
using the communication services of SS7 or OSI, an operation package is realized as an Application
Service Element (ASE).
The CONNECTION-PACKAGE class is used to define the bind and unbind operations used to establish
and release an association. When realized using the communication services of SS7, a connection
package is realized as the procedures that use the structured dialogue handling services of TC.
Application contexts which do not require the explicit invocation of bind and unbind operations can still be
considered as including a connection package which uses the emptyBind and emptyUnbind pre-defined
operations.
The CONTRACT class is used to define an association contract in terms of a connection package and
one or more operation packages. When specifying the contract, those packages in which either only the
association initiator assumes the role of consumer, or only the association responder assumes the role of
consumer, or either may assume the role of consumer, are identified. When using the communication
services of SS7 or OSI, a contract is realized as an application context.
The ROS-OBJECT-CLASS class is used to define a set of common capabilities of a set of ROS-objects in
terms of the (association) contracts they support as initiators and/or responders. When realized using TC
or OSI, a ROS-object maps to an application process and a contract to an application context.
---------------------- Page: 9 ----------------------
SIST ETS 300 287-1:1998
Page 8
ETS 300 287-1: November 1996
ZA.1.3 Communication model
The realization of ROS involves the selection of a suitable medium to convey invocations and replies
between a pair of ROS-objects.
The possible media can be classified in two broad categories:
a) those required when the invoker and the performer are to be implemented in a single physical
equipment;
b) those required when the invoker and the performer are to be implemented in separated physical
equipment.
Category a) can be further divided into message-passing and procedure-calling facilities.
The medium in category b) depends on the type of network which interconnects the two objects and on
some Quality of Service (QoS) criteria.
ITU-T Recommendation X.880 [3] models the medium as being composed of two stub objects (one for
the invoker, one for the performer) and one information transfer object (see figure ZA.1). The information
transfer object capabilities also includes the association control functionalities which might be required to
set up an association between the application entities involved in the communication.
ROS Information ROS
Stub Stub
object transfer object
Medium
Figure ZA.1: Generic ROS communication model
The role of each stub object is merely to transform invocations and replies into protocol data units (and
vice-versa) they exchange using the information transfer object. For a given type of stub objects there are
several possible types of information transfer objects.
In the context of OSI, the stub objects are realized by the Remote Operation Service Element (ROSE)
while several information transfer realizations are available, using suitable combination of Association
Control Service Element (ACSE), Reliable Transfer Service Element (RTSE) and the presentation service.
The stub objects are realized by the Component Handling Block (CHA) of the TC Component Sub-Layer
(CSL, see ITU-T Recommendation Q.774 as modified by this ETS) together with a collection of operation-
specific ASEs (the TC-User ASEs). The CHA whose services are defined in subclause 3.1.3 of ITU-T
Recommendation Q.771 as modified by this ETS drives the generic protocol required to invoke and report
returns of arbitrary operations.
Each TC-User ASE embodies knowledge of the definitions of the specific operations involved in some
operation package. Collectively, the CSL and the TC-User ASEs have knowledge of all the operations of
the association contract.
---------------------- Page: 10 ----------------------
SIST ETS 300 287-1:1998
Page 9
ETS 300 287-1: November 1996
Application process Application process
ROS object ROS object
Application Entity Application Entity
O-ASEs O-ASEs
Stub Stub
CHA CHA
Component Component
sub-layer sub-layer
DHA DHA
Transaction sub-layer
Medium Information transfer
Figure ZA.2: TC realization of ROS
ZA.2 Remote operation service realization
ZA.2.1 Basic services (Stub)
The TC CSL provides the necessary services for supporting the invocation of operations and reporting
responses. It also provides additional local services for cancelling operation (TC-U-CANCEL request,
TC-L-CANCEL indication) or reporting locally detected protocol error (TC-L-REJECT indication).
NOTE: The following restrictions apply:
- whether an operation is synchronous or not is not taken into account (from a TC
point of view operations are always considered as being asynchronous.
However, the TC-User might behave in a synchronous manner);
- the set of allowed InvokeIds is restricted to the integer range (-128 to 127);
2)
- the priority field is ignored .
ZA.2.2 Bind and unbind operations
NOTE: In order to minimize the impact of Bind and Unbind operations on TC specifications,
this annex assumes that the TC-User constructs the bind and unbind APDUs and
transfers them to TC as if it would be ordinary user information. As a consequence, TC
is not aware that these operations are being invoked and cannot check that they are
used consistently with respect to the dialogue service and component handling service
(e.g. it cannot verify that no operation is requested after an unbind operation has been
invoked).
2)
This might evolve as the studies on priority handling in SS7 will progress.
---------------------- Page: 11 ----------------------
SIST ETS 300 287-1:1998
Page 10
ETS 300 287-1: November 1996
ZA.2.2.1 Bind operation
When an application context definition includes a connection package, the initiating TC-User invokes a
bind operation to be executed as part of the dialogue establishment procedure, prior to the execution of
any other operation. Failure of the execution of this operation leads to the rejection of the dialogue.
If the TC-User does not really need to invoke an explicit bind operation, it is assumed that it uses the
emptyBind pre-defined operation.
ZA.2.2.1.1 Invoking a bind operation
The TC-User can invoke a bind operation using the TC-BEGIN request primitive. If the definition of the
bind operation includes an &ArgumentType field, the TC-User constructs a bind-invoke PDU from this
information and transfers it as the first (or only part) of the user-information parameter of the TC-BEGIN
request primitive. Otherwise no bind-invoke PDU is sent.
NOTE: This should ensure that the bind-request PDU will be included in the first external field
of the user-information element of the Dialogue Request APDU (AARQ).
ZA.2.2.1.2 Responding to a bind operation
The TC-User reports the outcome a bind operation using the first dialogue handling primitive it issues.
Successful execution of the bind operation is reported using a TC-CONTINUE request primitive or a
TC-END request primitive if there is no need to continue the dialogue. In the latter case it needs also to
invoke an unbind operation.
NOTE: Use of the TC-END request primitive at this stage places restriction of the use of
unbind o
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.