Conceptio › Archive › ECMA International

ECMA Internationalopen access

ECMA-165 — Private Integrated Services Network (PISN) - Generic functional protocol for the support of supplementary services - Inter-exchange signalling procedures and protocol (QSIG-GF) (June 2001)

ECMA International · ECMA International

ECMA International · Standards · License: Open Access

ecma ecmainternational exchange integrated inter network pisn private

ecma, standard, ecma international, specification, ecma-165, ecma 165, 165, private, integrated, services, network, pisn, generic, functional, protocol, for, the, support, supplementary, inter-exchange, signalling, procedures, and, qsig-gf

S tandard ECMA-165

4th Edition - June 2001

Standardizing Information

and

Communication

Systems

Private Integrated Services Network (PISN) Generic Functional Protocol for the Support of Supplementary Services Inter-Exchange Signalling Procedures and Protocol

Phone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http://www.ecma.ch - Internet: [email protected]

S tandard ECMA-165

4th Edition - June 2001

Standardizing Information

and

Communication

Systems

Private Integrated Services Network (PISN) Generic Functional Protocol for the Support of Supplementary Services Inter-Exchange Signalling Procedures and Protocol (QSIG-GF)

Phone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http://www.ecma.ch - Internet: [email protected] IW

ECMA-165.DOC

04-09-02 09,49

Brief History

This Standard is one of a series of ECMA Standards defining services and signalling protocols applicable to Private Integrated Services Digital Networks (PISNs). The series uses ISDN concepts as developed by ITU-T and conforms to the framework of International Standards on Open Systems Interconnection as defined by ISO/IEC. It has been produced under ITSTC work items M-IT-05 5.1.3 and M-IT-05 5.1.2.2 and under ETSI work items DE/ECMA-00045 and RE/ECMA-00118. This particular Standard defines the signalling protocol for use at the Q reference point between two PINXs for the transport of protocol information as part of Supplementary Services and/or Additional Network Features (ANFs) within a PISN. The protocol defined in this Standard forms part of the PSS1 protocol (informally known as QSIG). The generic functional procedures provide a flexible and open ended approach to the provision of supplementary service and ANF protocols. These procedures provide: – generic protocols which may be utilised in the provision of supplementary services and ANFs, both related to existing calls and separate from existing calls where appropriate to the capability required; – a dialogue identification protocol to enable supplementary service or ANF information flows to be tied together to form a dialogue; – supplementary service and ANF transparency across a PISN, whereby transit PINXs need have no knowledge of the capability provided to the PISN user or PISN itself unless involved in the provision of that capability; and – the capability for standardised and manufacturer specific capabilities to coexist in both single and multi-vendor PISNs. The protocol defined in this Standard is based upon that described in ITU-T Recommendation Q.932 (1993). This Standard is based upon the practical experience of ECMA member companies and the results of their active and continuous participation in the work of ISO/IEC JTC1, ITU-T, ETSI and other international and national standardization bodies. It represents a pragmatic and widely based consensus. Compared to the 3 rd Edition of Standard ECMA-165 (published by ECMA in June 1997), this 4 th Edition incorporates changes in order to achieve complete alignment with International Standard ISO/IEC 11582:1995(E) published by ISO/IEC in July 1995, including Technical Corrigendum 1 (1995), Defect Report 1 (2000) and additional changes as listed in annex L.

Adopted as 4th Edition of Standard ECMA-165 by the General Assembly of June 2001.

List of corrected errata for ECMA-165 1 0 J u ly 2 0 0 2

Summary Following is a summary of errors detected and corrected in Standard ECMA-165, Private Integrated Services Network (PISN) - Generic Functional Protocol for the Support of Supplementary Services - Inter-Exchange Signalling Procedures and Protocol.

Clause 11.3.3.5, table 35 In the module Association-Control-Apdus-asn1-97, the Object Identifier of the ACSE-1 module is wrong. Original IMPORTS ACSE-apdu FROM ACSE-1 { joint-iso-itu-t association-control( 2) abstract-syntax( 1) apdus( 0) version( 1) };

Corrected IMPORTS ACSE-apdu FROM ACSE-1 { joint-iso-itu-t association-control(2) modules(0) apdus(0) version1( 1) };

Clause F.2, table F.3 Some of the Object Identifiers defined in the different Hypothetical-service-operation-asn1-97 modules are not well defined. Original Hypothetical-service-operation-asn1-97 { iso identified-organization icd-ecma member-company hypothetical-manufacturer hypothetical-service-offering-asn1-97 }

Corrected Hypothetical-service-operation-asn1-97 { iso( 1) identified-organization( 3) icd-ecma( 12) membercompany( 2) hypothetical-manufacturer( 1999) hypothetical-service-offering-asn1-97 ( 9999) }

Original IMPORTS

OPERATION FROM Remote-Operations-Information-Objects { joint-iso-ccitt( 2) remote-operations( 4) notation( 0) };

Corrected IMPORTS

OPERATION FROM Remote-Operations-Information-Objects { joint-iso-itu-t remote-operations(4) informationObjects(5) version1(0) };

Original CODE global: { iso( 1) identified-organization( 3) icd-ecma( 0012) member-company( 2) hypotheticalmanufacturer( 1999) hypothetical-manufacturer-service( 1) }

Corrected CODE global: { iso( 1) identified-organization( 3) icd-ecma( 12) member-company( 2) hypotheticalmanufacturer( 1999) hypothetical-manufacturer-service( 1) }

Clause F.2, table F.4 Some of the Object Identifiers defined in the different Hypothetical-service-operation-asn1-97 modules are not well defined. Original Hypothetical-service-operation-asn1-97 { iso standard hypothetical-Standard( 2222222) first-and-onlymodule-asn1-97 ( 0) }

Corrected Hypothetical-service-operation-asn1-97 { iso standard hypothetical-standard( 2222222) first-and-onlymodule-asn1-97 ( 0) }

Original IMPORTS

OPERATION FROM Remote-Operation-Notation { joint-iso-ccitt( 2) remote-operations( 4) notation( 0) };

Corrected IMPORTS

OPERATION FROM Remote-Operations-Information-Objects { joint-iso-itu-t remote-operations(4) informationObjects(5) version1(0) };

Clause F.2, table F.5 Some of the Object Identifiers defined in the different Hypothetical-service-operation-asn1-97 modules are not well defined. Original Hypothetical-service-operation-asn1-97 { iso standard hypothetical-Standard( 2222222) first-and-onlymodule-asn1-97 ( 0) }

Corrected Hypothetical-service-operation-asn1-97 { iso standard hypothetical-standard( 2222222) first-and-onlymodule-asn1-97 ( 0) }

Original IMPORTS

OPERATION FROM Remote-Operation-Notation { joint-iso-ccitt( 2) remote-operations( 4) notation( 0) };

Corrected IMPORTS

OPERATION FROM Remote-Operations-Information-Objects { joint-iso-itu-t remote-operations(4) informationObjects(5) version1(0) };

Original IDENTIFIER { iso identified-organization icd-ecma member-company hypothetical-manufacturer hypothetical-extension-number1 }

Corrected IDENTIFIER { iso identified-organization icd-ecma member-company hypothetical-manufacturer hypothetical-extension-number1 (1) }

Original IDENTIFIER { iso identified-organization icd-ecma member-company hypothetical-manufacturer hypothetical-extension-number2 }

Corrected IDENTIFIER { iso identified-organization icd-ecma member-company hypothetical-manufacturer hypothetical-extension-number2 (2) }

In addition replace all occurrences of Original extension {

CHOICE single [2] IMPLICIT Extension{{ExampleExtensionSet}} multiple [3] IMPLICIT SEQUENCE OF Extension{{ExampleExtensionSet}}

{

CHOICE single [2] IMPLICIT Extension{{ExampleExtensionSet}}, multiple [3] IMPLICIT SEQUENCE OF Extension{{ExampleExtensionSet}}

Corrected extension

- i -

Table of contents 1

Scope

Conformance

References (normative)

Definitions E x te r n a l d e f in itio n s ACSE APDU A d d itio n a l N e tw o r k F e a tu r e ( A N F ) Adjacent PINX A p p lic a tio n P r o to c o l D a ta U n it ( A P D U ) Call, Basic call Ca ll in d e p e n d e n t s ig n a llin g c o n n e c tio n Ca ll in d e p e n d e n t Call related Co n n e c tio n o r ie n te d Co n n e c tio n le s s Co o r d in a tio n F u n c tio n D e s tin a tio n P I N X DSE APDU D ia lo g u e S e r v ic e E le me n t ( D S E ) End PINX Gateway PINX G e n e r i c F u n c t i o n a l T r a n s p o r t C o n tr o l ( G F T - C o n tr o l ) e n t i t y I n c o min g s id e I n te r p r e ta tio n A P D U I n te r - P I N X lin k I n v o c a tio n L in k s ig n if ic a n c e Mis typ e d N e tw o r k s ig n if ic a n c e Next PINX N o tif ic a tio n O r ig in a tin g P I N X O u tg o in g s id e PINX address Preceding PINX P r iv a te S ig n a llin g S ys te m N o . 1 P r o to c o l Co n tr o l RO S E A P D U S id e S ig n a llin g Ca r r ia g e Me c h a n is m ( S CM) Source PINX

2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5

4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 4.19 4.20 4.21 4.22 4.23 4.24 4.25 4.26 4.27 4.28 4.29 4.30 4.31 4.32 4.33 4.34 4.35 4.36 4.37

- ii -

4.38 4.39 4.40 4.41 4.42 4.43 4.44 5 6

Subsequent PINX S u p p le me n ta r y s e r v ic e S u p p l e me n t a r y S e r v i c e s Co n t r o l ( S S - C o n t r o l ) e n t i t y T e r min a tin g P I N X T e r min a l, T e r min a l E q u ip me n t T r a n s it P I N X U n r e c o g n is e d Lis t o f a c r o n y m s

5 5 5 5 5 5 5 5

General principles A p p lic a tio n A s s o c ia tio n P r o to c o l Mo d e l A p p l i c a t i o n o f t h e p r o to c o l mo d e l t o c o mmu n ic a t i o n b e t w e e n S S - C o n tr o l e n t i t i e s i n non-Adjacent PINXs 6 . 4 S e r v ic e s p r o v id e d b y RO S E 6 . 5 S e r v ic e s p r o v id e d b y A CS E 6 . 6 S e r v ic e s p r o v id e d b y D S E 6 . 7 S e r v ic e s p r o v id e d b y G F T - Co n tr o l 6.7.1 Co n n e c tio n o r ie n te d s e r v ic e s 6.7.2 Co n n e c tio n le s s tr a n s p o r t s e r v ic e s 6.7.3 N o tif ic a tio n s e r v ic e s 6 . 8 S e r v ic e s p r o v id e d b y P r o to c o l Co n tr o l to G F T - Co n tr o l 6.8.1 Co n n e c tio n o r ie n te d tr a n s p o r t s e r v ic e s 6.8.2 Co n n e c tio n le s s tr a n s p o r t s e r v ic e 6.8.3 N o tif ic a tio n s e r v ic e s 6 . 9 S e r v ic e s r e q u ir e d o f th e S ig n a llin g Ca r r ia g e Me c h a n is m

8 9 9 9 10 10 11 11 12 12 13 13 13

Protocol Control and GFT-Control Requirements 7 . 1 Ca ll r e la te d P r o c e d u r e s f o r th e tr a n s p o r t o f A P D U s 7.1.1 P r o to c o l Co n tr o l r e q u ir e me n ts 7.1.2 G F T - Co n tr o l r e q u ir e me n ts 7 . 2 Co n n e c tio n le s s A P D U T r a n s p o r t Me c h a n is m 7.2.1 P r o to c o l Co n tr o l r e q u ir e me n ts 7.2.2 Co n tr o l r e q u ir e me n ts 7 . 3 Co n n e c tio n o r ie n te d c a ll in d e p e n d e n t A P D U tr a n s p o r t me c h a n is m 7.3.1 P r o to c o l Co n tr o l r e q u ir e me n ts 7.3.2 D yn a mic D e s c r ip tio n ( S D L ) o f Co n n e c tio n o r ie n te d P r o to c o l Co n tr o l p r o c e d u r e s 7.3.3 G e n e r ic F u n c tio n a l T r a n s p o r t Co n tr o l r e q u ir e me n ts 7 . 4 Ca ll r e la te d p r o c e d u r e s f o r th e tr a n s p o r t o f N o tif ic a tio n s 7.4.1 Ca te g o r ie s o f n o tif ic a tio n s 7.4.2 P r o to c o l Co n tr o l r e q u ir e me n ts 7.4.3 G F T - Co n tr o l r e q u ir e me n ts

13 13 13 14 22 22 22 23 23 28 34 37 37 37 38

Application layer requirements 8 . 1 Co o r d in a tio n F u n c tio n r e q u ir e me n ts 8.1.1 I n c lu s io n o f a n I n te r p r e ta tio n A P D U a t a S o u r c e P I N X

38 38 38

6.1 6.2 6.3

6 6 7

- iii -

8.1.2 H a n d lin g o f A P D U s a t a D e s tin a tio n P I N X 8 . 2 RO S E r e q u ir e me n ts 8 . 3 A CS E r e q u ir e me n ts 8 . 4 D S E r e q u ir e me n ts 8.4.1 Actions at the PINX which initiates the dialogue (PINX A) 8.4.2 A c tio n s a t th e P I N X w h ic h te r min a te s th e d ia lo g u e ( P I N X B) 8.4.3 D ia lo g u e Co n tin u a tio n in th e A c tiv e S ta te 8.4.4 D ia lo g u e P r o to c o l T ime r s 8.4.5 E r r o r p r o c e d u r e s r e la tin g to d ia lo g u e c o n tr o l 8.4.6 E x a mp le o f a d ia lo g u e 8.4.7 D yn a mic D e s c r ip tio n ( S D L ) o f D ia lo g u e I d e n tif ic a tio n P r o to c o l P r o c e d u r e s 8 . 5 S S - Co n tr o l r e q u ir e me n ts 9 9.1 9.2 9.3

Manufacturer Specific Information Ma n u f a c tu r e r s p e c if ic o p e r a tio n s Ma n u f a c tu r e r s p e c if ic a d d itio n s to s ta n d a r d is e d o p e r a tio n s Ma n u f a c tu r e r s p e c if ic n o tif ic a tio n s

39 39 39 40 40 41 41 41 42 42 42 47 47 47 48 49

10 M e s s a g e f u n c t io n a l d e f in it io n s a n d c o n t e n t s 10.1 A L E RT I N G 10.2 CA L L P RO CE E D I N G 10.3 CONNECT 10.4 SETUP 10.5 DISCONNECT 10.6 RELEASE 10.7 RELEASE COMPLETE 10.8 F A CI L I T Y 10.9 NOTIFY 1 0 . 1 0 P RO G RE S S

49 49 49 50 50 50 51 51 51 52 52

11 General message format and information element coding 11.1 Me s s a g e T yp e 11.2 Call reference 11.3 O th e r in f o r ma tio n e le me n ts 11.3.1 Bearer capability 11.3.2 Ch a n n e l id e n tif ic a tio n 11.3.3 Facility 11.3.4 N o tif ic a tio n in d ic a to r 11.4 E n c o d in g o f in f o r ma tio n d e s c r ib e d u s in g A S N . 1

52 52 53 53 53 54 54 63 65

A n n e x A - P r o t o c o l I m p l e m e n t a t i o n C o n fo r m a n c e S t a t e m e n t ( P I C S ) f o r E C M A - 1 6 5

Annex B - ASN.1 definitions of generic parameters

A n n e x C - A p p lic a t io n o f t h e f u n c t io n a l p r o t o c o l

A n n e x D - R e m o t e o p e r a t io n s p r o t o c o l a n d a p p lic a t io n a s s o c ia t io n c o n t r o l

- iv -

Annex E - Formal ROSE Definitions

Annex F - Examples of the use of Manufacturer specific information

A n n e x G - P r o b le m c o d e d e f in it io n s

103

Annex H - Bibliography

105

A n n e x I - O b j e c t id e n t if ie r s d e f in e d in EC M A - 1 6 5

107

A n n e x J - “ R e c ip e ” f o r m ig r a t io n o f X . 2 0 8 / X . 2 0 9 b a s e d Q S I G A S N . 1 m o d u le s t o X.680 / X.690 ASN.1

109

A n n e x K - A S N . 1 d e f in it io n s a c c o r d in g t o I TU - T R e c s . X . 2 0 8 / X . 2 0 9

115

A n n e x L - Te c h n ic a l c h a n g e s s in c e t h ir d e d it io n o f EC M A - 1 6 5

127

Scope This Standard defines the signalling protocol for the control of Supplementary Services and Additional Network Features (ANFs) at the Q reference point. The protocol is part of Private Signalling System no. 1 (PSS1), known informally as QSIG. The Q reference point exists between Private Integrated services Network eXchanges (PINXs) connected together within a Private Integrated Services Network (PISN) and is defined in ECMA-133. Detailed procedures applicable to individual supplementary services and ANFs are beyond the scope of this Standard and will be specified by other standards for those services which are standardised and by individual manufacturers for proprietary services using the capabilities defined in this Standard. ECMA-143 defines the Layer 3 protocol for circuit-switched call control at the Q reference point. This Standard defines additional protocol procedures, to be used in conjunction with those defined in ECMA-143 for the control of supplementary services and ANFs. NOTE 1 Typical examples of the application of these generic functional procedures to some supplementary services are provided in annex C, for explanatory and illustrative purposes only. NOTE 2 Specific supplementary services and Additional Network Features may require additional information transfer mechanisms which are service or feature specific and are beyond the scope of this Standard.

Conformance In order to conform to this Standard, a PINX shall satisfy the requirements identified in the Protocol Implementation Conformance Statement (PICS) proforma in annex A.

References (normative) The following standards contain provisions which, through reference in this text, constitute provisions of this Standard. All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. In the case of references to ECMA Standards that are aligned with ISO/IEC International Standards, the number of the appropriate ISO/IEC International Standard is given in brackets after the ECMA reference. ECMA-133

Private Integrated Services Network (PISN) - Reference Configuration for PISN Exchanges (PINX) (International Standard ISO/IEC 11579-1)

ECMA-142

Private Integrated Services Network (PISN) - Circuit Mode 64kbit/s Bearer Services Service Description, Functional Capabilities and Information Flows (International Standard ISO/IEC 11574)

ECMA-143

Private Integrated Services Network (PISN) - Circuit Mode Bearer Services - InterExchange Signalling Procedures and Protocol (International Standard ISO/IEC 11572)

ECMA-155

Private Integrated Services Networks - Addressing (International Standard ISO/IEC 11571)

ECMA-225

Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol - Transit Counter Additional Network Feature (International Standard ISO/IEC 15056)

ISO/IEC 6523-1

Information technology - Structure for the identification of organizations and organization parts - Part 1: Identification of organization identification schemes (1998)

ISO/IEC 6523-2

Information technology - Structure for the identification of organizations and organization parts - Part 2: Registration of organization identification schemes (1998)

ITU-T Rec. I.112

Vocabulary of terms for ISDNs (1993)

- 2 -

ITU-T Rec. I.210

Principles of telecommunication services supported by an ISDN and the means to describe them (1993)

ITU-T Rec. Q.932 Digital subscriber signalling system No. 1 - Generic procedures for the control of ISDN supplementary services (1998) ITU-T Rec. X.217 Information technology - Open Systems Interconnection - Service definition for the association control service element (1995) ITU-T Rec. X.227 Information technology - Open Systems Interconnection - Connection-oriented protocol for the association control service element: Protocol specification (1995) ITU-T Rec. X.680 Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation (1997) ITU-T Rec. X.681 Information technology - Abstract Syntax Notation One (ASN.1): Information object specification (1997) ITU-T Rec. X.682 Information technology - Abstract Syntax Notation One (ASN.1): Constraint specification (1997) ITU-T Rec. X.683 Information technology - Abstract Syntax Notation One (ASN.1): Parameterization of ASN.1 specifications (1997) ITU-T Rec. X.690 Information technology - ASN.1 encoding rules - Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) (1997) ITU-T Rec. X.880 Information technology - Remote Operations: Concepts, model and notation (1994) ITU-T Rec. X.881 Information technology - Remote Operations: OSI realizations - Remote Operations Service Element (ROSE) service definition (1994) ITU-T Rec. X.882 Information technology - Remote Operations: OSI realizations - Remote Operations Service Element (ROSE) protocol specification (1994)

Definitions For the purposes of this Standard, the following definitions apply:

4.1

External definitions This Standard uses the following terms defined in other documents:

4.2

–

Object Identifier

(ITU-T Rec. X.680)

–

Private Integrated services Network eXchange (PINX)

(ECMA-133)

–

Private Integrated Services Network

(ECMA-133)

–

Service

(ITU-T Rec. I.112)

–

Signalling

(ITU-T Rec. I.112)

–

User

(ECMA-142)

ACSE APDU An APDU defined by the Association Control Service Element (ACSE).

4.3

Additional Network Feature (ANF) A capability provided by a PISN, not generally directly to a User, over and above that of the Basic call.

4.4

Adjacent PINX A PINX as considered from another PINX to which it is directly connected via one or more inter-PINX links.

- 3 -

4.5

Application Protocol Data Unit (APDU) A sequence of data elements exchanged between peer application layer entities, e.g. ACSE APDUs, DSE APDUs and ROSE APDUs.

4.6

Call, Basic call An instance of the use of a basic service.

4.7

Call independent signalling connection A signalling connection established between SS-Control entities located in different PINXs that does not have an associated user-information connection.

4.8

Call independent A property of information which is conveyed across the Q reference point in a message which does not use a call reference which has an associated user-information connection (that is, using a Connectionless or Connection oriented transport mechanism as defined in 7.2 or 7.3).

4.9

Call related A property of information which is conveyed across the Q reference point in a message which uses a call reference which has an associated user-information connection.

4.10

Connection oriented Communication between peer protocol entities by means of a connection or association established by an underlying layer.

4.11

Connectionless Communication between peer protocol entities by means of an unacknowledged, unidirectional transport mechanism provided by an underlying layer.

4.12

Coordination Function An entity which provides coordination between various SS-Control entities, ROSE, ACSE, DSE, GFTControl and Call Control for different supplementary services (see clause 6).

4.13

Destination PINX In the context of a single one-way exchange of information between two SS-Control entities, the PINX where the receiving SS-Control entity is located.

4.14

DSE APDU An APDU defined by the Dialogue Service Element.

4.15

Dialogue Service Element (DSE) A service element which provides services to SS-Control via the Coordination Function that associate ROSE or ACSE APDUs which are not implicitly associated by an underlying network layer connection.

4.16

End PINX In the context of a particular call, an Originating or Terminating PINX. It can also be a Gateway PINX, dependent on the capabilities of the signalling system being interworked (i.e. unless it transports APDUs unchanged to or from the other signalling system).

4.17

Gateway PINX Sub-clause 4.6 of ECMA-143 shall apply. Dependent on the capabilities of the signalling system being interworked by the Gateway PINX, it can act as a Transit or an End PINX in the context of the supplementary services APDUs. That is, it can either transport the APDUs unchanged to or from the other signalling system, perhaps embedded in some other protocol unit, or process the APDUs and perform an interworking function of the information flows and encoding of the supplementary service concerned.

4.18

Generic Functional Transport Control (GFT-Control) entity The entity that exists within a PINX and provides a range of services (defined in clause 6) to SS-Control, ROSE, ACSE and DSE via the Coordination Function.

- 4 -

4.19

Incoming side In the context of a Call independent signalling connection, the Side which receives the request for connection establishment from the Preceding PINX.

4.20

Interpretation APDU An APDU defined by the Coordination Function.

4.21

Inter-PINX link The totality of a signalling channel and a number (≥ 0) of user information channels (which may have different characteristics) at the Q reference point.

4.22

Invocation A request by a SS-Control entity to perform an operation in a remote SS-Control entity.

4.23

Link significance A property of a Facility information element which does not contain a Network Facility Extension octet group. It indicates that the element has only significance on a single inter-PINX link - i.e. only between two Adjacent PINXs.

4.24

Mistyped A property of an APDU whose structure does not conform to the structure defined in clause 11 of this Standard or the structure defined for a particular supplementary service.

4.25

Network significance A property of a Facility information element which includes a Network Facility Extension octet group. It indicates that the element has significance between two PINXs which are not necessarily Adjacent.

4.26

Next PINX An Adjacent PINX to which an APDU is to be sent in the context of an existing signalling connection (related to a call or independent of a call).

4.27

Notification A piece of protocol information which has the following properties:

4.28

–

it is intended to be delivered only to terminals and is therefore passed on transparently by PINXs;

–

it does not cause a change of state on either side of the Q reference point;

–

it represents a one-way flow of information that requires no response; and

–

it provides additional information that can be discarded without the need for significant error recovery if it is unrecognised by the terminal.

Originating PINX Sub-clause 4.5 of ECMA-143 shall apply. In addition, the term is also applied to a PINX which originates a Call independent signalling connection.

4.29

Outgoing side In the context of a Call independent signalling connection, the Side which sends the request for connection establishment to the Next PINX.

4.30

PINX address A PISN number as defined in ECMA-155 that is a complete number and that unambiguously identifies the addressed PINX or an addressable entity associated with that PINX.

4.31

Preceding PINX Sub-clause 4.7 of ECMA-143 shall apply. In addition, the term is also applied in a similar way to a PINX participating in a Call independent signalling connection.

- 5 -

4.32

Private Signalling System No.1 The generic name given to the signalling protocol that exists conceptually at the ‘Q’ reference point and is defined in this and other Standards. This protocol is visible and indirectly testable at the ‘C’ reference point (see ECMA-133).

4.33

Protocol Control An entity which exists within a PINX and provides a range of services (defined in clause 6) to the Generic Functional Transport Control entity.

4.34

ROSE APDU An APDU defined by the Remote Operations Service Element (ROSE).

4.35

Side The Protocol Control entity within a PINX at one end of an inter-PINX link.

4.36

Signalling Carriage Mechanism (SCM) The infrastructure that transports messages between Protocol Control entities in two interconnected PINXs.

4.37

Source PINX In the context of a single one-way exchange of information between two SS-Control entities, the PINX where the sending SS-Control entity is located.

4.38

Subsequent PINX Sub-clause 4.7 of ECMA-143 shall apply. In addition, the term is also applied in a similar way to a PINX participating in a Call independent signalling connection.

4.39

Supplementary service Section 2.4 of ITU-T Recommendation I.210 shall apply. For the purpose of this Standard, ANFs shall be regarded as supplementary services.

4.40

Supplementary Services Control (SS-Control) entity An entity that exists within a PINX and provides the procedures associated with the support of a particular supplementary service.

4.41

Terminating PINX Sub-clause 4.5 of ECMA-143 shall apply. In addition, the term is also applied to a PINX which terminates a Call independent signalling connection.

4.42

Terminal, Terminal Equipment An item of equipment attached to a telecommunication network to provide access for a user to one or more services.

4.43

Transit PINX Sub-clause 4.5 of ECMA-143 shall apply. In addition, the term is also applied to a PINX which participates in the provision of a Call independent signalling connection, but does not originate or terminate that connection.

4.44

Unrecognised A property of a message, information element, APDU or operation value whose type identifier is not one supported by the Destination PINX.

List of acronyms ACSE

Association Control Service Element

Application Entity

ANF

Additional Network Feature

APDU

Application Protocol Data Unit

- 6 -

ASN.1

Abstract Syntax Notation One

BER

Basic Encoding Rules

DSE

Dialogue Service Element

DSS1

Digital Subscriber Signalling no. 1

FIE

Facility information element

GFT

Generic Functional Transport

ICD

International Code Designator

MSI

Manufacturer Specific Information

NFE

Network Facility Extension

Protocol Control

PICS

Protocol Implementation Conformance Statement

PINX

Private Integrated services Network eXchange

PISN

Private Integrated Services Network

PSS1

Private Signalling System no. 1

Remote Operations

ROSE

Remote Operations Service Element

RTSE

Reliable Transfer Service Element

SCM

Signalling Carriage Mechanism

Supplementary Service

General principles The generic functional protocol defined in this Standard provides the means to exchange signalling information for the control of supplementary services over a PISN. It does not by itself control any supplementary service but rather provides generic services to specific SS-Control entities. Procedures for individual supplementary services based on these generic procedures are defined in other standards or may be manufacturer-specific. The generic functional protocol operates at the Q reference point between two PINXs in conjunction with a Layer 3 protocol for Basic call control (ECMA-143). Together these use the services of the Signalling Carriage Mechanism (SCM). The generic functional protocol provides mechanisms for the support of supplementary services which relate to existing basic calls or are entirely independent of any existing basic calls. In performing a supplementary service, whether Call independent or Call related, use may be made of both the Call related (7.1) and Call independent (7.2 and 7.3) information transfer procedures. If a particular supplementary service comprises Call related and Call independent information transfer procedures or relates to several basic calls at the same time it is - for the purpose of this Standard - deemed to consist of separate instances of Call related (one for each call) and Call independent services respectively. The combined use of two or more instances of Call related and/or Call independent procedures in support of a particular supplementary service is outside the scope of this Standard.

6.1

Application Association Supplementary service operations require an association between the respective peer SS-Control entities. This Standard provides three means by which this association can be achieved: a) implicitly by the network layer connection in the case of Call related connections and for callindependent signalling connections;

- 7 -

b) implicitly by the application layer dialogue service, in which case the association is independent of the underlying network layer connections and can use a combination of different mechanisms, including Call independent Connectionless information transfer or, c) explicitly by use of the Association Control Service Element (ACSE, X.217/227) in conjunction with the underlying mechanisms provided in (a) and (b).

6.2

Protocol Model Figure 1 shows the conceptual model for the generic functional protocol and its relation to the Basic call model defined in ECMA-143. SS-Control #1

Call Control

Coordination Function

• • • • SS-Control #n ROSE ACSE DSE

GFT Control

Protocol Control

Signalling Carriage Mechanism (SCM)

NOTE The capabilities defined in this Standard are indicated by shading, i.e. GFT-Control, DSE, ACSE, ROSE and extensions to Protocol Control. Part of the functions of the Coordination Function are also defined in this Standard, but the remainder of this element governs supplementary service specific interactions which are beyond the scope of this Standard. F ig u r e 1 - P S S 1 P r o t o c o l M o d e l At the top layer (the application layer) the actual supplementary service protocol operates between peer Supplementary Services Control (SS-Control) entities which are service-specific. The operation of specific SS-Control entities is beyond the scope of this Standard. SS-Control entities use the services of the Remote Operations Service Element (ROSE), the Association Control Service Element (ACSE) and the Dialogue Service Element (DSE) at the application layer via the Coordination Function. These entities use the services of Generic Functional Transport Control (GFTControl) at the network layer via the Coordination Function. GFT-Control uses the services of Protocol Control at the network layer.

- 8 -

The Remote Operations Service Element (ROSE) is defined in ITU-T Rec. X.881. The Association Control Service Element (ACSE) is defined in ITU-T Rec. X.217. NOTE In the application of ROSE for the support of supplementary services in PSS1 the underlying services used by ROSE are those provided by GFT-Control or those provided by the Association Control Service Entity (ACSE). No use is made of the services of the Reliable Transport Service Element (RTSE). The Dialogue Service Element (DSE) provides a means of associating ACSE or ROSE APDUs which are not implicitly associated by an underlying network layer connection. The Coordination Function provides coordination between GFT-Control, the various SS-Control entities, ROSE, ACSE, DSE and Call Control for different supplementary services. The relationships it coordinates are beyond the scope of this Standard. It also provides functions to support the handling of unrecognised APDUs. GFT-Control provides two distinct types of service via the Coordination Function: –

transport services for the carriage of Notifications, ROSE APDUs, ACSE APDUs and DSE APDUs between SS-Control entities in different PINXs, including transparent relaying through Transit PINXs. These services can be related to a Call or independent of a Call; and,

–

establishment and release of Call independent signalling connections.

Protocol Control is an extension of the existing Protocol Control entity. It provides services to GFTControl for: –

the transport of APDUs between Adjacent PINXs;

–

the establishment and release of signalling connections (Call independent Connection oriented service) between Adjacent PINXs.

This entity builds on the ECMA-143 (Basic call) Protocol Control in the following way: –

the Call related transfer of APDUs uses the call reference established for the call by Protocol Control. This can be either by: • the combination of Basic call control information and APDUs in the same ECMA-143 message if they appear concurrently at the Protocol Control service access points; or, • the transfer of APDUs in a message defined in this Standard associated with the call reference, when no Call Control primitive appears at the Protocol Control service access point.

–

6.3

Call independent signalling connections use the call reference mechanism of Protocol Control and some of the messages and procedures.

Application of the protocol model to communication between SS-Control entities in non-Adjacent PINXs Figure 2 shows the application of the protocol model to the case where communication occurs between SSControl entities in two PINXs via a single Transit PINX. It may be applied to communication via more than one Transit PINX by simple replication.

- 9 -

Transit PINX

End PINX

SS-C

ROSE

Coordination Function

End PINX

ROSE Application layer protocol

ACSE

DSE

GFT Control

Protocol Control

GFT Control Network Layer Protocol

SCM

Protocol Control

SCM

Network Layer Protocol

GFT Control

Protocol Control

SCM

SS-C = SS-Control

F ig u r e 2 - A p p lic a t io n o f t h e p r o t o c o l m o d e l t o c o m m u n i c a t i o n b e t w e e n n o n - A d j a c e n t P I N X s In figure 2, relaying functions at the Transit PINX are performed by GFT-Control. If communication is Call related, each of the PINXs in which the SS-Control entities are located may be either an End or a Transit PINX. For simplicity, the Call Control entities are not shown. If communication is in the context of a Call independent signalling connection, one of the PINXs in which the SS-Control entities are located is the Originating PINX and the other is the Terminating PINX. The Signalling Carriage Mechanism (SCM) is described in ECMA-143.

6.4

Services provided by ROSE ROSE provides a set of services to SS-Control to support the ROSE protocol. Primitives for these services are specified in X.881 and relate to the following ROSE APDUs: Invoke, ReturnResult, ReturnError and Reject.

6.5

Services provided by ACSE ACSE provides a set of services to establish and release an explicit Application association. Primitives for these services are specified in X.217 and relate to the following ACSE APDUs: Associate request, Associate response, Release request, Release response and Abort.

6.6

Services provided by DSE DSE provides the services shown in table 1 to SS-Control via the Coordination Function, with their contents indicated as either Mandatory (M) or Optional (O). These services are used for creating and terminating a Dialogue which associates peer SS-Control entities and for exchanging ACSE or ROSE APDUs within such an association.

- 10 -

Table 1 - Services provided by DSE – Dialog Begin Originating Dialog Identifier ROSE APDU(s) (Note)

Req/Ind M O

– Dialog Continue Originating Dialog Identifier Destination Dialog Identifier ROSE APDU(s) (Note)

Req/Ind M M O

– Dialog End Destination Dialog Identifier ROSE APDU(s) (Note)

Req/Ind M O

– Dialog Abort Destination Dialog Identifier User Abort Cause

Req/Ind M M

NOTE This element can contain one or more ACSE or ROSE APDUs.

6.7

Services provided by GFT-Control This entity provides the following services to SS-Control, ACSE, ROSE and DSE via the Coordination Function, with their contents indicated as either Mandatory (M) or Optional (O).

6.7.1

Connection oriented services The services shown in table 2 are provided for the control of the establishment and clearing of a Call independent signalling connection between the PINXs in which the peer SS-Control entities exist. NOTE 1 It is envisaged that the majority of supplementary services requiring call independent APDU transport will make use of a Call independent signalling connection via the use of the services shown in tables 2 and 3. Table 2 - Connection oriented services – GF-Setup Origination Address Destination Address Data (Note 2)

Req/Ind O M O

– GF-Release Cause Data (Note 2)

Req/Ind M O

– GF-Reject Cause Data (Note 2)

Req/Ind M O

Resp/Conf O O

NOTE 2 This element shall contain one or more APDUs and an indication of the destination of these APDUs on the connection path. APDUs may be ACSE APDUs, DSE APDUs or ROSE APDUs. It may also contain an interpretationAPDU generated by the Coordination Function. The service shown in table 3 is provided and is used for the conveyance of APDUs on a signalling connection (Call related or Call independent) between the PINXs in which the peer SS-Control entities exist.

- 11 -

Table 3 - Connection oriented services – GF-Data Req/Ind Data (Note 3) M Basic Call Correlation (Note 4) O NOTE 3 This element shall contain one or more APDUs and an indication of the destination of these APDUs on the connection path. APDUs may be ACSE APDUs, DSE APDUs or ROSE APDUs. It may also contain an interpretationAPDU generated by the Coordination Function. NOTE 4 This element shall be included if SS-Control requires that the Data to be conveyed is to be conveyed in conjunction with a specific basic call control message. 6.7.2

C o n n e c t io n le s s t r a n s p o r t s e r v ic e s The service shown in table 4 is provided to effect the transport of APDUs between two peer SS-Control entities without the use of a network layer connection. It is an unconfirmed service. Table 4 - Connectionless services – GF-Unitdata Origination Address Destination Address Data (Note)

Req/Ind M M M

NOTE This element shall contain one or more APDUs. APDUs may be ACSE APDUs, DSE APDUs or ROSE APDUs. It may also contain an interpretationAPDU generated by the Coordination Function. 6.7.3

N o t if ic a t io n s e r v ic e s The service in table 5 is provided to SS-Control via the Coordination Function. This service is used to effect the transport of notifications associated with the network layer signalling connection of a Call. Table 5 - Notification services – GF-Notify Notification Basic Call Correlation (Note)

Req/Ind M O

NOTE This element shall be included if SS-Control requires that the Notification is conveyed in conjunction with a specific basic call control message.

- 12 -

6.8

Services provided by Protocol Control to GFT-Control The following services are provided, with their contents indicated as either Mandatory (M) or Optional (O).

6.8.1

C o n n e c t io n o r ie n t e d t r a n s p o r t s e r v ic e s The services in table 6 provide the Connection oriented network service for Call independent supplementary service control. These services are used for the establishment and clearing of Call independent signalling connections between Adjacent PINXs. Table 6 - Connection oriented transport services – PC-Setup Origination Address Destination Address Data (Note 1)

Req/Ind O M O

– PC-Release Cause Data (Note 1)

Req/Ind M O

– PC-Reject Cause Data (Note 1)

Req/Ind M O

Resp/Conf O O

NOTE 1 This element shall contain one or more APDUs and an indication of the destination of these APDUs on the connection path. NOTE 2 These primitives are similar to the primitives defined in 6.2 of ECMA-143 for provision of services to Call Control. The service in table 7 is provided to GFT-Control for the conveyance of APDUs between Adjacent PINXs in association with a Basic call or Call independent signalling connection. Table 7 - Connection oriented transport services – PC-Data Data (Note 3) Basic Call Correlation (Note 4)

Req/Ind M O

NOTE 3 This element shall contain one or more APDUs and an indication of the destination of these APDUs on the connection path. NOTE 4 This element shall be included if the APDUs to be conveyed are to be conveyed in conjunction with a specific basic call control message.

- 13 -

6.8.2

C o n n e c t io n le s s t r a n s p o r t s e r v ic e The service in table 8 is provided to GFT-Control to effect the transport of APDUs between two Adjacent PINXs without the use of a network layer connection. Table 8 - Connectionless transport services – PC-Unitdata Origination Address Destination Address Data (Note)

Req/Ind M M M

NOTE This element shall contain one or more APDUs. 6.8.3

N o t if ic a t io n s e r v ic e s The service in table 9 is provided to GFT-Control. This service is used to effect the transport of notifications between Adjacent PINXs in association with the network layer signalling connection of a Call. Table 9 - Notification transport services

– PC-Notify Notification Basic Call Correlation (Note)

Req/Ind M O

NOTE This element shall be included if the Notification is to be conveyed in conjunction with a specific basic call control message.

6.9

Services required of the Signalling Carriage Mechanism The services required by Protocol Control are as specified in 6.3 of ECMA-143.

Protocol Control and GFT-Control Requirements

7.1

Call related Procedures for the transport of APDUs This clause describes the procedures required to transport Call related APDUs. NOTE The APDUs need not directly relate to the provision or state of the Call which provides the signalling connection over which the information is carried. If the Call fails and the connection is cleared down for any reason, APDUs that are in the process of being sent may never reach their destination. In such a case, the APDUs will be discarded. It is the responsibility of the supplementary service protocol to cater for this eventuality.

7.1.1 Protocol Control requirements 7.1.1.1 Sending the Facility information element When requested by GFT-Control, the Facility information element may be sent at any time during a call (i.e. where a call reference exists) subject to the following conditions: –

If a call establishment or a call clearing message that may contain a Facility information element (see clause 10) or a PROGRESS message is to be sent in the context of a Basic call and GFTControl has requested that the Facility information element be carried in that message, the Facility information element shall be included in that message.

–

otherwise, the Facility information element shall be carried in a FACILITY message.

Four exceptions where the Facility information element shall not be sent in a FACILITY message and an indication of transmission failure given to GFT-Control are: –

when no response has been received to a previously sent SETUP message (as defined in 10.1 of ECMA-143);

- 14 -

–

when no response has been sent to a previously received SETUP message (as defined in 10.1 of ECMA-143);

–

when the Facility information element is of network significance and a call clearing message has already been sent or received on the inter-PINX link; or

–

if no call establishment or clearing message is to be sent and a RELEASE or RELEASE COMPLETE message has been sent or received on the inter-PINX link.

NOTE 1 Further actions by the GFT-Control entity in such a situation (e.g. if the Facility information element was received from the Subsequent PINX) are implementation dependent. In designing protocols for supplementary services in a PISN, account should be taken of the fact that an end to end Call related signalling relationship cannot be guaranteed until the receipt of the first end to end Basic call message. NOTE 2 In the case where the Facility information element is sent to a PINX which does not conform to this Standard, the Facility information element will be discarded by that PINX and a STATUS message may be received (see clause 9 in ECMA-143). The STATUS message will indicate that either: the Facility information element was unrecognised; or, that the message (FACILITY) was unrecognised. In such cases, the recovery action, if any, is an implementation specific matter. 7.1.1.2

Receiving the Facility information element A PINX receiving a Facility information element in a valid call clearing or call establishment message (see clause 10) or a PROGRESS or FACILITY message shall pass the entire contents of that information element to GFT-Control. Protocol Control shall treat any value in octets 3.1 onwards as valid, and therefore the ECMA-143 procedures for information elements with invalid contents shall not apply to these octets.

7.1.2 GFT-Control requirements 7.1.2.1 Actions at a Source PINX On receipt of a request for APDU transport from the Coordination Function, the APDUs to be transported shall be encoded in a Facility information element, as defined in 11.3.3. APDUs may be of two basic types: –

Those which have only Link significance, i.e. over a single link of the PISN, between two Adjacent PINXs; or,

–

Those which have Network significance, between two PINXs in the PISN which are not necessarily adjacent, and which can be, but need not be, the End PINXs involved in the call.

If the APDUs have link significance, the Network Facility Extension (NFE), defined in 11.3.3.1, need not be included in the Facility information element (although it may optionally be included, explicitly identifying the Adjacent PINX). If the APDUs have network significance, the NFE shall be included, encoded as described in table 10. NOTE 1 The Facility information element may contain one or more APDUs. If more than one APDU is contained in a single Facility information element, they will all be processed by the Destination PINX. How and if these requests are related is beyond the scope of this Standard.

- 15 -

Table 10 - Encoding of NFE Case

Communication

Required coding of NetworkFacilityExtension for each identified case

No.

between ..

Encoding of sourceEntity

Encoding of sourceEntityAddress

Encoding of destinationEntity

Encoding of destinationEntityAddress

End PINX (Originating or Terminating) =>

endPINX

NOT included

endPINX

NOT included

anyTypeOfPINX

PINX Address

NOT included

anyTypeOfPINX

NOT included

anyTypeOfPINX

PINX Address

endPINX

NOT included

anyTypeOfPINX

PINX Address

anyTypeOfPINX

PINX Address

anyTypeOfPINX

PINX Address

anyTypeOfPINX

NOT included

(Note)

End PINX (Terminating or Originating, depending on direction of FIE) 2

End PINX (Originating or Terminating) =>

endPINX (Note)

addressed PINX 3

End PINX (Originating or Terminating) =>

endPINX (Note)

Next PINX which understands contents 4

Transit PINX => Terminating or Originating PINX (depending on direction of FIE)

Transit PINX => addressed PINX

Transit PINX => Next PINX NOTE

The value endPINX for the sourceEntity should be avoided if there is any possibility that the PINX can cease to be an End PINX (e.g. through the use of certain supplementary services) prior to a response (e.g. a Reject APDU) being received. The Facility information element shall be delivered to Protocol Control. 7.1.2.2

Actions at a Receiving PINX A PINX receiving a Facility information element (in one of the messages listed in clause 10) shall determine whether or not it is the Destination PINX for that Facility information element. It shall accomplish this by determining whether the Protocol Profile (octet 3) has the value ‘Networking Extensions’ and if so, whether octet 3 is immediately followed by an NFE (as determined by the tag value). If the Facility information element does not contain an NFE, the PINX shall become the Destination PINX for that Facility information element. If the Facility information element contains an NFE, the PINX shall determine whether it is a Transit PINX or End PINX in the context of the Basic call and act as described below.

- 16 -

7.1.2.2.1

En d P I N X a c t io n s If the receiving PINX is an End PINX, and the encoding of the received NFE complies with the encoding and structure defined in clause 11, the following actions shall apply: –

if the destinationEntity element of the NFE indicates endPINX or anyTypeOfPINX and no destinationEntityAddress element is included, it shall become the Destination PINX for that Facility information element;

–

if the destinationEntity element of the NFE indicates anyTypeOfPINX and includes a destinationEntityAddress element, it shall compare the received address to its own address. If the addresses match, the PINX shall become the Destination PINX for that Facility information element;

–

if the destinationEntity element of the NFE indicates endPINX and erroneously includes a destinationEntityAddress element, the PINX shall become the Destination PINX for that Facility information element;

–

in all other cases, the received Facility information element shall be discarded.

If the received NFE does not conform to the encoding and structure defined in clause 11, the entire Facility information element shall be discarded. 7.1.2.2.2

Tr a n s it P I N X a c t io n s If the receiving PINX is a Transit PINX, and the encoding of the received NFE complies with the encoding and structure defined in clause 11, the following actions shall apply: –

if the destinationEntity element of the NFE indicates anyTypeOfPINX and a destinationEntityAddress element is included, it shall compare the received address to its own address. If the addresses match, the PINX shall become the Destination PINX for that Facility information element;

–

if the destinationEntity element of the NFE indicates anyTypeOfPINX and no destinationEntityAddress element is included, the PINX may become the Destination PINX for that Facility information element if it understands the contents;

–

if the destinationEntity element of the NFE indicates endPINX and erroneously includes a destinationEntityAddress element, the PINX shall ignore the contents of the destinationEntityAddress field and treat the contents of the Facility information element as if only the destinationEntity element was present;

–

if the destinationEntity element of the NFE indicates endPINX, and the Transit PINX is capable of acting as an End PINX for all services indicated in the Facility information element, it may become the Destination PINX for that Facility information element;

NOTE 1 In this case, the source of the information will have no knowledge that the information has been intercepted, as the Transit PINX will act as if it were an End PINX. This may occur, for example, when a PINX at a PISN numbering domain boundary wishes to translate numbering information contained within an APDU. –

in all cases where the PINX does not become the Destination PINX, the Facility information element shall be passed on unchanged to the Next PINX.

If the received NFE does not conform to the encoding and structure defined in clause 11, the entire Facility information element shall be discarded and no Facility information element shall be passed on to the Next PINX. NOTE 2 Processing of a Facility information element at a Transit PINX does not preclude another Facility information element, which may have similar contents to that received by the Transit PINX, being sent to the Next PINX as a result of that internal processing.

- 17 -

7.1.2.3

A c t io n s a t a D e s t in a t io n P I N X All APDUs in the received Facility information element shall be delivered to the Coordination Function at a Destination PINX in the order in which they were received in the Facility information element together with an indication of the protocol profile. If the Protocol Profile (octet 3) in the received Facility information element does not indicate ‘Networking Extensions’, the indication of the protocol profile to the Coordination Function shall reflect the contents of the Protocol Profile. If the Protocol profile (octet 3) in the received Facility information element indicates ‘Networking Extensions’, and a Network Protocol Profile (as determined by the tag value) is present in the received Facility information element immediately following the NFE, if present, or immediately following octet 3, the indication of protocol profile to the Coordination Function shall reflect the contents of the Network Protocol Profile. If the Protocol profile (octet 3) in the received Facility information element indicates ‘Networking Extensions’, and a Network Protocol Profile is not present in the received Facility information element, the indication of protocol profile to the Coordination Function shall be the default (ROSE). The Facility information element shall be discarded under any of the following circumstances: – the Network Protocol Profile is present but incorrectly coded; – subsequent octets do not comprise one or more concatenated APDUs, each in the form of an encoded ASN.1 value (comprising tag, length and contents).

7.1.2.4

D y n a m ic d e s c r ip t io n ( S D L) o f G e n e r ic F u n c t io n a l Tr a n s p o r t C o n t r o l Figures 4 to 7 show SDL diagrams describing the actions of the GFT-Control entity, as specified in 7.1.2. Figure 3 is the key to these SDL diagrams.

Primitive received from Coordination Function

Primitive from Protocol Control indicating FIE received

Primitive to Protocol Control to initiate FIE transfer

Primitive sent to Coordination Function

Start of Macro

Decision symbol

Exit from Macro

State symbol

Calling a Macro

Task symbol

F ig u r e 3 - K e y t o S D L d ia g r a m s in f ig u r e s 4 , 5 , 6 a n d 7

- 18 -

idle-state

GF-Data Request

is APDU response to previous FIE ?

YES

is information to be sent to adjacent PINX ?

YES

NO set NFE destination appropriately

set NFE destination to received source

do not include NFE in PC-Data request NOTE

is this PINX a Transit PINX?

YES set NFE origination to 'Any' and include address

set NFE origination to 'End' and don't include address

PC-Data request

idle-state

NOTE In principle, including the NFE to explicitly identify the Adjacent PINX is not precluded by the procedures in this Standard. Figure 4 - Actions at a Source PINX (sheet 1 of 2)

- 19 -

set NFE destination appropriately

is a specific destination required ?

YES

Specific PINX required ?

END PINX

EXPLICITLY ADDRESSED PINX

set NFE destination = anyPINX with no address

set NFE destination = anyPINX with PINX address

set NFE destination = endPINX with no address

Figure 5 - Actions at a Source PINX (sheet 2 of 2)

- 20 -

idle-state

NOTE 1 PC-Data indication

PASS ON

determine destination

PROCESS

DISCARD NOTE 2 PC-Data request

discard entire received FIE

GF-Data indication

idle-state

NOTE 1 This primitive indicates that Protocol Control has received a Facility information element from an Adjacent PINX. NOTE 2 This primitive to the Protocol Control entity causes a Facility information element to be sent to the Next PINX in the direction of the Destination PINX.

Figure 6 - Actions at a Receiving PINX (sheet 1 of 2)

- 21 -

determine destination

is NFE included in FIE ?

YES YES

more than one NFE ?

discard all NFEs except first

is NFE structure correct ?

YES

entity of receiving Pinx ?

TRANSIT

NFE destination =?

ANY PINX

END

OTHER

END

OTHER

NFE destination =?

END

ANY PINX

D destination address included ?

YES

does destination address match ? YES

does PINX understand and wish to be destination ?

does PINX wish to intercept ?

YES

destination address included ?

YES

does destination address match ?

YES

Pass it on

YES

Process

Figure 7 - Actions at a Receiving PINX (sheet 2 of 2)

Discard

- 22 -

7.2

Connectionless APDU Transport Mechanism The procedures defined in this clause describe a Connectionless network layer service which provides APDU transfer between PINXs outside the context of a call.

7.2.1 Protocol Control requirements 7.2.1.1 Requirements for sending a Connectionless message When requested by GFT-Control to send APDUs using Connectionless transport, Protocol Control shall first ensure that an SCM connection exists on the relevant inter-PINX link. If an SCM connection does not exist, Protocol Control shall establish an SCM connection according to the procedures described in 9.1.1 of ECMA-143. Once this Data Link is established, Protocol Control shall transfer the APDUs (encoded in a Facility information element) across the interface by sending a FACILITY message (defined in 10.7) containing the Dummy call reference (defined in 11.2), and the Calling and Called party number information elements as provided by GFT-Control. NOTE In the case where the FACILITY message is sent to a PINX which does not support Connectionless APDU transport, the FACILITY message will be discarded by that PINX in accordance with 9.2.3 of ECMA-143. 7.2.1.2

Requirements for receiving a Connectionless message On receipt of a valid FACILITY message containing the Dummy call reference the Facility information element shall be passed to GFT-Control. If a FACILITY message containing the Dummy call reference contains any of the following errors, it shall be discarded: – unrecognised information element which is encoded ‘comprehension required’; – missing mandatory information element; or, – mandatory information element content error. If a FACILITY message containing the Dummy call reference contains any unrecognised information elements that are not encoded "comprehension required"; or optional information elements with invalid contents, these information elements shall be discarded and the remainder of the FACILITY message processed as valid. On receipt of any messages containing the dummy call reference, other than the FACILITY message, the message shall be discarded.

7.2.2 Control requirements 7.2.2.1 Actions at a Source PINX On receipt of a request from the Coordination Function to send APDUs using Connectionless transport, accompanied by the address of the Destination PINX, GFT-Control shall: – if a route to the destination can be selected, select the appropriate inter-PINX link based on the destination address given in the request from the Coordination Function and inform Protocol Control to send a FACILITY message which shall contain: • a Calling party number information element, identifying the address of the Source PINX; • a Called party number information element identifying the address of the Destination PINX; and, • a Facility information element which shall not contain an NFE. – if no route to the Destination PINX can be selected, ignore the request. 7.2.2.2

Actions at a Receiving PINX If a PINX receives a FACILITY message containing the Dummy call reference on an inter-PINX link from an Adjacent PINX, it shall examine the contents of the Called party number information element to determine whether or not the FACILITY message is to be terminated at that PINX. If the Called party number identifies another PINX, and the receiving PINX can route the FACILITY message

- 23 -

based on this Called party number, the FACILITY message (with contents as received) shall be sent on the appropriate inter-PINX link. If the Called party number information element contains an address identifying the receiving PINX, it shall act as the Destination PINX for the FACILITY message. If a received FACILITY message containing the Dummy call reference contains a Called Party number information element that does not identify the receiving PINX or a PINX to which the FACILITY message can be passed on, the PINX shall discard the FACILITY message. NOTE It is the responsibility of the appropriate specification for the supplementary service utilising these transport procedures to ensure that the service can cope gracefully if the FACILITY message is discarded during routing. 7.2.2.3

A c t io n s a t a D e s t in a t io n P I N X If the received FACILITY message is destined for the receiving PINX, the contents of the Facility information element and the address of the Source PINX shall be passed to the appropriate SS-Control entity via the Coordination Function. NOTE It is the responsibility of SS-Control (i.e. the specific supplementary service) in the Destination PINX to store the Calling party number information element to enable response to the service request to be made using a further Connectionless message. If the received Facility information element contains an NFE, the receiving PINX shall ignore the contents of that NFE.

7.3

Connection oriented call independent APDU transport mechanism The procedures in this clause describe a Connection oriented network layer service which provides APDU transfer between PINXs outside the context of a call.

7.3.1

7.3.1.1

Protocol Control requirements The description of the Protocol Control requirements for Connection oriented APDU transport uses a subset of the states defined in 7.1 of ECMA-143. A c t io n s in t h e N u ll s t a t e When asked to initiate a Call independent signalling connection by GFT-Control, the Outgoing side Protocol Control shall: – ensure that an SCM connection exists on the relevant inter-PINX link. If an SCM connection does not exist, Protocol Control shall establish an SCM connection according to the procedures described in 9.1.1 of ECMA-143; – send a SETUP message on the appropriate inter-PINX link which shall contain only: • a Call reference, selected according to 14.3 of ECMA-143; • a Bearer capability information element indicating the additional codepoints defined in 11.3.1, i.e. Coding standard indicating ‘other international standard’, Information transfer capability indicating ‘unrestricted digital information’, Transfer mode indicating ‘circuit mode’, and Information transfer rate indicating ‘Call independent signalling connection’; • a Channel identification information element indicating ‘no-channel’ in the channel selection field, 'channel indicated is the signalling channel' in the signalling channel indication field and ‘exclusive’ in the preferred/exclusive field, as defined in 11.3.2; • a Called party number information element containing a number at least sufficient to identify the Terminating PINX; • optionally, a Sending complete information element, as defined in 14.5 of ECMA-143; • optionally, a Calling party number information element containing a number at least sufficient to identify the Originating PINX; and,

- 24 -

• optionally, one or more Facility information elements; and, – start timer T303; and, – enter the Call initiated state. On receipt of a SETUP message relating to establishment of a Call independent signalling connection, the Incoming side shall: – if the request is valid and can be processed, return a CALL PROCEEDING message to the Outgoing side, indicate the connection request to GFT-Control and enter the Incoming call proceeding state; or, – if the request is invalid or cannot be accepted by the PINX, return a RELEASE COMPLETE message to the Outgoing side, release the call reference and remain in the Null state. 7.3.1.2

A c t io n s in t h e C a ll in it ia t e d s t a t e On receipt of a CALL PROCEEDING message from the Incoming side, the Outgoing side shall stop T303, start timer T310, if applicable, and enter the Outgoing call proceeding state. If no response is received from the Incoming side before timer T303 expires, the SETUP message may optionally be retransmitted and timer T303 restarted. If no response is received before timer T303 expires for a second time (or for the first time if the SETUP message is not to be retransmitted), the Outgoing side shall send a RELEASE COMPLETE message to the Incoming side; inform GFTControl of the failure of the signalling connection request; and enter the Null state. NOTE 1 The RELEASE COMPLETE message should contain cause no. 102 “Recovery on Timer Expiry”. NOTE 2 If the Connection oriented procedures are not supported by a PINX which receives a SETUP message requesting a Call independent signalling connection, it will respond with a call clearing message indicating, for example, that the Bearer capability cannot be provided or that the message has contained an information element content error. This will initiate connection release in accordance with 7.3.1.7.

7.3.1.3

Actions in the Incoming call proceeding state When receiving an indication that the Call independent signalling connection is established from GFT-Control, the Incoming side shall: send a CONNECT message to the Outgoing side and either: enter the Active state, or start timer T313 and enter the Connect request state.

7.3.1.4

Actions in the Outgoing call proceeding state On receipt of a CONNECT message from the Incoming side, the Outgoing side shall: stop timer T310 (if applicable), inform GFT-Control that the signalling connection is established, send a CONNECT ACKNOWLEDGE message to the Incoming side and enter the Active state. If timer T310 expires, the Outgoing side shall indicate that the signalling connection request has failed to GFT-Control and initiate release of the connection as described in 7.3.1.7. NOTE The cause sent to the Incoming side should be no. 102 “Recovery on Timer Expiry”.

7.3.1.5

A c t io n s in t h e C o n n e c t r e q u e s t s t a t e On receipt of a CONNECT ACKNOWLEDGE message, the Incoming side shall: stop timer T313 and enter the Active state. If timer T313 expires before a CONNECT ACKNOWLEDGE message is received the Incoming side shall: indicate failure of connection establishment to GFT-Control and initiate release of the connection as described in 7.3.1.7. NOTE The cause sent to the Outgoing side should be no. 102 “Recovery on Timer Expiry”.

- 25 -

7.3.1.6

A c t io n s in t h e A c t iv e s t a t e On receipt of a FACILITY message from a peer Protocol Control entity, an indication shall be given to GFT-Control. On receipt of a request to send supplementary services related information by GFT-Control, Protocol Control shall send a FACILITY message to the peer Protocol Control entity. A received CONNECT ACKNOWLEDGE message shall be ignored.

7.3.1.7

C o n n e c t io n r e le a s e When Protocol Control is requested by GFT-Control to release a Call independent signalling connection, Protocol Control shall: – if in the Release request state, ignore the request from GFT-Control; or – if in any other Protocol Control state, send a RELEASE message with an appropriate cause value, start timer T308 and enter the Release request state. When Protocol Control makes a local decision to release a Call independent signalling connection (e.g. due to a protocol error), it shall, if not in the Release request state: inform GFT-Control that the signalling connection has been released, send a RELEASE message with an appropriate cause value, start timer T308 and enter the Release request state. On receipt of a RELEASE message in any state other than the Release request state, Protocol Control shall indicate to GFT-Control that the signalling connection has been released, send a RELEASE COMPLETE message, release the call reference and enter the Null state. On receipt of a RELEASE COMPLETE message in any state other than the Release request state, Protocol Control shall indicate to GFT-Control that the signalling connection has been released, release the call reference and enter the Null state.

7.3.1.8

A c t io n s in t h e R e le a s e r e q u e s t s t a t e On receipt of a RELEASE or a RELEASE COMPLETE message, Protocol Control shall: stop timer T308, release the call reference and enter the Null state. If timer T308 expires for the first time, the RELEASE message shall be retransmitted and timer T308 shall be restarted. If timer T308 expires a second time, Protocol Control shall release the call reference and enter the Null state.

7.3.1.9

Transport of APDUs associated with a Call independent signalling connection When requested by GFT-Control, the Facility information element may be sent in a call establishment or a call clearing message (see clause 10) of the connection oriented, call independent signalling connection or in a FACILITY message during Active state of the connection oriented, call independent signalling connection.

7.3.1.10

Protocol error handling Sub-clause 9.2 of ECMA-143 shall apply with the following modifications: – actions regarding the handling of B-channels are not applicable; – actions regarding the handling of the DISCONNECT message (not defined for use with Call independent connections) are not applicable; – on SCM failure, for connections in the Active state, Protocol Control may release all resources, release the call reference, enter the Null state and inform GFT-Control of the failure of the connection, as an alternative to the procedures specified for active connections in 9.2.9 of ECMA-143; – if a SETUP ACKNOWLEDGE, ALERTING, INFORMATION, DISCONNECT or PROGRESS message (defined in ECMA-143) is received in any state (except the Null state, where invalid call reference error procedures apply) it shall be treated as an unexpected or unrecognised message in accordance with 9.2.4 of ECMA-143. Sub-clause 9.3 of ECMA-143 shall apply for the generation and request of Call independent connection state information.

- 26 -

7.3.1.11

Procedures for layer management Clause 11 of ECMA-143 shall apply. In the case that the Restart indicator information element indicates restart of a single channel, call independent signalling connections shall not be affected. In the case that the Restart indicator information element indicates ‘all channels’, Protocol Control shall return all call independent signalling connections to the idle state and inform GFT-Control.

7.3.1.12

Protocol timer values Table 11 defines the values and attributes of the protocol timers required for Connection oriented Protocol Control. In table 11, the following conventions are used to indicate the applicability of the protocol timers to an incoming or outgoing side Protocol Control entity in a PINX: M:

The support of the timer is Mandatory

The support of the timer is Optional

M(I):

The support of the timer is Mandatory if the associated (optional) procedures are implemented.

All timer values given in table 11 shall have a tolerance of 10%. Where minimum and maximum values are given, the choice of value is an implementation matter, within the range specified, with a tolerance of 10% below the minimum value and 10% above the maximum value.

- 27 -

Table 11 - Protocol Control timer values Timer Number T303

Timer Value Call State Cause for start

Normally terminated

Minimum 4 s,

On receipt of CALL Retransmit PROCEEDING or SETUP and RELEASE COMPLETE restart T303 or release the connection as specified in 7.3.1.7

Maximum 6 s

Second T303

Minimum 4 s,

T308

Minimum 4 s,

Maximum 6 s

Call initiated

Retransmit RELEASE, restart T308.

Release request

On expiry of T308

On receiving RELEASE or RELEASE COMPLETE

Release call reference

SCM disconnection. Connections in Stable states are not lost.

On SCM reestablishment

Release connection and call reference

On receipt of CONNECT or RELEASE

Release connection as specified in 7.3.1.7

M (Optional for a Transit PINX)

On receipt of CONNECT ACKNOWLEDGE

Release connection as specified in 7.3.1.7

M (I)

90 s

Any state

T310

Implementation dependent

Outgoing call proceeding

Minimum 4 s,

Connect request

T322

Minimum 4 s,

On receiving RELEASE or RELEASE COMPLETE

T309

Maximum 6 s

Release connection as specified in 7.3.1.7

On sending RELEASE

Minimum 4 s,

T313

On On receipt of CALL retransmission of PROCEEDING or SETUP RELEASE COMPLETE

Release request

Second T308

Maximum 6 s

On Sending SETUP

Action to be Incoming Outgoing taken when side side timer expires

On receipt of CALL PROCEEDING On sending CONNECT

Any STATUS STATUS, RELEASE or STATUS connection ENQUIRY sent RELEASE COMPLETE ENQUIRY may Maximum 6 s state except received. be retransmitted Null several times implementation dependant

- 28 -

7.3.2

Dynamic Description (SDL) of Connection oriented Protocol Control procedures Figures 9 contains a dynamic description of the Connection oriented Protocol Control procedures in 7.3.1. It is based on the SDL description of the Basic call, defined in annex E of ECMA-143 and is not intended to be complete. It is to be used as an aid to the interpretation of the text, which shall be the prime source should a conflict occur. Figure 8 shows the key to the symbols used in figure 9. Table 12 describes the naming convention used for primitives shown in the SDL diagram. Table 12 - Key to primitive names used in figure 9 Prefix

Primitive from/to:

Event_

An entity which provides Protocol Control with notification of protocol related events other than receipt of incoming messages or primitives from GFT-Control or the SCM.

PC_

Primitives from / to GFT-Control to / from Protocol Control

DL_

Primitives from / to the SCM to / from Protocol Control

Incoming Message

Incoming Primitive

Outgoing Primitive

Outgoing Message

Protocol state 'n'

Decision symbol

Task symbol

Option symbol

F ig u r e 8 - K e y t o s y m b o ls u s e d in t h e S D L d ia g r a m f o r C o n n e c t io n o r ie n t e d P r o t o c o l C o n t r o l

- 29 -

0 - Null

PC_Setup request

RELEASE COMPLETE

Allocate Call Reference

0 - Null

SETUP

Start timer T303

SETUP

Mandatory IE missing or invalid content ?

YES

Call Reference flag = 1

YES

NO 1 - Call Initiated

Save Call Reference

Valid Information ?

0 - Null

YES CALL PROCEEDING

PC_Setup Indication

9 - Incoming Call Proceeding

RELEASE COMPLETE

Release Call Reference

0 - Null

F ig u r e 9 - C o n n e c t io n o r ie n t e d P r o t o c o l C o n t r o l S D L ( S h e e t 1 o f 1 0 )

- 30 A

DL_Release indication

STATUS

STATUS ENQUIRY

0 - Null

Call State Indicated ?

State

RELEASE

Unexpected or Unrecognised Message

RELEASE COMPLETE

0 - Null

State = 0

RELEASE COMPLETE

0 - Null

STATUS (#30)

0 - Null

RELEASE COMPLETE

0 - Null

F ig u r e 9 - C o n n e c t io n o r ie n t e d P r o t o c o l C o n t r o l S D L ( S h e e t 2 o f 1 0 )

- 31 -

1 - Call Initiated

PC_Release request

Stop T303

RELEASE

CALL PROCEEDING

RELEASE COMPLETE

Event_Expiry T303

Stop T303

Final Expiry ?

Start T303 (if applicable)

PC_Reject Indication

YES

PC_Release Indication

SETUP Release Call Reference

Start T308

Restart T303

RELEASE COMPLETE

Release Call Reference

19 - Release Request

3 - Outgoing Call Proceeding

0 - Null

1 - Call Initiated

0 - Null

F ig u r e 9 - C o n n e c t io n o r ie n t e d P r o t o c o l C o n t r o l S D L ( S h e e t 3 o f 1 0 )

3 - Outgoing Call Proceeding

PC_Release request

Stop T310

RELEASE

CONNECT

Stop T310

PC_Setup Confirmation

Event_Expiry T310

RELEASE

PC_Release Indication

Start T308

CONNECT ACKNOWLEDGE

Start T308

19 - Release Request

10 - Active

19 - Release Request

F ig u r e 9 - C o n n e c t io n o r ie n t e d P r o t o c o l C o n t r o l S D L ( S h e e t 4 o f 1 0 )

- 32 -

8 - Connect Request

Event_Expiry T313

CONNECT ACK

RELEASE

PC_Release request

Stop T313

Start T308

RELEASE

19 - Release Request

PC_Release Indication

10 - Active

Start T308

19 - Release Request

F ig u r e 9 - C o n n e c t io n o r ie n t e d P r o t o c o l C o n t r o l S D L ( S h e e t 5 o f 1 0 )

10 - Active

FACILITY

CONNECT ACK

PC_Data Indication

10 - Active

PC_Data request

FACILITY

10 - Active

PC_Release request

RELEASE

Start T308

19 - Release Request

F ig u r e 9 - C o n n e c t io n o r ie n t e d P r o t o c o l C o n t r o l S D L ( S h e e t 6 o f 1 0 )

- 33 -

9 - Incoming Call Proceeding

PC_Setup response

PC_Release request

CONNECT

RELEASE

Start T308

Start T313

8 - Connect Request

10 - Active

19 - Release Request

F ig u r e 9 - C o n n e c t io n o r ie n t e d P r o t o c o l C o n t r o l S D L ( S h e e t 7 o f 1 0 )

19 - Release Request

RELEASE

RELEASE COMPLETE

Stop T308

Release Call Reference

STATUS (state null)

19 - Release Request

Event_Expiry T308

First Expiry of T308?

YES

RELEASE 0 - Null Restart T308

Release Call Reference

19 - Release Request

0 - Null

F ig u r e 9 - C o n n e c t io n o r ie n t e d P r o t o c o l C o n t r o l S D L ( S h e e t 8 o f 1 0 )

- 34 -

Any state excluding 0, 1, 19

Any state excluding 0, 19

RELEASE COMPLETE

RELEASE

Stop all related timers

PC_Release Indication

Release Call Reference

RELEASE COMPLETE

Release Call Reference

0 - Null

F ig u r e 9 - C o n n e c t io n o r ie n t e d P r o t o c o l C o n t r o l S D L ( S h e e t 9 o f 1 0 )

Any State (except Null)

Unexpected Message (except REL or REL COM)

SETUP (CR relates to active call)

Unrecognised Message

Remain in current state

STATUS ENQUIRY

STATUS

STATUS ENQUIRY

STATUS

Remain in current state

F ig u r e 9 - C o n n e c t io n o r ie n t e d P r o t o c o l C o n t r o l S D L ( S h e e t 1 0 o f 1 0 ) 7.3.3

Generic Functional Transport Control requirements The procedures describing the requirements of the GFT-Control entity for Call independent signalling connection control are defined in terms of a number of states. These states are conceptual states that are used to enable straightforward description of the dynamic aspects of the GFT-Control procedures.

- 35 -

The states used are separated into states that exist at an Originating PINX, a Transit PINX and a Terminating PINX. A brief description of the states is as follows: – Originating PINX GFT-Control States: • Originating_connection_idle:

no connection exists.

• Originating_connection_request:

connection establishment has been requested, but no response has been received from the Terminating PINX.

• Originating_connection_active:

the connection is active.

– Transit PINX GFT-Control States: • Transit_connection_idle:

no connection exists.

• Transit_connection_request:

connection establishment request has been received from the Preceding PINX and forwarded to the Subsequent PINX, but no response has been received from the Subsequent PINX.

• Transit_connection_active:

the connection is active.

– Terminating PINX GFT-Control States: • Incoming_connection_idle:

no connection exists.

• Incoming_connection_active:

the connection is active.

7.3.3.1 A c t io n s a t a n O r ig in a t in g P I N X 7 . 3 . 3 . 1 . 1 A c t io n s in t h e O r ig in a t in g _ c o n n e c t io n _ id le s t a t e When a request for establishment of a Call independent signalling connection to a remote PINX is received from the Coordination Function, GFT-Control shall: request the Outgoing side Protocol Control to send a SETUP message, including the address of the Terminating PINX and enter the Originating_connection_request state. 7.3.3.1.2

A c t io n s in t h e O r ig in a t in g _ c o n n e c t io n _ r e q u e s t s t a t e If Protocol Control informs GFT-Control that a RELEASE or RELEASE COMPLETE message has been received, GFT-Control shall inform the Coordination Function that the connection has failed and enter the Originating_connection_idle state. If Protocol Control informs GFT-Control that a CONNECT message has been received, GFTControl shall enter the Originating_connection_active state.

7.3.3.1.3

A c t io n s in t h e O r ig in a t in g _ c o n n e c t io n _ a c t iv e s t a t e If a request for transfer of APDUs on the connection is received from the Coordination Function, GFT-Control shall instruct Protocol Control to send a FACILITY message to the Subsequent PINX, containing a Facility information element in accordance with 7.3.3.4. If Protocol Control informs GFT-Control that a FACILITY message has been received, the PINX shall become the Destination PINX for the received Facility information element in accordance with 7.3.3.5. If Protocol Control informs GFT-Control that a RELEASE message has been received, GFTControl shall inform the Coordination Function that the connection has been released and enter the Originating_connection_idle state. If a request that the connection be released is received from the Coordination Function, GFTControl shall: request that Protocol Control send a RELEASE message and enter the Originating_connection_idle state.

7.3.3.2

A c t io n s a t a Tr a n s it P I N X If GFT-Control receives indication from Protocol Control of a received SETUP message from the Preceding PINX, it shall examine the contents of the Called party number information element. If the

- 36 -

Called party number information element matches that of the Receiving PINX, the PINX shall become a Terminating PINX, otherwise it shall follow the procedures of this clause. If GFT-Control receives any APDUs from Protocol Control in any of the messages which may contain a Facility information element (see clause 10), it shall examine the header of the Facility information element for the presence of an NFE. The treatment of the Facility information element based on this NFE shall be as defined in clause 7.1.2.2. 7.3.3.2.1

A c t io n s in t h e Tr a n s it _ c o n n e c t io n _ id le s t a t e If the Called party number contained in the SETUP message is that of another PINX and a connection to that PINX is possible, GFT-Control shall: request Protocol Control to send a SETUP message on the appropriate inter-PINX link to the Subsequent PINX, associate the incoming and outgoing connections and enter the Transit_connection_request state. If the contents of the Called party number information element contained in the SETUP message is not sufficient to enable routing onto a further inter-PINX link, GFT-Control shall: request Protocol Control to release the connection by sending a RELEASE message to the Preceding PINX and remain in the Transit_connection_idle state.

7.3.3.2.2

A c t io n s in t h e Tr a n s it _ c o n n e c t io n _ r e q u e s t s t a t e When Protocol Control informs GFT-Control of a CONNECT message received from the Subsequent PINX, GFT-Control shall: request Protocol Control to send a CONNECT message to the Preceding PINX and enter the Transit_connection_active state. When Protocol Control informs GFT-Control that a RELEASE or RELEASE COMPLETE message has been received from the Subsequent PINX, GFT-Control shall: request Protocol Control to send a RELEASE message to the Preceding PINX and enter the Transit_connection_idle state. When Protocol Control informs GFT-Control that a RELEASE message has been received from the Preceding PINX, GFT-Control shall: request Protocol Control to send a RELEASE message to the Subsequent PINX and enter the Transit_connection_idle state.

7.3.3.2.3

A c t io n s in t h e Tr a n s it _ c o n n e c t io n _ a c t iv e s t a t e If Protocol Control informs GFT-Control of the receipt of a FACILITY message from the Subsequent PINX, and if it contains a Facility information element that is to be passed on to the Preceding PINX (in accordance with 7.1.2.2), GFT-Control shall request Protocol Control to send a FACILITY message containing that Facility information element to the Preceding PINX. If Protocol Control informs GFT-Control of the receipt of a FACILITY message from the Preceding PINX, and it contains a Facility information element that is to be passed on to the Subsequent PINX (in accordance with 7.1.2.2), GFT–Control shall request Protocol Control to send a FACILITY message containing that Facility information element to the Subsequent PINX. If Protocol Control informs GFT-Control of the receipt of a RELEASE message from the Subsequent PINX, GFT-Control shall request Protocol Control to send a RELEASE message to the Preceding PINX and shall enter the Transit_connection_idle state. If Protocol Control informs GFT-Control of the receipt of a RELEASE message from the Preceding PINX, GFT-Control shall request Protocol Control to send a RELEASE message to the Subsequent PINX and shall enter the Transit_connection_idle state.

7.3.3.3

7.3.3.3.1

Actions at a Terminating PINX If GFT-Control receives any APDUs from Protocol Control in any of the messages which may contain a Facility information element (see clause 10), it shall examine the header of the Facility information element for the presence of an NFE. The treatment of the Facility information element based on this NFE shall be as defined in clause 7.1.2.2. A c t io n s in t h e I n c o m in g _ c o n n e c t io n _ id le s t a t e If Protocol Control notifies GFT-Control of a received SETUP message that is to be terminated on the receiving PINX, and resources for the connection are available, GFT-Control shall request Protocol Control to send a CONNECT message and enter the Incoming_connection_active state.

- 37 -

NOTE 1 Before sending the CONNECT message GFT-Control should determine from the coordination function if any APDUs are to be included in the CONNECT message. If no resources for the connection are available, GFT-Control shall: request Protocol Control to send a RELEASE message; and remain in the Incoming_connection_idle state. NOTE 2 The RELEASE message is used in this case as Protocol Control has already returned a CALL PROCEEDING message to the Preceding PINX. 7.3.3.3.2

A c t io n s in t h e I n c o m in g _ c o n n e c t io n _ a c t iv e s t a t e If the Coordination Function requests transfer of APDUs on the connection, GFT-Control shall instruct Protocol Control to send a FACILITY message to the Preceding PINX containing a Facility information element in accordance with 7.3.3.4. If Protocol Control informs GFT-Control that a FACILITY message has been received from the Preceding PINX, GFT-Control shall remain in the same state. If Protocol Control informs GFT-Control that a RELEASE message has been received from the Preceding PINX, it shall inform the Coordination Function that the connection has been released and enter the Incoming_connection_idle state. If the Coordination Function requests that the connection be released, GFT-Control shall: request that Protocol Control send a RELEASE message; and enter the Incoming_connection_idle state.

7.3.3.4

Actions at a Source PINX The actions defined in 7.1.2.1 shall apply.

7.3.3.5

A c t io n s a t a D e s t in a t io n P I N X The actions defined in 7.1.2.3 shall apply.

7.4

Call related procedures for the transport of Notifications This clause defines the functional signalling procedures that support the delivery of notifications over the PISN in association with a Basic call.

7.4.1

C a t e g o r ie s o f n o t if ic a t io n s Procedures are defined for the delivery of three types of notification information as follows: – the delivery of simple notification indicators based on the Notification Indicator information element as described in 11.3.4; – the delivery of notification ‘parameters’ that are specified as information elements using the encoding scheme defined in clause 14 of ECMA-143 within the pss1IeNotification Notification defined in annex B; – the delivery of notification components using an extension codepoint in octet 3 of the Notification indicator information element and ASN.1 encoded data structure in subsequent octets.

7.4.2 Protocol Control requirements 7.4.2.1 S e n d in g n o t if ic a t io n in f o r m a t io n The transport of notifications shall make use of the call reference of a Basic call and its underlying SCM connection. Notifications shall be sent using the Notification indicator information element. If the delivery of the notification information coincides with the sending of the FACILITY message or any of the Basic call messages listed in clause 10 in which the Notification indicator information element is permitted, the notification may be carried in that message. Otherwise, the notification shall be delivered in a NOTIFY message. However: – if a SETUP message has been sent, but no response has been received from the Next PINX (i.e. the B-channel has not yet been agreed on the Outgoing side of the PINX);

- 38 -

– if a SETUP message has been received from the Preceding PINX, but no response has been sent (i.e. the B-channel has not yet been agreed on the Incoming side of the PINX); or, – if a clearing message has already been sent to or received from the Next PINX the notification information shall be discarded. No state change shall occur on sending a NOTIFY message. NOTE In the case where the Notification indicator information element is sent to a PINX which does not conform to this Standard, the Notification indicator information element will be discarded by that PINX and a STATUS message (see 13 in ECMA-143) can be received. The STATUS message will indicate that either: the Notification indicator information element was unrecognised; or, that the message (NOTIFY or FACILITY) was unrecognised. In such cases, no further action should be taken. 7.4.2.2

R e c e i v i n g n o t if i c a t i o n i n f o r m a t i o n On receipt of a Notification indicator information element, in the NOTIFY message or in any of the other messages listed in clause 10 in which the Notification indicator information element is permitted, it shall be passed to GFT-Control. No state change shall occur on receipt of a NOTIFY message.

7.4.3 GFT-Control requirements 7.4.3.1 A c t io n s a t a P I N X wh ic h g e n e r a t e s n o t if ic a t io n s A PINX which wishes to generate a notification shall request Protocol Control to send a Notification indicator information element. 7.4.3.2

A c t io n s a t a Tr a n s it P I N X If a Transit PINX receives a Notification indicator information element from the Preceding PINX, it shall request Protocol Control to send the Notification indicator information element to the Subsequent PINX. If a Transit PINX receives a Notification indicator information element from the Subsequent PINX, it shall request Protocol Control to send the Notification indicator information element to the Preceding PINX.

7.4.3.3

Actions at a Receiving End PINX If an End PINX receives a Notification indicator information element, at any time during a Call, it shall convey the information it contains to the PISN user - dependent on the ability of the PISN user’s equipment to receive such information. NOTE Further (implementation specific) actions of a PINX receiving a notification (e.g. changing the state of a local non-Standard state machine) are not precluded and are beyond the scope of this Standard.

Application layer requirements

8.1

Coordination Function requirements The behaviour of the Coordination Function in passing information between the various SS-Control entities, ROSE, DSE, ACSE, Call Control and GFT-Control is beyond the scope of this Standard, with the exception of the provisions in 8.1.1 and 8.1.2 relating to the handling of the Interpretation APDU, the routeing of APDUs received from GFT-Control and error handling at a Destination PINX.

8.1.1

Inclusion of an Interpretation APDU at a Source PINX If a Source PINX wishes to include additional information to facilitate handling of unrecognised ROSE APDUs of type InvokePDU (see 11.3.3.4) at a Destination PINX, it shall include an Interpretation APDU (see 11.3.3.2) as the first APDU in the sequence of APDUs sent to GFT-Control.

- 39 -

NOTE Where two or more ROSE APDUs of type InvokePDU are to be sent simultaneously and the unrecognised InvokePDU handling requirements of each differs, the ROSE APDUs should be grouped in multiple Facility information elements, each with its own Interpretation APDU. 8.1.2

H a n d lin g o f A P D U s a t a D e s t in a t io n P I N X The Coordination function shall process the APDUs received from GFT-Control based on the indication of protocol profile from GFT-Control: – if the indication of protocol profile has the value ‘ROSE’, the Coordination Function shall deliver the remainder of the APDUs to ROSE, excluding the first APDU, if, according to its tag value, it is an Interpretation APDU; – if the indication of protocol profile has the value ‘ACSE’, and ACSE is supported, the Coordination Function shall deliver the APDUs to ACSE, excluding the first APDU, if, according to its tag value, it is an Interpretation APDU; – if the indication of protocol profile has the value ‘DSE’, and DSE is supported, the Coordination Function shall deliver the APDUs to DSE, excluding the first APDU, if, according to its tag value, it is an Interpretation APDU; – in all other cases, the Coordination Function shall discard all the APDUs received from GFT-Control. If the first APDU is an Interpretation APDU, the Coordination Function shall examine any ROSE APDU of type RejectPDU generated by ROSE as a result of the processing of these APDUs. If the element problem in the RejectPDU is of type InvokeProblem and has value unrecognisedOperation the action taken shall depend on the contents of the Interpretation APDU as follows: – If the Interpretation APDU indicates rejectUnrecognisedInvokePdu the ROSE APDU of type RejectPDU shall be delivered to the destination indicated by ROSE; – If the Interpretation APDU indicates clearCallIfAnyInvokePduNotRecognised the ROSE APDU of type RejectPDU shall be delivered to the destination indicated by ROSE, and Call Control shall be requested to clear the Basic call or Call independent signalling connection to which the InvokePDU was related; – If the Interpretation APDU indicates discardAnyUnrecognisedInvokePDU the ROSE APDU of type RejectPDU shall be discarded. If no Interpretation APDU is received, any ROSE APDUs of type RejectPDU shall be delivered to the destination indicated by ROSE.

8.2

ROSE requirements Service APDUs shall be formed according to ROSE as defined in X.880 and X.881. The procedures specified in section 7 of X.882 for sending and receiving ROSE APDUs shall apply, with the exception that sub-sections 7.1 to 7.3 do not apply and that the Transfer services used shall be those provided by GFT-Control or those provided by ACSE or DSE. As a minimum, a Destination PINX shall recognise received ROSE APDUs and reject those whose operation values are not supported. Additional requirements relating to the use of ROSE are supplementary service specific and are beyond the scope of this Standard.

8.3

ACSE requirements The ACSE may be used to create an explicit application-association between two supplementary services control entities. When used, the procedures specified in section 7 of X.227 for sending and receiving ACSE APDUs shall apply, with the exception that the underlying services used shall be those provided implicitly by GFT-Control or DSE, and not those provided by the presentation-service. As a minimum, a PINX which supports ACSE shall recognise received ACSE APDUs and reject those whose association context names are not recognised. Additional requirements relating to the use of ACSE are supplementary service specific and beyond the scope of this Standard.

- 40 -

8.4

DSE requirements The DSE may be used to create a dialogue between two PINXs, to enable service requests and responses to be correlated, particularly when they do not exist within the context of the same network layer connection. The DSE uses the underlying services provided by GFT-Control via the Coordination Function. The coding requirements for the DSE APDUs are defined in 11.3.3.3. Any DSE APDU, with the exception of a DialogAbortPDU, may contain one or more ROSE APDUs or one or more ACSE APDUs. A state machine shall be associated with each dialogue within a PINX. Four dialogue states are defined: – Idle: no dialogue exists; – Initiate sending: a DialogBeginPDU has been sent, a DialogContinuePDU is awaited from the peer PINX; – Initiate receiving: a DialogBeginPDU has been received, a request from the Coordination Function is awaited to continue or terminate the dialogue; – Active: the dialogue is established.

8.4.1 A c t io n s a t t h e P I N X wh ic h in it ia t e s t h e d ia lo g u e ( P I N X A ) 8.4.1.1 I d le s t a t e p r o c e d u r e s When a request from the Coordination Function to initiate a dialogue is received, PINX A shall: – send a DialogBeginPDU to the PINX identified in the request (PINX B). The element of type OriginationDialogId shall contain a dialogue identifier selected by PINX A that is sufficient to distinguish the dialogue from any others in which PINX A is involved. The DialogBeginPDU may also contain one or more ROSE APDUs or one or more ACSE APDUs relating to a particular supplementary service or services; – start timer T_Originating_Dialogue (T_OD); and, – enter the Initiate sending state. The selected dialogue identifier shall be included in the element of type OriginationDialogId in all further DialogContinuePDUs sent from PINX A to PINX B for the duration of the dialogue. 8.4.1.2

I n it ia t e s e n d in g s t a t e p r o c e d u r e s On receipt of a DialogContinuePDU, PINX A shall: – cancel timer T_Originating_Dialogue; – store the value of the element of type OriginationDialogID. This is the dialogue identifier selected by PINX B and shall be included in all DSE APDUs sent from PINX A to PINX B in the element of type DestinationDialogId for the duration of the dialogue; – provide an indication of dialogue continuation to the Coordination Function; and, – enter the Active state. On receipt of a DialogEndPDU, PINX A shall consider the dialogue to be terminated, release the locally assigned dialogue identifier, inform the Coordination Function, cancel timer T_Originating_Dialogue and enter the Idle state. On receipt of a DialogAbortPDU, PINX A shall consider the dialogue to be aborted, inform the Coordination Function, cancel timer T_Originating_Dialogue and enter the Idle state. If a request to abort the dialogue is received from the Coordination Function, PINX A shall cancel timer T_Originating_Dialogue, release the locally assigned dialogue identifier and enter the Idle state. If timer T_Originating_Dialogue expires, PINX A shall consider the dialogue to be aborted, inform the Coordination Function that the dialogue has been aborted, release the dialogue identifier assigned locally by PINX A and enter the Idle state.

- 41 -

8.4.2 Actions at the PINX which terminates the dialogue (PINX B) 8.4.2.1 I d le s t a t e p r o c e d u r e s On receipt of a DialogBeginPDU from PINX A, PINX B shall: – check that the value of the element of type OriginationDialogId in the DialogBeginPDU is valid. If it is not valid, PINX B shall discard the DialogBeginPDU and remain in the idle state; – save the value of the element of type OriginationDialogId in the DialogBeginPDU. This is the dialogue identifier selected by PINX A and shall be included in all DSE APDUs sent from PINX B to PINX A in the element of type DestinationDialogId for the duration of the dialogue; – inform the Coordination Function; and, – enter the Initiate receiving state. 8.4.2.2

Initiate receiving state procedures If PINX B wishes to continue the dialogue, it shall: – send a DialogContinuePDU to PINX A containing, in the element of type OriginationDialogId, a dialogue identifier selected by PINX B to be sufficient to distinguish the dialogue from any others in which PINX B is involved, and in the element of type DestinationDialogId the value received in the element of type OriginationDialogId in the DialogBeginPDU from PINX A; and, – enter the Active state. If PINX B cannot accept the dialogue, it shall send DialogAbortPDU to PINX A, release the stored dialogue identifier and enter the Idle state. If PINX B wishes to end the dialogue, it shall send DialogEndPDU to PINX A, release the stored dialogue identifier and enter the Idle state.

8.4.3

D ia lo g u e C o n t in u a t io n in t h e A c t iv e S t a t e If a PINX wishes to continue the dialogue, it shall: send a DialogContinuePDU to the peer PINX and remain in the active state. The DialogContinuePDU may also contain one or more ROSE APDUs or one or more ACSE APDUs. On receipt of a DialogContinuePDU, the PINX shall indicate dialogue continuation to the Coordination Function, together with any ROSE APDUs or ACSE APDUs contained in the received DialogContinuePDU. On receipt of a DialogEndPDU, the PINX shall consider the dialogue to be terminated, inform the Coordination Function, release the dialogue identifier assigned locally and the identifier received from the peer PINX, and enter the Idle state. On receipt of a DialogAbortPDU, the PINX shall consider the dialogue to be aborted, inform the Coordination Function, release the dialogue identifier assigned locally and the identifier received from the peer PINX, and enter the Idle state. If a request to terminate the dialogue is received from the Coordination Function, the PINX shall send a DialogEndPDU to the peer PINX, release the dialogue identifier assigned locally and the identifier received from the peer PINX, and enter the idle state. If a request to abort the dialogue is received from the Coordination Function, the PINX shall send a DialogAbortPDU to the peer PINX, release the dialogue identifier assigned locally and the identifier received from the peer PINX, and enter the idle state.

8.4.4

Dialogue Protocol Timers Table 13 defines the protocol timers for the Dialogue procedures.

- 42 -

Table 13 - Dialogue Protocol Timers Timer

State

Value

Normal Start

Normal Termination

Actions on expiry

T_OD

Initiate sending

Implementation dependent

On sending DialogBeginPDU

On receipt of a DialogContinuePDU, DialogEndPDU or DialogAbortPDU

Indicate to the Coordination Function that dialogue is aborted. Enter idle state.

8.4.5

Error procedures relating to dialogue control If a PINX receives any DSE APDUs relating to the same dialogue from the peer PINX that are incorrectly formatted they shall be discarded. If a PINX receives a DialogEndPDU or a DialogAbortPDU in the Idle state, the APDU shall be discarded and it shall remain in the Idle state. If a PINX receives a DialogContinuePDU in the Idle state, it shall send a DialogAbortPDU containing an element of type DestinationDialogId which has the same value as the element of type OriginationDialogId in the received DialogContinuePDU, and remain in the Idle state. If a PINX receives a DialogContinuePDU in the Active state which contains, in the element of type OriginationDialogId an unrecognised dialogue identifier, it shall send a DialogAbortPDU containing an element of type DestinationDialogId which has the same value as the element of type OriginationDialogId in the received DialogContinuePDU, and remain in the Active state.

8.4.6

Ex a m p le o f a d ia lo g u e Figure 10 shows an example of a dialogue between two PINXs, illustrating the usage and values of the origination and destination dialogue identifiers.

PINX A

PINX B DialogBeginPDU(ODId=x) DialogContinnuePDU(ODId=y), DDId=x)

DialogContinnuePDU(ODId=x), DDId=y) DialogContinnuePDU(ODId=y), DDId=x)

DialogEndPDU(DDId=y)

Key: DDId = DestinationDialogId ODId = OriginationDialogId F ig u r e 1 0 - A s im p le e x a m p le o f a D ia lo g u e 8.4.7

D y n a m ic D e s c r ip t io n ( S D L) o f D ia lo g u e I d e n t if ic a t io n P r o t o c o l P r o c e d u r e s Figure 12 provides an SDL representation of the dynamic aspects of the DSE protocol. Figure 11 contains a description of the elements used in figure 12.

- 43 -

Primitive received from SS-Control via the Coordination Function

DSE PDU received from GFT-Control via the Coordination Function

DSE PDU sent to GFT-Control via the Coordination Function

Primitive sent to SS-Control via the Coordination Function

State symbol

Decision symbol

Task symbol

F ig u r e 1 1 - K e y t o D ia lo g u e S D L d ia g r a m in f ig u r e 1 2

- 44 -

Idle

DialogBegin PDU

DialogBegin request

Assign local Dialogue ID

DialogBegin PDU

DialogCont. PDU

DialogEnd PDU

DialogAbort PDU

Discard PDU

Idle

Start Timer T_OD

Initiate sending

Is Originating Dialogue ID valid ?

YES

Save received Dialogue ID

Discard received PDU

DialogBegin indication

Initiate sending

Initiate receiving

F ig u r e 1 2 - D ia lo g u e p r o c e d u r e s d y n a m i c d e s c r i p t i o n ( s h e e t 1 o f 4 )

- 45 -

Initiate receiving

DialogCont. request

Assign local Dialogue ID

DialogCont. PDU

Active

DialogEnd request

DialogAbort request

DialogEnd PDU

DialogAbort PDU

Released saved Dialogue ID

Idle

F ig u r e 1 2 - D ia lo g u e p r o c e d u r e s d y n a m i c d e s c r i p t i o n ( s h e e t 2 o f 4 )

- 46 -

Initiate sending

DialogCont. PDU

DialogAbort request

DialogAbort PDU

Save received Dialogue ID

DialogAbort indication

Stop timer T_OD

DialogCont. indication

Released assigned Dialogue ID

Active

DialogEnd PDU

DialogEnd indication

Enet_timeout T_OD

DialogAbort indication

Idle

F ig u r e 1 2 - D ia lo g u e p r o c e d u r e s d y n a m i c d e s c r i p t i o n ( s h e e t 3 o f 4 )

- 47 -

Active

DialogCont. request

DialogCont. PDU

DialogAbort request

DialogEnd request

DialogAbort PDU

DialogEnd PDU

DialogAbort PDU

DialogAbort indication

Released assigned and stored Dialogue IDs DialogCont. PDU

Active

DialogEnd PDU

DialogEnd indication

DialogCont. PDU with unrecognised OriginationDialogID

Idle DialogCont. indication

Active

DialogAbort PDU

Active

F ig u r e 1 2 - D ia lo g u e p r o c e d u r e s d y n a m i c d e s c r i p t i o n ( s h e e t 4 o f 4 )

8.5

SS-Control requirements The requirements for SS-Control are supplementary service specific and are beyond the scope of this Standard.

Manufacturer Specific Information PSS1 permits the inclusion in messages of non-standardised information which is specific to a particular design of PINX or a particular network etc. This information is known as Manufacturer Specific Information (MSI). Manufacturer specific information may exist in the PISN as a result of the following: – manufacturer specific supplementary services; – manufacturer specific extensions to Standard supplementary services; or – manufacturer specific notifications. In all these cases, any information which is manufacturer specific shall be encoded in such a way that it can be uniquely identified. Apart from the use of information elements belonging to codesets 6 or 7, as described in ECMA-143 for conveyance of MSI to an Adjacent PINX, any manufacturer specific information generated by a PINX conforming to this Standard shall be encoded in conformance with the contents of this clause.

9.1

Manufacturer specific operations Manufacturer specific operations shall conform to the encoding and transport rules defined for standardised operations in other clauses of this Standard, but in addition shall make use of operation values which are unique to that manufacturer - i.e. of type OBJECT IDENTIFIER. If any non-standardised error values are to be included in a manufacturer specific operation, they shall be of type OBJECT IDENTIFIER. Examples of how manufacturer specific operations may be encoded are shown in annex F.

- 48 -

9.2

Manufacturer specific additions to standardised operations As an alternative to the definition of a manufacturer specific operation, a manufacturer may wish to use an enhanced form of a standardised operation. NOTE This may be used, for example, to include additional parameters which are manufacturer specific as part of the Standard service (e.g. information describing the detailed location of a party involved in the service). To allow for this possibility, Standards for supplementary services will include ‘placeholders’ for manufacturer specific extensions. Each placeholder will be an optional CHOICE construct containing an element of type Extension or a sequence of elements of type Extension (as defined in table 14) with the argument, result or error parameter of an operation. This placeholder may be included in the ROSE APDU if MSI is to be conveyed. An element of type Extension shall contain an element of type OBJECT IDENTIFIER to uniquely identify the MSI. If the Destination PINX identifies an element of type Extension or a sequence of elements of type Extension in a standardised operation, when processing the contents of a received Facility information element in accordance with the relevant supplementary service standard, it shall act on an element of type Extension only if it recognises the value in the element of type OBJECT IDENTIFIER (see table 14). Otherwise the entire element of type Extension shall be discarded. In the case of a sequence of elements of type Extension (i.e. where multiple extensions to the service are defined) the PINX shall consider each element of type Extension separately - that is, only those elements of type Extension containing an unrecognised value in the element of type OBJECT IDENTIFIER shall be discarded. Table 14 - Manufacturer specific extension mechanism Manufacturer-specific-service-extension-class-asn1-97 { iso( 1) standard( 0) pss1-generic-procedures( 11582) msi-class-asn1-97( 11) } DEFINITIONS BEGIN

::=

EXTENSION ::= CLASS { &ArgumentType, &extensionId OBJECT IDENTIFIER } WITH SYNTAX { ARGUMENT &ArgumentType IDENTIFIER &extensionId } Extension {EXTENSION:ExtensionSet} ::= SEQUENCE { extensionId EXTENSION.&extensionId({Extensionset}), extensionArgument EXTENSION.&ArgumentType({ExtensionSet}{@extensionId}) } Extensionset

EXTENSION ::= {...}

-- ExtensionSet is a set of objects of class EXTENSION. Element extensionId is constrained to be -- the identifier of an object from that set, and element extensionArgument is constrained to be the -- argument type for that particular object. END -- of Manufacturer-specific-service-extension-class-asn1-97 An example of the use of the Extension type is shown in annex F.

- 49 -

9.3

Manufacturer specific notifications Manufacturer specific notifications may occur in the PISN as part of manufacturer specific supplementary services or as additions to standardised supplementary services. If provided, they shall be encoded and transported across the PISN in accordance with the rules for standardised notifications (see 7.4, 10 and 11.3.4). Manufacturer specific notifications shall be conveyed using ASN.1 type NotificationDataStructure in octet 3.1 of the Notification indicator information element, as specified in 11.3.4. Manufacturer specific notifications shall not make use of the notification description field (octet 3) of the Notification indicator information element, other than to include the ‘discriminator for notification extension’ codepoint (see 11.3.4).

Message functional definitions and contents This clause describes additions to the call control messages defined in clause 13 of ECMA-143 and a number of new messages. The tables in this clause follow the conventions described in the introduction of clause 13 of ECMA-143. Table 15 summarises the messages that may also be used for the transport of APDUs and notification information, including those already defined in ECMA-143. Table 15 - PSS1 messages used for the transport of APDUs and notification information

10.1

Call establishment messages ALERTING CONNECT SETUP

Reference: 10.1 10.3 10.4

Call clearing messages DISCONNECT RELEASE RELEASE COMPLETE

Reference: 10.5 10.6 10.7

Miscellaneous messages FACILITY NOTIFY PROGRESS

Reference: 10.8 10.9 10.10

ALERTING Sub-clause 13.2.1 of ECMA-143 shall apply, with the following modification: – the information elements shown in table 16 may also be included: Table 16 - ALERTING message content Information Element

10.2

Reference

Type

Length

Facility

11.3.3

3-*

Notification indicator

11.3.4

3-*

CALL PROCEEDING Sub-clause 13.2.2 of ECMA-143 shall apply. NOTE Because of additional coding possibility in 11.3.2, the minimum length of the Channel identification information element can be 3 octets.

- 50 -

10.3

CONNECT Sub-clause 13.2.3 of ECMA-143 shall apply, with the following modification: – the information elements shown in table 17 may also be included: Table 17 - CONNECT message content Information Element

Reference

Type

Length

Facility

11.3.3

3-*

Notification indicator

11.3.4

3-*

NOTE In case of establishment of Call Independent Signalling Connection the following information elements are not included: Channel identification, Connected subaddress, Notification indicator, Low layer compatibility, Progress indicator.

10.4

SETUP Sub-clause 13.2.10 of ECMA-143 shall apply, with the following modification: – the information elements shown in table 18 may also be included: Table 18 - SETUP message content Information Element

Reference

Type

Length

Facility

11.3.3

3-*

Notification indicator

11.3.4

3-*

NOTE Because of additional coding possibility in 11.3.2, the minimum length of the Channel identification information element can be 3 octets.

10.5

DISCONNECT Sub-clause 13.2.5 of ECMA-143 shall apply, with the following modification: – the information elements shown in table 19 may also be included: Table 19 - DISCONNECT message content Information Element

Reference

Type

Length

Facility

11.3.3

3-*

Notification indicator

11.3.4

3-*

- 51 -

10.6

RELEASE Sub-clause 13.2.8 of ECMA-143 shall apply, with the following modification: – the information elements shown in table 20 may also be included: Table 20 - RELEASE message content Information Element Facility

10.7

Reference

Type

Length

11.3.3

3-*

RELEASE COMPLETE Sub-clause 13.2.9 of ECMA-143 shall apply, with the following modification: – the information elements shown in table 21 may also be included: Table 21 - RELEASE COMPLETE message content Information Element Facility

10.8

Reference

Type

Length

11.3.3

3-*

FACILITY This message, as shown in table 22, may be sent to transport APDUs. For the use of this message, refer to clause 7. Table 22 - FACILITY message content Message Type: FACILITY Direction: both Information Element

Reference

Type

Length

14.2 - ECMA143

Call reference

11.2

1-3 (note 1)

Message type

11.1

Facility

11.3.3

3-*

Notification indicator

11.3.4

3-*

Calling party number

14.5 - ECMA143

O (note 2)

Called party number

14.5 - ECMA143

O (note 2)

Protocol discriminator

4-32

NOTE 1 When the FACILITY message is used in a Connectionless manner, the dummy call reference (see 11.2) shall be used. NOTE 2 This information element is mandatory when the FACILITY message is used in a Connectionless manner, otherwise it shall not be included.

- 52 -

10.9

NOTIFY This message, as shown in table 23 may be sent by a PINX to provide notifications to a user, in association with a Basic call. For the use of this message, see 7.4. Table 23 - NOTIFY message content Message Type: NOTIFY Direction: both Information Element

Reference

Type

Length

14.2 - ECMA143

Call reference

11.2

Message type

11.1

Notification indicator

11.3.4

3-*

Protocol discriminator

10.10 PROGRESS Sub-clause 13.2.7 of ECMA-143 shall apply, with the following modification: – the information elements shown in table 24 may also be included: Table 24 - PROGRESS message content Information Element

Reference

Type

Length

Facility

11.3.3

3-*

Notification indicator

11.3.4

3-*

General message format and information element coding This clause describes information element coding in addition to that defined in clause 14 of ECMA-143. Where the contents of an information element field are described using ASN.1 notation, the encoding of this field shall be as defined in 11.4.

11.1

Message Type The following message type codings are additional to those defined in 14.4 of ECMA-143 and are used for the supplementary service specific messages defined in clause 10. Ta b le 2 5 - M e s s a g e t y p e s a p p lic a b le o v e r t h e P I S N Bits 8 7 6 5 4 3 2 1 0 1 1 Miscellaneous messages 0 0 0 1 0 FACILITY 0 1 1 1 0 NOTIFY

- 53 -

11.2

Call reference Sub-clause 14.3 of ECMA-143 shall apply, with the following addition: – The dummy call reference defined in figure 13 shall be used when a FACILITY message is sent in accordance with the procedures of 7.2. 8 0

7 0

6 0

5 0

4 0

3 0

2 0

1 0

octet 1

Figure 13 - Dummy call reference

11.3

Other information elements For the information elements defined in this clause, the coding and presentation rules defined in 14.5 of ECMA-143 shall apply. Table 26 lists the information element codings in codeset zero defined in this Standard in addition to those defined in table 22, 14.5 of ECMA-143. T a b l e 2 6 - A d d i t i o n a l c o d e s et ze r o i n f o r m a t i o n e l e m e n t s Bits 8 7 6 5 4 3 2 1 0 Variable length information elements 0 0 1 1 1 0 0 Facility 0 1 0 0 1 1 1 Notification indicator All other values are reserved

11.3.1

Bearer capability Sub-clause 14.5.5 of ECMA-143 shall apply with the additional codepoints in table 27. Table 27 - Bearer capability Coding standard (octet 3) Bits 7 6 0 1 Other international standard (note 1) Information transfer capability (octet 3) for coding standard ‘other international standard’ Bits 5 4 3 2 1 0 1 0 0 0 Unrestricted digital information All other values are reserved Transfer mode(octet 4) for coding standard ‘other international standard’ Bits 7 6 0 0 Call independent signalling connection All other values are reserved Information transfer rate (octet 4, bits 5 to 1) for coding standard ‘other international standard’ Bits 5 4 3 2 1 0 0 0 0 0 Call independent signalling connection All other values are reserved

- 54 -

NOTE 1 When this coding standard is indicated, the coding defined in 14.5.5 of ECMA-143 shall apply for octets 1 to 2 and bit 8 of octets 3 to 4. Information transfer capability, Transfer mode and Information transfer rate shall be encoded as indicated and no other octets shall be included. 11.3.2

C h a n n e l id e n t if ic a t io n Sub-clause 14.5.12 of ECMA-143 shall apply with the additional codepoints in table 28. Table 28 - Channel identification information element (note 1) Signalling channel indicator (octet 3) Bit 3 1

The channel identified is the signalling channel

Information channel selection (octet 3) Bits 2 1 0 0

No channel (note 2)

NOTE 1 Bits 8-4 of this octet are defined in accordance with sub-clause 14.5.12 of ECMA-143 and used in accordance with sub-clause 7.3.1.1 of this Standard. NOTE 2 When this coding is indicated, octets 3.2 and 3.3 shall be omitted. 11.3.3

Facility This clause defines only the structure and coding of the Facility information element. The purpose of Facility information element is to convey an optional Interpretation APDU and one or more ROSE APDUs, ACSE APDUs or DSE APDUs. All APDUs contained in the Facility information element will be delivered to the same PINX (as identified by the NFE). If the different APDUs are to be processed by different PINXs, they shall be included in different Facility information elements. The Facility information element may be repeated in a given message. The maximum length of the Facility information element is application dependent. The Facility information element is defined in figure 14 and tables 29 and 30.

- 55 -

4 3 Facility 1

octet 1

Information element identifier

1 ext

Length of information element contents

octet 2

0 0 spare spare

octet 3

Protocol Profile

Network Facility Extension (NFE) (note 1)

octet 3.1 * (note 2)

Network Protocol Profile (note 3)

octet 3.2 * (note 2)

Interpretation APDU (note 4)

octet 3.3 * (note 2)

Service APDU(s) (note 5)

octets 4 etc.

Figure 14 - Facility information element NOTE 1 The Network Facility Extension (NFE), as defined in 11.3.3.1, may be included, in accordance with the procedures of clause 7. NOTE 2 Each of octet groups 3.1, 3.2 and 3.3 comprises an ASN.1 type encoded as defined in 11.4. The presence or absence of each of these octet groups can be determined from the presence or absence of the tag values concerned in the appropriate position in the Facility information element. NOTE 3 The Network Protocol Profile may be included to specify the contents of the Service APDUs. If it is not included, the contents of all the Service APDUs shall be assumed to be ROSE. NOTE 4 The Interpretation APDU, as defined in 11.3.3.2, may be included, in accordance with the procedures in 8.1. NOTE 5 Octets 4 onwards shall comprise one of the following: − one or more ROSE APDUs as defined in 11.3.3.4; − one or more ACSE APDUs as defined in 11.3.3.5; or, − one or more DSE APDUs as defined in 11.3.3.3. The Network Protocol Profile shall comprise ASN.1 type NetworkProtocolProfile as defined in table 29 and encoded as defined in 11.4. The Protocol Profile in octet 3 of the Facility information element shall be encoded as shown in table 30.

- 56 -

Ta b le 2 9 - N e t wo r k P r o t o c o l P r o f ile Network-Protocol-Profile-definition-asn1-97 { iso( 1) standard( 0) pss1-generic-procedures( 11582) network-protocol-profile-definition-asn1-97( 19) } DEFINITIONS BEGIN

::=

NetworkProtocolProfile

::=

[18] IMPLICIT INTEGER { acse( 19), dse( 32) } (0..254)

END -- of Network-Protocol-Profile-definition-asn1-97

Ta b le 3 0 - P r o t o c o l P r o f ile C o d in g ( o c t e t 3 ) Bits 5 4 3 2 1 1 1 1 1 1 Networking Extensions All other values are reserved 11.3.3.1

Network Facility Extension (NFE) The NFE shall comprise ASN.1 type NetworkFacilityExtension as defined in table 31 and encoded in accordance with 11.4. This provides a means of routing the contents of the Facility information element within the context of a call or a call independent signalling connection across the PISN, and a means of identifying the origin and destination of the information, in accordance with the procedures of clause 7. Table 10 in 7.1.2.1 describes the use of the particular elements of the NFE. Table 31 - Network Facility Extension Network-Facility-Extension-asn1-97 { iso( 1) standard( 0) pss1-generic-procedures( 11582) network-facility-extension-asn1-97( 13) } DEFINITIONS ::= BEGIN IMPORTS

PartyNumber FROM Addressing-Data-Elements-asn1-97 { iso( 1) standard( 0) pss1-generic-procedures( 11582) addressing-data-elements-asn1-97( 20) };

NetworkFacilityExtension ::= [10] IMPLICIT SEQUENCE { sourceEntity [0] IMPLICIT EntityType, sourceEntityAddress [1] AddressInformation destinationEntity [2] IMPLICIT EntityType, destinationEntityAddress [3] AddressInformation } EntityType ::=

ENUMERATED { endPINX( 0), anyTypeOfPINX( 1) }

AddressInformation ::= END

PartyNumber

-- of Network-Facility-Extension-asn1-97

OPTIONAL, OPTIONAL

- 57 -

11.3.3.2

I n t e r p r e t a t io n A P D U The Interpretation ADPU shall comprise ASN.1 type InterpretationAPDU as defined in table 32, encoded in accordance with 11.4. This APDU provides a means whereby the originator can include optional instructions to the receiving PINX for use in the event that it does not understand the operation value of an Invoke APDU contained in octets 4 onwards of the Facility information element. Sub-clause 8.1 describes the use of the Interpretation APDU. Table 32 - Interpretation APDU Interpretation-Apdu-asn1-97 { iso( 1) standard( 0) pss1-generic-procedures( 11582) interpretation-apdu-asn1-97( 14) } DEFINITIONS ::= BEGIN InterpretationApdu ::= [11] IMPLICIT ENUMERATED { discardAnyUnrecognisedInvokePdu( 0), clearCallIfAnyInvokePduNotRecognised( 1), -- this value also applies to Call independent signalling connections -- see clause 8.1.2 rejectAnyUnrecognisedInvokePdu( 2) -- this coding is implied by the absence of an -- interpretation APDU. } END

-- of Interpretation-Apdu-asn1-97

- 58 -

11.3.3.3

DSE APDU A DSE APDU shall comprise ASN.1 type DseAPDU as defined in table 33 and encoded in accordance with 11.4. Ta b le 3 3 - D S E A P D U s ( s h e e t 1 o f 2 )

Dialog-Service-Pdus-asn1-97 {iso( 1) standard( 0) pss1-generic-procedures( 11582) dialog-service-pdus-asn1-97( 15) } DEFINITIONS ::= BEGIN IMPORTS RoseAPDU, InvokeId, InvokeIdSet FROM PSS1-Service-APDUs-asn1-97 { iso( 1) standard( 0) pss1-generic-procedures( 11582) pss1-service-apdus-asn1-97( 16)} AcseAPDU FROM Association-Control-Apdus-asn1-97 {iso( 1) standard( 0) pss1-generic-procedures( 11582) association-control-apdus-asn1-97( 12)} EXTENSION, Extension{} FROM Manufacturer-specific-service-extension-class-asn1-97 { iso( 1) standard( 0) pss1-generic-procedures( 11582) msi-class-asn1-97( 11)} OPERATION FROM Remote-Operations-Information-Objects {joint-iso-itu-t remote-operations(4) informationObjects(5) version1(0)}; DseAPDU ::=

CHOICE { begin end continue abort

[12] IMPLICIT DialogBeginPDU, [14] IMPLICIT DialogEndPDU, [15] IMPLICIT DialogContinuePDU, [17] IMPLICIT DialogAbortPDU

DialogBeginPDU ::= SEQUENCE { originationDialogId remoteOperationsPortion DialogEndPDU

DialogContinuePDU

DialogAbortPDU

OriginationDialogId, RemoteOperationsPortion

OPTIONAL

}

::= SEQUENCE { destinationDialogId remoteOperationsPortion

DestinationDialogId, RemoteOperationsPortion

OPTIONAL

}

::= SEQUENCE { originationDialogId destinationDialogId remoteOperationsPortion

OriginationDialogId, DestinationDialogId, RemoteOperationsPortion

OPTIONAL

}

::= SEQUENCE { destinationDialogId abortChoice CHOICE { p-AbortCause userAbortInformation

DestinationDialogId, P-AbortCause, UserAbortInformation

OriginationDialogId

::= [0] IMPLICIT OCTET STRING (SIZE(0..8))

DestinationDialogId

::= [1] IMPLICIT OCTET STRING (SIZE(0..8))

P-AbortCause

::= [2] IMPLICIT INTEGER { unrecognisedDseApdu( 0), unrecognisedDialogId( 1), badlyFormattedDseApdu( 2), incorrectDseApdu( 3), resourceLimitation( 4)

UserAbortInformation ::= [3] IMPLICIT Extension{{DSE-Extension-Set}} DSE-Extension-Set

}

EXTENSION ::= {...}

}

} (0..255)

}

- 59 -

Ta b le 3 3 - D S E A P D U s ( s h e e t 2 o f 2 ) RemoteOperationsPortion ::= [4] IMPLICIT SEQUENCE OF CHOICE { roseAPDU [17] RoseAPDU{{InvokeIdSet},{OperationSet},{OperationSet}}, acseAPDU [19] AcseAPDU } OperationSet OPERATION ::= {...} END -- of Dialog-Service-Pdus-asn1-97

11.3.3.4

ROSE APDU A ROSE APDU shall comprise ASN.1 type RoseAPDU as defined in table 34 and encoded in accordance with 11.4. In accordance with X.880, ROSE APDUs are of four types: –

Invoke APDU (ASN.1 type Invoke in X.880);

–

Return result APDU (ASN.1 type ReturnResult in X.880);

–

Return error APDU (ASN.1 type ReturnError in X.880);

–

Reject APDU (ASN.1 type Reject in X.880).

Invoke APDUs, return result APDUs and return error APDUs used in the context of a supplementary service will be implicitly defined by the operations and errors used by that supplementary service. These operations and errors will be defined using ASN.1 in the relevant supplementary service specifications (standardised or manufacturer specific). Certain supplementary services may require the use within ROSE APDUs of existing information elements encoded according to the rules of 14.5 of ECMA-143 within the argument of an invoke APDU, the result of a return result APDU, or the parameter of a return error APDU (with the exception of the Facility information element, which shall not be included in this way). In such a case, these information elements shall be included within an element of type PSS1InformationElement within the argument or result of the operation concerned or the parameter of the error concerned. In this way, the ECMA-143 encoding for these information elements can be retained. If more than one information element is to be included as part of the same argument, result or parameter, all the information elements shall be grouped together within the same element of type PSS1InformationElement. The type PSS1InformationElement is encoded as shown in table B.3 on page 81.

- 60 -

Table 34 - PSS1 Service APDUs (sheet 1 of 4) PSS1-Service-APDUs-asn1-97 { iso( 1) standard( 0) pss1-generic-procedures( 11582) pss1-service-apdus-asn1-97( 16)} DEFINITIONS IMPLICIT TAGS ::= BEGIN -- exports everything IMPORTS

OPERATION, ERROR FROM Remote-Operations-Information-Objects {joint-iso-itu-t remote-operations(4) informationObjects(5) version1(0)};

RoseAPDU {InvokeId:InvokeIdSet, OPERATION:Invokable, OPERATION:Returnable} ::= CHOICE { invoke [1] Invoke {{InvokeIdSet}, {Invokable}}, returnResult [2] ReturnResult {{Returnable}}, returnError [3] ReturnError {{Errors{{Returnable}}}}, reject [4] Reject } (CONSTRAINED BY { -- must conform to the above definition -- } ! RejectProblem : general-unrecognisedPDU) Invoke {InvokeId:InvokeIdSet, OPERATION:Operations} ::= SEQUENCE { invokeId InvokeId (InvokeIdSet) (CONSTRAINED BY {-- must be unambiguous --} ! RejectProblem : invoke-duplicateInvocation), linkedId [0] InvokeId (CONSTRAINED BY {-- must identify an outstanding operation --} ! RejectProblem : invoke-unrecognisedLinkedId) (CONSTRAINED BY {-- which has one or more linked operations--} ! RejectProblem : invoke-linkedResponseUnexpected) OPTIONAL, opcode OPERATION.&operationCode ({Operations} ! RejectProblem : invoke-unrecognisedOperation), argument OPERATION.&ArgumentType ({Operations} {@opcode} ! RejectProblem : invoke-mistypedArgument) OPTIONAL } (CONSTRAINED BY { -- must conform to the above definition -- } ! RejectProblem : general-mistypedPDU) (

WITH COMPONENTS {..., linkedId ABSENT }|

- 61 -

Table 34 - PSS1 Service APDUs (sheet 2 of 4) WITH COMPONENTS {..., linkedId PRESENT, opcode (CONSTRAINED BY {-- must be in the &Linked field of the associated operation --} ! RejectProblem : invoke-unexpectedLinkedOperation) } ) ReturnResult {OPERATION:Operations}::= SEQUENCE { invokeId InvokeId (CONSTRAINED BY {-- must be that for an outstanding operation --} ! RejectProblem : returnResult-unrecognisedInvocation) (CONSTRAINED BY {-- which returns a result --} ! RejectProblem : returnResult-resultResponseUnexpected), result SEQUENCE { opcode OPERATION.&operationCode ({Operations})(CONSTRAINED BY {-- identified by invokeId --} ! RejectProblem : returnResult-unrecognisedInvocation), result OPERATION.&ResultType ({Operations} {@.opcode} ! RejectProblem : returnResult-mistypedResult) } OPTIONAL } (CONSTRAINED BY { -- must conform to the above definition -- } ! RejectProblem : general-mistypedPDU) ReturnError {ERROR:Errors} ::= SEQUENCE { invokeId InvokeId (CONSTRAINED BY {-- must be that for an outstanding operation --} ! RejectProblem : returnError-unrecognisedInvocation) (CONSTRAINED BY {-- which returns an error --} ! RejectProblem : returnError-errorResponseUnexpected), errcode ERROR.&errorCode ({Errors} ! RejectProblem : returnError-unrecognisedError) (CONSTRAINED BY {--must be in the &Errors field of the associated operation --} ! RejectProblem : returnError-unexpectedError), parameter ERROR.&ParameterType ({Errors}{@errcode} ! RejectProblem : returnError-mistypedParameter) OPTIONAL } (CONSTRAINED BY { -- must conform to the above definition -- } ! RejectProblem : general-mistypedPDU)

- 62 -

Table 34 - PSS1 Service APDUs (sheet 3 of 4) Reject ::= SEQUENCE { invokeId InvokeIdOrNull, problem CHOICE { general [0] GeneralProblem, invoke [1] InvokeProblem, returnResult [2] ReturnResultProblem, returnError [3] ReturnErrorProblem } } (CONSTRAINED BY { -- must conform to the above definition -- } ! RejectProblem : general-mistypedPDU) GeneralProblem ::= INTEGER { unrecognisedPDU(0), mistypedPDU (1), badlyStructuredPDU (2) } InvokeProblem ::= INTEGER { duplicateInvocation (0), unrecognisedOperation (1), mistypedArgument (2), resourceLimitation (3), initiatorReleasing (4), unrecognisedLinkedId (5), linkedResponseUnexpected (6), unexpectedChildOperation (7) } ReturnResultProblem ::= INTEGER { unrecognisedInvocation (0), resultResponseUnexpected (1), mistypedResult (2) } ReturnErrorProblem ::= INTEGER { unrecognisedInvocation (0), errorResponseUnexpected (1), unrecognisedError (2), unexpectedError (3), mistypedParameter (4) }

- 63 -

Table 34 - PSS1 Service APDUs (sheet 4 of 4) RejectProblem ::= INTEGER { general-unrecognisedPDU (0), general-mistypedPDU (1), general-badlyStructuredPDU (2), invoke-duplicateInvocation (10), invoke-unrecognisedOperation (11), invoke-mistypedArgument (12), invoke-resourceLimitation (13), invoke-releaseInProgress (14), invoke-unrecognisedLinkedId (15), invoke-linkedResponseUnexpected (16), invoke-unexpectedLinkedOperation (17), returnResult-unrecognisedInvocation (20), returnResult-resultResponseUnexpected (21), returnResult-mistypedResult (22), returnError-unrecognisedInvocation (30), returnError-errorResponseUnexpected (31), returnError-unrecognisedError (32), returnError-unexpectedError (33), returnError-mistypedParameter (34) } InvokeId

::= INTEGER

InvokeIdOrNull ::= CHOICE { present InvokeId (InvokeIdSet), absent NULL } InvokeIdSet INTEGER ::= {INTEGER(-32768..32767)} Errors {OPERATION:Operations} ERROR ::= {Operations.&Errors} END

11.3.3.5

-- PSS1-Service-APDUs-asn1-97

ACSE APDU An ACSE APDU shall comprise ASN.1 type AcseAPDU as defined in table 35 and encoded in accordance with 11.4. Type ACSE-apdu is defined in section 9 of X.227. Table 35 - ACSE APDUs Association-Control-Apdus-asn1-97 {iso( 1) standard( 0) pss1-generic-procedures( 11582) association-control-apdus-asn1-97( 12) } DEFINITIONS

::=

BEGIN IMPORTS ACSE-apdu FROM ACSE-1 { joint-iso-itu-t association-control(2) modules(0) apdus(0) version1( 1) }; AcseAPDU

::= ACSE-apdu

END --of Association-Control-Apdus-asn1-97 11.3.4

N o t if ic a t io n in d ic a t o r The purpose of the Notification indicator information element is to convey a notification.

- 64 -

The Notification indicator information element is coded as shown in figure 15 and tables 36 and 37. The maximum length of the information element is application dependent. The Notification indicator information element may be repeated in a message. 8

1 ext

5 4 3 2 Notification indicator 1 0 0 1 1 Information element identifier

1 1

octet 1

Length of information element contents

octet 2

Notification Description (table 36)

octet 3

ASN.1 encoded Notification Data Structure (table 37)

octet 4 * (note 1)

F i g u r e 1 5 - N o t i f i c a t i o n in d i c a t o r i n f o r m a t i o n e l e m e n t NOTE 1 Octet 4 shall only be included when the notification description indicates the “discriminator for notification extension” or "discriminator for extension to ASN.1 notification data structure". T a b l e 3 6 - N o t i f i c a t i o n D e s c r ip t i o n e n c o d i n g ( o c t e t 3 ) Bits 7 6 5 4 3 2 1 0 0 0 0 0 0 0 to 0 0 0 0 0 1 0 0 0 0 0 0 1 1 0 0 0 0 1 0 0 to

reserved for notification values assigned in ITU-T Recommendation Q.932 discriminator for notification extension reserved for notification values assigned in ITU-T Recommendation Q.932

0 0 1 1 1 1 1 0 1 0 0 0 0 0 to 0 1 1 1 1 1 1 1 0 0 0 0 0 0

reserved for notification values assigned by ISO discriminator for extension to ISO defined ASN.1 encoded notification data structure

1 0 0 0 0 0 1 to

reserved for notification values assigned in ITU-T Recommendation Q.932

1 1 1 1 1 1 1 All values shall be treated as valid

Notification Description value “discriminator for notification extension” shall be used for notifications defined using ASN.1 in which the notification value is either of type INTEGER with a value defined by ITU-T or of type OBJECT IDENTIFIER. Notification values of type OBJECT IDENTIFIER include manufacturer specific notifications (see 9.3). Notification Description value “discriminator for extension to ISO defined ASN.1 encoded data structure” shall be used for notifications defined using ASN.1 in which the notification value is of type INTEGER with a value defined by ISO. In either case, octet 4 shall contain ASN.1 type NotificationDataStructure, as defined in table 37. Element notificationTypeID shall contain the notification value and element notificationArgument shall contain any additional data.

- 65 -

Table B.2 in annex B also defines the notification pss1IeNotification, which can be used to convey PSS1 information elements as a notification. Other notifications will be defined using the NOTIFICATION class in the relevant supplementary services specifications (standardised or manufacturer specific). Table 37 - ASN.1 encoded Notification Data Structure Notification-Data-Structure-asn1-97 { iso( 1) standard( 0) pss1-generic-procedures( 11582) notification-data-structure-asn1-97( 18) } DEFINITIONS ::= BEGIN IMPORTS

NOTIFICATION FROM Notification-Class-asn1-97 { iso( 1) standard( 0) pss1-generic-procedures( 11582) notification-class-asn1-97( 21) };

NotificationDataStructure {NOTIFICATION:NotificationSet} ::= SEQUENCE { notificationValue NOTIFICATION.&notificationCode ({NotificationSet}), notificationArgument NOTIFICATION.&ArgumentType ({NotificationSet}{@notificationValue}) OPTIONAL } NotificationSet NOTIFICATION ::= {...} -- NotificationSet is a set of objects of class NOTIFICATION. Element notificationValue is -- constrained to be the identifier of an object from that set, and element notificationArgument is -- constrained to be the argument type for that particular object. END

11.4

-- of Notification-Data-Structure-asn1-97

Encoding of information described using ASN.1 Where the contents of an information element field are defined using ASN.1 notation, the encoding of this field shall be in accordance with the Basic Encoding Rules (BER) defined in X.690 with the following restrictions: – when the definite form is used for length encoding, a data value of length less than 128 octets shall have the length encoded in the short form; – when the long form is used for length encoding, the minimum number of octets shall be used to encode the length field; and, – values of the type OCTET STRING or BIT STRING shall be encoded in a primitive form. Receiving entities shall be able to interpret all length forms of the basic encoding rules.

- 66 -

- 67 -

Annex A ( n o r ma tiv e )

Protocol Implementation Conformance Statement (PICS) for ECMA-165

A.1

Introduction The supplier of a protocol implementation which is claimed to conform to ECMA-165 shall complete the following Protocol Implementation Conformance Statement (PICS) proforma. A completed PICS proforma is the PICS for the implementation in question. The PICS is a statement of which capabilities and options of the protocol have been implemented. The PICS can have a number of uses, including use: – by the protocol implementor, as a check list to reduce the risk of failure to conform to the standard through oversight; – by the supplier and acquirer - or potential acquirer - of the implementation, as a detailed indication of the capabilities of the implementation, stated relative to the common basis for understanding provided by the standards PICS proforma; – by the user or potential user of the implementation, as a basis for initially checking the possibility of interworking with another implementation; NOTE While interworking can never be guaranteed, failure to interwork can often be predicted from incompatible PICS’s. – by a protocol tester, as the basis for selecting appropriate tests against which to assess the claim for conformance of the implementation.

A.2

Instructions for completing the PICS proforma

A.2.1

General structure of the PICS proforma The PICS proforma is a fixed format questionnaire divided into sub-clauses each containing a group of individual items. Each item is identified by an item number, the name of the item (question to be answered), and the reference(s) to the clause(s) that specifies (specify) the item in the main body of this Standard. The “Status” column indicates whether an item is applicable and if so whether support is mandatory or optional. The following terms are used: m

mandatory (the capability is required for conformance to the protocol);

optional (the capability is not required for conformance to the protocol, but if the capability is implemented it is required to conform to the protocol specifications);

o.<n>

optional, but support of at least one of the group of options labelled by the same numeral <n> is required;

prohibited;

c.<cond>

conditional requirement, depending on support for the item or items listed in condition <cond>;

<item>:m

simple conditional requirement, the capability being mandatory if item number <item> is supported, otherwise not applicable;

- 68 -

<item>:o

simple conditional requirement, the capability being optional if item number <item> is supported, otherwise not applicable.

Answers to the questionnaire items are to be provided either in the “Support” column, by simply marking an answer to indicate a restricted choice (Yes or No), or in the “Not Applicable” column (N/A).

A.2.2

Additional information Items of Additional Information allow a supplier to provide further information intended to assist the interpretation of the PICS. It is not intended or expected that a large quantity will be supplied, and a PICS can be considered complete without any such information. Examples might be an outline of the ways in which a (single) implementation can be set up to operate in a variety of environments and configurations. References to items of Additional Information may be entered next to any answer in the questionnaire, and may be included in items of Exception information.

A.2.3

Exception information It may occasionally happen that a supplier will wish to answer an item with mandatory or prohibited status (after any conditions have been applied) in a way that conflicts with the indicated requirement. No preprinted answer will be found in the Support column for this: instead, the supplier is required to write into the support column an x.<i> reference to an item of Exception Information, and to provide the appropriate rationale in the Exception item itself. An implementation for which an Exception item is required in this way does not conform to ECMA-165. NOTE A possible reason for the situation described above is that a defect in the Standard has been reported, a correction for which is expected to change the requirement not met by the implementation.

- 69 -

A.3

PICS proforma

A.3.1

Implementation Identification Supplier (note 1)

Contact point for queries about the PICS (note 1)

Implementation Name(s) and Version(s) (note 1, note 2) Other information necessary for full identification e.g., name(s) and version(s) for machines and/or operating systems; System name(s) NOTE 1 Only the first three items are required for all implementations; other information may be completed as appropriate in meeting the requirement for full identification. NOTE 2 The terms Name and Version should be interpreted appropriately to correspond with a suppliers terminology (e.g. Type, Series, Model).

A.3.2

Protocol Summary, ECMA-165 Protocol version

1.0

Addenda Implemented (if applicable) Amendments Implemented Have any exception items been required?

No[ ]Yes[ ] (The answer Yes means that the implementation does not conform to ECMA-165)

Date of Statement

- 70 -

A.3.3

Call Related Protocol Control and GFT-Control requirements

ITEM

QUESTION/FEATURE

Can the implementation act as a Source PINX for APDUs?

7.1.1.1

Yes[ ] No [ ]

Sending the Facility information element

7.1.1.1

Yes [ ]

Receiving the Facility information element

7.1.1.2

Yes [ ]

Actions at a Source PINX

7.1.2.1

A1:m

Actions at a Receiving PINX

7.1.2.2

Yes [ ]

Can the PINX act as an Originating, Terminating, Incoming or Outgoing GatewayPINX as defined in ECMA-143?

4 & ECMA143

o.1

Yes[ ] No [ ]

End PINX actions

7.1.2.2.1

A7:m

Actions at a Destination PINX

7.1.2.3

Yes [ ]

A10

Can the PINX act as a Transit PINX as defined in ECMA-143?

4 & ECMA143

o.1

Yes[ ] No [ ]

A11

Transit PINX actions

7.1.2.2.2

A10:m

A12

Can the implementation generate notification information?

7.4

A13

Sending notification information

7.4.2.1

A12:m

A14

Receiving notification information

7.4.2.2

A15

Actions at a PINX which generates notifications

7.4.3.1

A12:m

[]

Yes [ ]

A16

Actions at a Transit PINX

7.4.3.2

A10:m

[]

Yes [ ]

A17

Actions at a Receiving End PINX

7.4.3.3

A7:m

[]

Yes [ ]

A.3.4

REFERENCE STATUS

N/A

[]

SUPPORT

Yes [ ]

Yes [ ] Yes[ ] No [ ]

[]

Yes [ ] Yes [ ]

Connectionless APDU transport mechanism

ITEM

QUESTION/FEATURE

REFERENCE STATUS

N/A

SUPPORT

Does the PINX support Connectionless APDU transport?

7.2

Requirements for sending a Connectionless message

7.2.1.1

B1:m

[]

Yes [ ]

Requirements for receiving a Connectionless message

7.2.1.2

B1:m

[]

Yes [ ]

Actions at a Receiving PINX

7.2.2.2

B1:m

[]

Yes [ ]

Actions at a Destination PINX

7.2.2.3

B1:m

[]

Yes [ ] No [ ]

Actions at a Source PINX

7.2.2.1

B1:o

[]

Yes [ ] No [ ]

Yes[ ] No [ ]

- 71 -

A.3.5

Connection oriented APDU transport mechanism

ITEM

QUESTION/FEATURE

REFERENCE

STATUS

N/A

SUPPORT

Does the PINX support connection-oriented APDU transport?

7.3

Can the implementation act as a Source PINX for APDUs when supporting the Connection oriented APDU transport mechanism?

7.3

C1:o

[]

Yes[ ] No [ ]

Connection oriented transport mechanism Protocol Control requirements

7.3.1

C1:m

[]

Yes [ ]

Actions at an Originating PINX

7.3.3.1

C1:o

[]

Yes [ ] No [ ]

Actions at a Transit PINX

7.3.3.2

c.1

[]

Yes [ ]

Actions at a Terminating PINX

7.3.3.3

C1:o

[]

Yes [ ] No [ ]

Actions at a Source PINX

7.3.3.4

C2:m

[]

Yes [ ]

Actions at a Destination PINX

7.3.3.5

C1:m

[]

Yes [ ]

c.1

A.3.6 ITEM

Yes[ ] No [ ]

IF (A10 AND C1) THEN m, ELSE N/A

Coordination Function requirements QUESTION/FEATURE

REFERENCE STATUS

N/A

SUPPORT

Inclusion of an Interpretation APDU at a Source PINX

8.1.1

Yes [ ] No [ ]

Handling of APDUs at a Destination PINX

8.1.2

Yes [ ]

A.3.7 ITEM E1

A.3.8 ITEM

ROSE requirements QUESTION/FEATURE ROSE requirements

REFERENCE STATUS 8.2

REFERENCE

STATUS

N/A

SUPPORT Yes [ ]

ACSE requirements QUESTION/FEATURE

Does implementation support the ACSE protocol?

8.3

ACSE requirements

8.3

G1:m

N/A

SUPPORT Yes [ ] No [ ]

[]

Yes [ ]

- 72 -

A.3.9 ITEM

DSE requirements QUESTION/FEATURE

REFERENCE STATUS

N/A

SUPPORT

Does implementation support the DSE protocol?

8.4

Actions at the PINX which initiates the dialogue

8.4.1

F1:o.2

[]

Yes [ ] No [ ]

Actions at the PINX which terminates the dialogue

8.4.2

F1:o.2

[]

Yes [ ] No [ ]

Actions for dialogue continuation

8.4.3

F1:m

[]

Yes [ ]

T_Originating_Dialogue

8.4.4

F2:m

[]

Yes [ ] value [

Error procedures relating to dialogue control

8.4.5

F1:m

Yes [ ] No [ ]

[]

Yes [ ]

A.3.10 Manufacturer specific information ITEM

QUESTION/FEATURE

REFERENCE STATUS

N/A

SUPPORT

Manufacturer specific operations

9.1

Yes [ ] No[ ]

Manufacturer specific additions to standardised operations

9.2

Yes [ ] No[ ]

Manufacturer specific notifications

9.3

Yes [ ] No[ ]

A.3.11 Messages and information elements ITEM

QUESTION/FEATURE

REFERENCE STATUS

N/A

SUPPORT

General message format and information element coding

Yes [ ]

Message type

11.1

Yes [ ]

Dummy Call reference

11.2

B1:m

[]

Yes [ ]

Bearer Capability

11.3.1

C1:m

[]

Yes [ ]

Channel identification

11.3.2

C1:m

[]

Yes [ ]

Facility information element structure

11.3.3

Yes [ ]

Network Facility Extension

11.3.3.1

Yes [ ]

Interpretation APDU

11.3.3.2

Yes [ ]

DSE APDUs

11.3.3.3

F1:m

I10

ROSE APDUs

11.3.3.4

Yes [ ]

I11

Notification indicator

11.3.4

Yes [ ]

I12

ACSE APDUs

11.3.3.5

G1:m

I13

Encoding of ASN.1 defined elements

11.4

Yes [ ]

I14

Network Protocol Profile

11.3.3

Yes [ ]

[]

Yes [ ]

- 73 -

A.3.12 Implemented parameters in ECMA-165 messages NOTE In the following clauses, the headings ‘Orig’ and ‘Rx’ should be interpreted as follows: ‘Orig’: the capability to originate the element specified - i.e. create the element and send it on an PSS1link; not relay the element having received it from a Preceding PINX. ‘Rx’: the capability to correctly receive and process the specified element as a valid element from a Preceding PINX; including relay of the element to a Subsequent PINX if acting as a Transit PINX for the related call or connection. A . 3 . 1 2 . 1 A LER TI N G m e s s a g e ITEM

QUESTION/FEATURE

REFERENCE STATUS

N/A

SUPPORT

[]

Yes [ ] No [ ]

Facility information element - Orig

10.1, 11.3.3

A1:o.3

Facility information element - Rx

10.1, 11.3.3

Notification indicator information element - Orig

10.1, 11.3.4

A12:o.4

Notification indicator information element - Rx

10.1, 11.3.4

Yes [ ] []

Yes [ ] No [ ] Yes [ ]

A . 3 . 1 2 . 2 C O N N EC T m e s s a g e ITEM

QUESTION/FEATURE

REFERENCE STATUS

N/A

SUPPORT

[]

Yes [ ] No [ ]

Facility information element - Orig

10.3, 11.3.3

c.2

Facility information element - Rx

10.3, 11.3.3

Notification indicator information element - Orig

10.3, 11.3.4

A12:o.4

Notification indicator information element - Rx

10.3, 11.3.4

c.2

Yes [ ] []

Yes [ ] No [ ] Yes [ ]

IF (A1 OR C2) THEN o.3, ELSE N/A

A . 3 . 1 2 . 3 S ETU P m e s s a g e ITEM

QUESTION/FEATURE

REFERENCE STATUS

N/A

SUPPORT

[]

Yes [ ] No [ ]

Facility information element - Orig

10.4, 11.3.3

c.2

Facility information element - Rx

10.4, 11.3.3

Notification indicator information element - Orig

10.4, 11.3.4

A12:o.4

Notification indicator information element - Rx

10.4, 11.3.4

Yes [ ] []

Yes [ ] No [ ] Yes [ ]

A . 3 . 1 2 . 4 D I S C O N N EC T m e s s a g e ITEM

QUESTION/FEATURE

REFERENCE STATUS

N/A

SUPPORT

Facility information element - Orig

10.5, 11.3.3

A1:o.3

[]

Yes [ ] No [ ]

Facility information element - Rx

10.5, 11.3.3

Notification indicator information element - Orig

10.5, 11.3.4

A12:o.4

Notification indicator information element - Rx

10.5, 11.3.4

Yes [ ] []

Yes [ ] No [ ] Yes [ ]

- 74 -

A.3.12.5 RELEASE message ITEM

QUESTION/FEATURE

REFERENCE STATUS

N/A

SUPPORT

[]

Yes [ ] No [ ]

Facility information element - Orig

10.6, 11.3.3

c.2

Facility information element - Rx

10.6, 11.3.3

Yes [ ]

A.3.12.6 RELEASE COMPLETE message ITEM

QUESTION/FEATURE

REFERENCE STATUS

N/A

SUPPORT

[]

Yes [ ] No [ ]

Facility information element - Orig

10.7, 11.3.3

c.2

Facility information element - Rx

10.7, 11.3.3

Yes [ ]

A . 3 . 1 2 . 7 F A C I LI TY m e s s a g e ITEM

QUESTION/FEATURE

REFERENCE STATUS

N/A

SUPPORT

FACILITY message - Orig

10.8

c.3

[]

Yes [ ] No [ ]

Protocol discriminator- Orig

10.8, (14.2 ECMA-143)

P1:m

[]

Yes [ ]

Protocol discriminator- Rx

10.8, (14.2 ECMA-143)

Call reference-Orig

10.8, 11.2

P1:m

Call reference-Rx

10.8, 11.2

Message type-Orig

10.8, 11.1

P1:m

Message type-Rx

10.8, 11.1

Calling party number - Orig

10.8, 14.5 of ECMA-143

B7:m

[]

Yes [ ]

Calling party number - Rx

10.8, 14.5 of ECMA-143

B1:m

[]

Yes [ ]

P10

Called party number - Orig

10.8, 14.5 of ECMA-143

B7:m

[]

Yes [ ]

P11

Called party number - Rx

10.8, 14.5 of ECMA-143

B1:m

[]

Yes [ ]

P12

Facility information element - Orig

10.8, 11.3.3

P1:m

[]

Yes [ ]

P13

Facility information element - Rx

10.8, 11.3.3

P14

Notification indicator information element - Orig

10.8, 11.3.4

c.4

P15

Notification indicator information element - Rx

10.8, 11.3.4

c.3

IF (A1 OR C2) THEN o.3ELSE IF B7 THEN mELSE N/A

c.4

IF (P1 AND A12) THEN o.4ELSE N/A

Yes [ ] []

Yes [ ] Yes [ ]

[]

Yes [ ] Yes [ ]

Yes [ ] []

Yes [ ] No [ ] Yes [ ]

- 75 -

A . 3 . 1 2 . 8 N O TI F Y m e s s a g e ITEM

QUESTION/FEATURE

NOTIFY message - Orig

REFERENCE STATUS

N/A

SUPPORT

10.9

A12:o.4

[]

Yes [ ] No [ ]

Protocol discriminator - Orig

10.9, (14.2 of ECMA-143)

Q1:m

[]

Yes [ ]

Protocol discriminator- Rx

10.9, (14.2 of ECMA-143)

Call reference – Orig

10.9, 11.2

Q1:m

Call reference – Rx

10.9, 11.2

Message type – Orig

10.9, 11.1

Q1:m

Message type – Rx

10.9, 11.1

Notification Indicator - Orig

10.9, 11.3.4

Q1:m

Notification Indicator - Rx

10.9, 11.3.4

Yes [ ] []

Yes [ ] Yes [ ]

[]

Yes [ ] Yes [ ]

[]

Yes [ ] Yes [ ]

A . 3 . 1 2 . 9 P R O G R ES S m e s s a g e ITEM

QUESTION/FEATURE

REFERENCE STATUS

N/A

SUPPORT

[]

Yes [ ] No [ ]

Facility information element - Orig

10.10, 11.3.3

A1:o.3

Facility information element – Rx

10.10, 11.3.3

Notification indicator information element – Orig

10.10, 11.3.4

A12:o.4

Notification indicator information element – Rx

10.10, 11.3.4

Yes [ ] []

Yes [ ] No [ ] Yes [ ]

- 76 -

- 77 -

Annex B ( n o r ma tiv e )

ASN.1 definitions of generic parameters

This annex contains definitions for generic parameters used in this and other Standards.

B.1

Addressing information Table B.1 contains the definition of ASN.1 types for encoding PISN addressing information. T a b l e B . 1 - A d d r e s s i n g i n f o r m a t i o n d e f in it io n s ( s h e e t 1 o f 3 ) Addressing-Data-Elements-asn1-97 {iso( 1) standard( 0) pss1-generic-procedures( 11582) addressing-data-elements-asn1-97( 20)} DEFINITIONS EXPLICIT TAGS ::= BEGIN PresentedAddressScreened ::= CHOICE { presentationAllowedAddress [0] IMPLICIT AddressScreened, presentationRestricted [1] IMPLICIT NULL, numberNotAvailableDueToInterworking [2] IMPLICIT NULL, presentationRestrictedAddress [3] IMPLICIT AddressScreened} PresentedAddressUnscreened ::= CHOICE { presentationAllowedAddress [0] IMPLICIT Address, presentationRestricted [1] IMPLICIT NULL, numberNotAvailableDueToInterworking [2] IMPLICIT NULL, presentationRestrictedAddress [3] IMPLICIT Address} PresentedNumberScreened ::= CHOICE { presentationAllowedAddress [0] IMPLICIT NumberScreened, presentationRestricted [1] IMPLICIT NULL, numberNotAvailableDueToInterworking [2] IMPLICIT NULL, presentationRestrictedAddress [3] IMPLICIT NumberScreened} PresentedNumberUnscreened ::= CHOICE { presentationAllowedAddress [0] PartyNumber, presentationRestricted [1] IMPLICIT NULL, numberNotAvailableDueToInterworking [2] IMPLICIT NULL, presentationRestrictedAddress [3] PartyNumber} AddressScreened

::=

SEQUENCE { partyNumber PartyNumber, screeningIndicator ScreeningIndicator, partySubaddress PartySubaddress OPTIONAL}

NumberScreened

::= SEQUENCE { partyNumber PartyNumber, screeningIndicator ScreeningIndicator}

Address

::= SEQUENCE { partyNumber PartyNumber, partySubaddress PartySubaddress OPTIONAL}

- 78 -

T a b l e B . 1 - A d d r e s s i n g i n f o r m a t i o n d e f in it io n s ( s h e e t 2 o f 3 ) PartyNumber

::= CHOICE { unknownPartyNumber [0] IMPLICIT NumberDigits, -- the numbering plan is the default numbering -- plan of the network. It is recommended that -- this value is used. publicPartyNumber [1] IMPLICIT PublicPartyNumber, -- the numbering plan is according to -- Recommendation E.163 and E.164. dataPartyNumber [3] IMPLICIT NumberDigits, -- not used, value reserved. telexPartyNumber [4] IMPLICIT NumberDigits, -- not used, value reserved. privatePartyNumber [5] IMPLICIT PrivatePartyNumber, nationalStandardPartyNumber [8] IMPLICIT NumberDigits} -- not used, value reserved.

PublicPartyNumber

::= SEQUENCE { publicTypeOfNumber PublicTypeOfNumber, publicNumberDigits NumberDigits}

PrivatePartyNumber ::= SEQUENCE { privateTypeOfNumber PrivateTypeOfNumber, privateNumberDigits NumberDigits} NumberDigits

::=

NumericString (SIZE(1..20))

PublicTypeOfNumber ::= ENUMERATED { unknown (0), -- if used number digits carry prefix indicating type -- of number according to national recommendations. internationalNumber (1), nationalNumber (2), networkSpecificNumber (3), -- not used, value reserved subscriberNumber (4), abbreviatedNumber (6)} -- valid only for called party number at the outgoing -- access, network substitutes appropriate number. PrivateTypeOfNumber ::= ENUMERATED { unknown (0), level2RegionalNumber (1), level1RegionalNumber (2), pISNSpecificNumber (3), localNumber (4), abbreviatedNumber (6)} PartySubaddress

::= CHOICE { userSpecifiedSubaddress UserSpecifiedSubaddress, -- not recommended. nSAPSubaddress NSAPSubaddress} -- according to Recommendation X.213.

UserSpecifiedSubaddress ::= SEQUENCE { subaddressInformation SubaddressInformation, oddCountIndicator BOOLEAN OPTIONAL} -- used when the coding of subaddress is BCD NSAPSubaddress

::= OCTET STRING (SIZE(1..20)) -- specified according to X.213. Some networks may -- limit the subaddress value to some other length -- e.g. 4 octets

- 79 -

T a b l e B . 1 - A d d r e s s i n g i n f o r m a t i o n d e f in it io n s ( s h e e t 3 o f 3 ) SubaddressInformation ::= OCTET STRING (SIZE(1..20)) -- coded according to user requirements. Some networks -- may limit the subaddress value to some other length -- e.g. 4 octets ScreeningIndicator

::= ENUMERATED { userProvidedNotScreened (0), -- number was provided by a remote user terminal -- equipment, and has been screened by a network that -- is not the local public or the local private -- network. userProvidedVerifiedAndPassed (1), -- number was provided by a remote user terminal -- equipment (or by a remote private network), and has -- been screened by the local public or the local -- private network. userProvidedVerifiedAndFailed (2), -- not used, value reserved. networkProvided (3)} -- number was provided by local public or local -- private network.

PresentationAllowedIndicator

::=

BOOLEAN

END -- of Addressing-Data-Elements-asn1-97

- 80 -

B.2

Notifications Table B.2 defines the ASN.1 NOTIFICATION class used for defining notifications that can be carried in the Notification indicator as defined in 11.3.4. It also defines the notification value pss1IeNotification, the use of which is described in 11.3.4. Table B.2 - NOTIFICATION class definition Notification-class-asn1-97 { iso( 1) standard( 0) pss1-generic-procedures( 11582) notification-class-asn1-97( 21) } DEFINITIONS ::= BEGIN IMPORTS PSS1InformationElement FROM PSS1-generic-parameters-definition-asn1-97 { iso( 1) standard( 0) pss1-generic-procedures( 11582) pss1-generic-parameters-asn1-97( 17)}; NOTIFICATION ::= CLASS { &ArgumentType OPTIONAL, &argumentTypeOptional BOOLEAN OPTIONAL, &notificationCode Code UNIQUE } WITH SYNTAX { [ARGUMENT &ArgumentType [OPTIONAL &argumentTypeOptional]] CODE &notificationCode } Code ::= CHOICE { local INTEGER, global OBJECT IDENTIFIER } -- the notification below is used to convey information elements used as notifications across a PISN pss1IeNotification NOTIFICATION ::= { ARGUMENT PSS1InformationElement CODE local: 2001 } END -- of Notification-class-asn1-97

- 81 -

B.3

PSS1InformationElement Table B.3 defines the ASN.1 type PSS1InformationElement, the use of which is described in 11.3.3.4. Table B.3 - PSS1 information element PSS1-generic-parameters-definition-asn1-97 { iso( 1) standard( 0) pss1-generic-procedures( 11582) pss1-generic-parameters-asn1-97( 17)} DEFINITIONS BEGIN

::=

PSS1InformationElement

::= [APPLICATION 0] IMPLICIT

END -- of PSS1 Generic parameters definition-asn1-97

OCTET STRING

- 82 -

- 83 -

Annex C ( in f o r ma tiv e )

Application of the functional protocol

C.1

Examples of the use of the functional protocol over the PISN This annex contains examples of the use and encoding of the functional protocol (as defined in clauses 6 to 9 of this Standard. It is intended as an example of the potential application or use of the protocol and is not intended to constrain the definition of particular supplementary services.

C.2

Call related supplementary services In the figures in this clause, the notation shown in figure C.1 is used when referring to messages between PINXs. Message type

ALERTING (Crc,

Call reference Value

FAC[or=End, De=End, Return result]) \__________________________________/ Contents of Facility IE Key: FAC = Facility information element Or = ‘sourceEntity’ in NFE (End=endPINX) De = ‘destinationEntity’ in NFE End = endPINX value of sourceEntity or destinationEntity in NFE (see 7.1.1) Any = anytypeOfPINX value of sourceEntity or destinationEntity in NFE (see 7.1.1) RetRes = return result APDU

F i g u r e C . 1 - N o t a t i o n f o r C a l l r e l a t e d s u p p le m e n t a r y s e r v i c e s e x a m p l e m e s s a g e f l o w s

C.2.1

Call Establishment

C.2.1.1 End to end Service request In this example, a service invocation is passed between the End PINXs involved in a call, during call establishment. The supplementary service uses, as an example, operation hypotheticalService as defined in module Hypothetical-service-operation in table F.4 in annex F, without any manufacturer specific extension.

- 84 -

SETUP (CRa, FAC[ Or=End, De=End, Invoke]) CALL PROC (CRa)

ALERTING (CRa, FAC[ Or=End, De=End, Return result])

SETUP (CRb, FAC[ Or=End, De=End, Invoke]) CALL PROC (CRb)

ALERTING (CRb, FAC[ Or=End, De=End, Return result])

SETUP (CRc, FAC[ Or=End, De=End, Invoke]) CALL PROC (CRc) ALERTING (CRc, FAC[ Or=End, De=End, Return result])

Figure C.2 - End to end service invocation on call setup NOTE Depending on the particular service, the result of processing the invocation may cause the call setup to fail in some circumstances. Figure C.2 shows the transport of the end to end service request and response during call setup. Figure C.3 shows the encoding of the Facility information element sent in the original SETUP message. It contains an invoke APDU with a single integer argument (hypotheticalParameter1) and the operation value is given by its object identifier: {

iso(1) standard(0) hypothetical-standard( 2222222) hypothetical-operation(10) }

This results in an object identifier of 6 octets in length, encoded in accordance with clause 8.19 of X.691. The invoke identifier chosen for this example was the arbitrary value ‘2’. This identifier is generated by the originator of the invoke APDU so that any response received via the same underlying association (in this case the Basic call) can be correlated with the originally sent invoke APDU. The encoding of the return result APDU (sent in the ALERTING message of figure C.2) in figure C.4 illustrates the use of the invoke identifier to perform this correlation.

- 85 -

Facility information element identifier length = 25 octets 1

protocol profile = networking extensions

context specific tag 10 (NFE) length = 6 octets context specific tag 0 (sourceEntity) length = 1 octet integer = 0 (endPINX) context specific tag 2 (destinationEntity) length = 1 octet integer = 0 (endPINX)

context specific tag 1 (invoke APDU) length = 14 octets universal tag 2 (integer, invoke id type) length = 1 octet integer = 2 (arbitrary value) universal tag 6 (object identifier) length = 6 octets 0

contents = 0x28

contents = 0x01

contents = 0x07

contents = 0x51

contents = 0x0e

contents = 0x0a universal tag 2 (integer, argument) length = 1 octet integer = 0 (hypothetical argument #1)

F ig u r e C . 3 - En c o d in g o f in v o k e A P D U f r o m f ig u r e C . 2

- 86 -

Facility information element identifier length = 32 octets 1

protocol profile = networking extensions

context specific tag 2 (ret res. APDU) length = 21 octets universal tag 2 (integer, invoke id type) length = 1 octet integer = 2 (arbitrary value) universal tag 16 (sequence, result) length = 16 octets universal tag 6 (object identifier) length = 6 octets 0

contents = 0x28

contents = 0x01

contents = 0x07

contents = 0x51

contents = 0x0e

contents = 0x0a universal tag 16 (sequence, result) length = 6 octets context specific tag 0 (element 1) length = 1 octet integer = integer value context specific tag 1 (element 2) length = 1 octet integer = integer value

F ig u r e C . 4 - En c o d in g o f r e t u r n r e s u lt A P D U f r o m A LER TI N G m e s s a g e o f f ig u r e C . 2

- 87 -

C.2.1.2 Link Service Request Figure C.5 shows an example of a link by link service request and response during call setup. The service request is between two transit PINXs and does not contain a Network Facility Extension octet group.

SETUP (CRa) CALL PROC (CRa)

ALERTING (CRa)

SETUP (CRb, FAC[ Invoke]) CALL PROC (CRb)

ALERTING (CRb, FAC[

SETUP (CRc) CALL PROC (CRc) ALERTING (CRc)

Return result])

Figure C.5 - Link service request on call setup

C.2.2

Call Clearing

C.2.2.1 End to End Request Figure C.6 shows a call being cleared across the network, with an end to end service request. This request is a Class 5 ROSE operation which requires no response.

DISC (CRa, FAC[ Or=End, De=End, Invoke]) RELEASE (CRa) RELEASE COMPLETE(CRa)

DISC (CRb, FAC[ Or=End, De=End, Invoke]) RELEASE (CRb) RELEASE COMPLETE(CRb)

DISC (CRc, FAC[ Or=End, De=End, Invoke]) RELEASE (CRc) RELEASE COMPLETE(CRc)

Figure C.6 - End to end service request on call clearing

- 88 -

C.2.2.2 Link Service Request Figure C.7 shows a call being cleared across the network, with a link service request between two Transit PINXs.

DISC (CRa) RELEASE (CRa) RELEASE COMPLETE(CRa)

DISC (CRb, FAC[Invoke]) RELEASE (CRb, FAC [Return result]) RELEASE COMPLETE(CRb)

DISC (CRc) RELEASE (CRc) RELEASE COMPLETE(CRc)

Figure C.7 - link service request on call clearing

C.2.3

Call Active

C.2.3.1 End to End Request Figure C.8 shows an end to end service request and response during the active state of a call.

Active Call FACILITY (CRa, FAC[ Or=End, De=End, Invoke])

FACILITY (CRa, FAC[ Or=End, De=End, Return result])

FACILITY (CRb, FAC[ Or=End, De=End, Invoke])

FACILITY (CRb, FAC[ Or=End, De=End, Return result])

FACILITY (CRc, FAC[ Or=End, De=End, Invoke]) FACILITY (CRc, FAC[ Or=End, De=End, Return result])

Figure C.8 - End to End service request during active call C.2.3.2 Link Service Request Figure C.9 shows a link by link service request and response during the active state of a call.

Active Call FACILITY (CRb, FAC[ Invoke])

FACILITY (CRb, FAC[Return result])

Figure C.9 - Link by Link service request during active call

- 89 -

C.3

Call independent supplementary services In this clause, the notation shown in figures C.10 and C.11 is used when referring to messages between PINXs.

Message type

Dummy Call reference Value

Originating Node

Contents of Facility IE

Destination Node

FACILITY (CRd, Orig=A, Dest=B, FAC[ DCont{ODi=x, DDi=y, Return result}]) DSE APDU

originationDialogId

destinationDialogId

ROSE APDU

Figure C.10 - Notation for Connectionless Call independent message sequence examples

Message type

Call reference Value

Originating Node Destination Node

FACILITY (CRd, Calling=A, Called=B, FAC[Return result]) Contents of Facility IE (NFE not shown for clarity, but similar contents to call related case)

ROSE APDU

Figure C.11 - Notation for Connection oriented Call independent message sequence examples The abbreviations DCont, DBeg and DEnd refer to the DialogContinuePDU, DialogBeginPDU and DialogEndPDU respectively, defined in clause 8.

- 90 -

C.3.1

Connectionless Transport Figure C.12 shows service requests which are passed between two PINXs

Node A

Node B

FACILITY (CRd, Orig=A, Dest=B FAC[DBeg{ODi=x, Invoke}])

FACILITY (CRd, Orig=B, Dest=A FAC[DCont{ODi=y, DDi=x, RetRes}])

FACILITY (CRd, Orig=A, Dest=B FAC[DCont{ODi=x, Ddi=y, Invoke}])

FACILITY (CRd, Orig=B, Dest=A FAC[DEnd{DDi=x, Invoke}])

FACILITY (CRd, Orig=A, Dest=B FAC[DBeg{ODi=x, Invoke}])

FACILITY (CRd, Orig=B, Dest=A FAC[DCont{ODi=y, DDi=x, RetRes}])

FACILITY (CRd, Orig=A, Dest=B FAC[DCont{ODi=x, Ddi=y, Invoke}])

FACILITY (CRd, Orig=B, Dest=A FAC[DEnd{DDi=x, Invoke}])

FACILITY (CRd, Orig=A, Dest=B FAC[DBeg{ODi=x, Invoke}]) FACILITY (CRd, Orig=B, Dest=A FAC[DCont{ODi=y, DDi=x, RetRes}])

FACILITY (CRd, Orig=A, Dest=B FAC[DCont{ODi=x, Ddi=y, Invoke}])

FACILITY (CRd, Orig=B, Dest=A FAC[DEnd{DDi=x, Invoke}])

Figure C.12 - Connectionless end to end service

C.3.2

Connection oriented Transport Figure C.13 shows the establishment, active and clearing phases of a Call independent signalling connection between two PINXs

Node A

Node B

SETUP (CRa, Orig=A, Dest=B, FAC[Invoke]) CALL PROC (CRa)

CONNECT(CRa, Orig=B, Dest=A FAC[RetRes]) CONNECT ACKNOWLEDGE (CRa) FACILITY (Cra, FAC[Invoke])

RELEASE(CRa, FAC[RetRes]) RELEASE COMPLETE (CRa)

SETUP(CRb, Orig=A, Dest=B, FAC[Invoke]) CALL PROC (CRb)

CONNECT(CRb, Orig=B, Dest=A FAC[RetRes]) CONNECT ACKNOWLEDGE (CRb)

FACILITY (CRb, FAC[Invoke])

RELEASE(CRb, FAC[RetRes]) RELEASE COMPLETE (CRb)

SETUP(CRc, Orig=A, Dest=B, FAC[Invoke]) CALL PROC (CRc) CONNECT (CRc, Orig=B, Dest=A FAC[RetRes]) CONNECT ACKNOWLEDGE (CRc)

FACILITY (CRc, FAC[Invoke]) RELEASE (CRc, FAC[RetRes]) RELEASE COMPLETE (CRc)

Figure C.13 - Connection oriented signalling connection

- 91 -

Annex D (deleted)

Remote operations protocol and application association control

This annex was deleted. Information about ROSE APDU transport via PSS1 Generic Functional Protocol can be found in section 8.2 of this Standard.

- 92 -

- 93 -

Annex E (deleted)

Formal ROSE Definitions

The formal rose definitions can be found in ITU-T Rec. X.880.

- 94 -

- 95 -

Annex F ( in f o r ma tiv e )

Examples of the use of Manufacturer specific information

F.1

Manufacturer Specific Object Identifiers in Operation Values As defined in 9.1, manufacturers who wish to provide manufacturer specific supplementary services in a standardised manner should use unique operation values, constructed using manufacturer specific object identifiers. Manufacturer specific object identifiers may be constructed in the following way. Manufacturers requiring an assigned identification may apply to a “Sponsoring and Issuing organisation” according to ISO/IEC 6523-1/2 and be assigned an organisation identifier. The manufacturer should then use that organisation identifier in an object identifier (as the root of the manufacturer specific service operation value) according to the structure defined by the issuing organisation. One example of a regional Sponsoring and issuing organisation is ECMA, which has been assigned an International Code Designator (ICD). ECMA will assign values to ECMA member companies in its object identifier root. The use of ECMA issued organisation identifiers in object identifiers is as shown in table F.1. PINXs conforming to this Standard can make use of an organisation identifier issued by any “sponsoring and issuing organisation” (e.g. ECMA or a National Standards Body). Table F.1 - Structure of ECMA Object Identifier level 1:

iso( 1)

level 2:

identified-organization( 3)

level 3:

icd-ecma( 0012)

level 4:

a) b) c) d)

standard( 0) technical-report( 1) member-company( 2) private-ISDN-signalling-domain( 9)

level 5:

for c) of level 4: organisation identifier assigned by ECMA

level 6:

this level and others below it are used to suit the purpose of the organisation assigned the value at Level 5.

Thus, according to table F.1, the ECMA object identifier for a company with the assigned organisation code ‘1999’ (all organisation codes issued by ECMA have 4 digits of which the first is always ‘1’), may be structured as shown in table F.2. The contents of level 6 is manufacturer specific and may identify a company specific operation value or may not exist at all. In this example, level 6 provides a manufacturer specific operation value.

- 96 -

T a b l e F . 2 - E C M A O b j e c t i d e n t i f i e r f o r h y p o t he t i c a l m a n u f a c t u r e r s p e c i f i c s e r v i c e o p e r a t i o n Object identifier for hypothetical manufacturer specific service operation value: HypotheticalManufacturerSpecificSupplementaryService ::= { iso( 1) identified-organization( 3) icd-ecma( 0012) member-company( 2) hypothetical-manufacturer( 1999) hypothetical-manufacturer-service( 1) } In pure numeric notation, this would be: { 1 3 0012 2 1999 1 } (This shall be encoded as described in ITU-T recommendation X.690)

This object identifier value would then be used in the definition of the manufacturer specific operation (internally to that manufacturer). An example of a manufacturer specific operation definition is shown in table F.3.

F.2

Manufacturer specific extensions to standardised supplementary services An example of the use of the element of type Extension (defined in 9.2) in a standardised supplementary services definition is given in table F.4 for a hypothetical ISO standard number '2222222'. In the operation definitions for standardised supplementary services, the following constructs are used: – where the standardised parameter (argument of invoke APDU, result of return result APDU) is a single value (e.g. INTEGER), the Standard can instead specify a SEQUENCE containing a CHOICE of an element of type Extension or a SEQUENCE of elements of type Extension. Thus, the parameter would then become: Parameter1 ::= CHOICE { integerName INTEGER, sequenceName SEQUENCE { integerNameInSeq INTEGER, ext CHOICE { single [1] IMPLICIT Extension{{ExampleExtensionSet}}, multiple [2] IMPLICIT SEQUENCE OF Extension{{ExampleExtensionSet}} } } } ExampleExtensionSet EXTENSION ::= {...}

- 97 -

– where the parameter is a SEQUENCE type, this would be replaced by a SEQUENCE containing a CHOICE of an element of type Extension or a SEQUENCE of elements of type Extension. Thus, the parameter would then become: Parameter2 ::= SEQUENCE { listName List-of-Standard-parameter-types, ext CHOICE { single [1] IMPLICIT Extension{{ExampleExtensionSet}}, multiple [2] IMPLICIT SEQUENCE OF Extension{{ExampleExtensionSet}} } OPTIONAL } ExampleExtensionSet EXTENSION ::= {...} – where there is no defined parameter, a parameter should be added as shown below: Parameter ::= CHOICE { null NULL, extension [1] IMPLICIT Extension{{ExampleExtensionSet}}, extensionSeq [2] IMPLICIT SEQUENCE OF Extension{{ExampleExtensionSet}} } ExampleExtensionSet EXTENSION ::= {...} NOTE The use of implicit tagging within the CHOICE construct containing elements of type Extension should be used consistent with the context specific tags used in the remainder of the SEQUENCE in which it is contained. In this way, manufacturer specific additions to standardised supplementary services may be included in a generic and backwards compatible manner. The manufacturer object identifier (shown in table F.3 below) should be encoded in the same manner as described in 9.1. The use of a SEQUENCE of elements of type Extension allows the coexistence of a number of different extensions to the standardised supplementary service. It also allows for future versions of the standardised service to be backwards compatible with, and to coexist with, manufacturer-specific additions to the original supplementary service.

- 98 -

Table F.3 - Example of manufacturer specific operation Hypothetical-service-operation-asn1-97 { iso( 1) identified-organization( 3) icd-ecma( 12) member-company( 2) hypothetical-manufacturer( 1999) hypothetical-service-offering-asn1-97 ( 9999) } DEFINITIONS BEGIN IMPORTS

::= OPERATION FROM Remote-Operations-Information-Objects { joint-iso-itu-t remote-operations(4) informationObjects(5) version1(0) };

MSI-HypotheticalService-Operations OPERATION ::= { hypotheticalService } hypotheticalService OPERATION ::= { ARGUMENT HypotheticalArgument RESULT HypotheticalResult ALWAYS RESPONDS FALSE CODE global: { iso( 1) identified-organization( 3) icd-ecma( 12) member-company( 2) hypothetical-manufacturer( 1999) hypothetical-manufacturer-service( 1) } } HypotheticalArgument

::= INTEGER { hypotheticalParameter1( 0), hypotheticalParameter2( 1) }

HypotheticalResult

::= INTEGER { hypotheticalResult1( 0), hypotheticalResult2( 1) }

END

-- of hypothetical-manufacturer-service-operation

- 99 -

Table F.4 - Example definition of standardised operation with elements of type extension Hypothetical-service-operation-asn1-97 { iso standard hypothetical-standard( 2222222) first-and-only-module-asn1-97 ( 0) } DEFINITIONS BEGIN IMPORTS

::=

OPERATION FROM Remote-Operations-Information-Objects { joint-iso-itu-t remote-operations(4) informationObjects(5) version1(0) }; EXTENSION, Extension{} FROM Manufacturer-specific-service-extension-class-asn1-97 { iso standard pss1-generic-procedures( 11582) msi-class-asn1-97 ( 11) };

MSI-HypotheticalService-Operations OPERATION ::= { hypotheticalService } hypotheticalService

}

OPERATION ::= { ARGUMENT CHOICE { normalArgument NormalIntegerArgument, sequenceName SEQUENCE { normalArgument NormalIntegerArgument, extension CHOICE { single [2] IMPLICIT Extension{{ExampleExtensionSet}}, multiple [3] IMPLICIT SEQUENCE OF Extension{{ExampleExtensionSet}} } OPTIONAL } } RESULT SEQUENCE { list ListOfNormalResultSequenceElements, extension CHOICE { single [2] IMPLICIT Extension{{ExampleExtensionSet}}, multiple [3] IMPLICIT SEQUENCE OF Extension{{ExampleExtensionSet}} } OPTIONAL } ALWAYS RESPONDS FALSE CODE global: { iso standard hypothetical-standard( 2222222) hypothetical-operation( 10) }

NormalIntegerArgument ::= INTEGER { hypotheticalParameter1( 0), hypotheticalParameter2( 1) } ListOfNormalResultSequenceElements ::= SEQUENCE { normalResultSequenceElement1 [0] IMPLICIT INTEGER, normalResultSequenceElement2 [1] IMPLICIT INTEGER } ExampleExtentionSet END

EXTENSION ::= {...}

-- of hypothetical-service-operation-asn1-97

- 100 -

T a b l e F . 5 - E x a m p l e d e f i n i t io n o f m a n u f a c t u r e r s p e c i f i c e x t e n s i o n ( s h e e t 1 o f 2 ) Hypothetical-service-operation-asn1-97 { iso standard hypothetical-standard( 2222222) first-and-only-module-asn1-97 ( 0) } DEFINITIONS BEGIN IMPORTS

::= OPERATION FROM Remote-Operations-Information-Objects { joint-iso-itu-t remote-operations(4) informationObjects(5) version1(0) }; EXTENSION, Extension{} FROM Manufacturer-specific-service-extension-class-asn1-97 { iso standard pss1-generic-procedures( 11582) msi-class-asn1-97 ( 11)};

MSI-HypotheticalService-Operations OPERATION ::= { hypotheticalService } hypotheticalService

global: { iso standard hypothetical-standard( 2222222) hypothetical-operation( 10) }

EXTENSION ::= { ARGUMENT SEQUENCE { element1 INTEGER, element2 OCTET STRING} IDENTIFIER { iso identified-organization icd-ecma member-company hypothetical-manufacturer hypothetical-extension-number1 (1) } }

- 101 -

T a b l e F . 5 - E x a m p l e d e f i n i t io n o f m a n u f a c t u r e r s p e c i f i c e x t e n s i o n ( s h e e t 2 o f 2 ) msiExtension2

EXTENSION ::= { ARGUMENT INTEGER IDENTIFIER { iso identified-organization icd-ecma member-company hypothetical-manufacturer hypothetical-extension-number2 (2) } }

ExampleExtensionSet END

EXTENSION ::= { msiExtension1 | msiExtension2 }

-- of hypothetical-service-operation-asn1-97

- 102 -

- 103 -

Annex G ( in f o r ma tiv e )

Problem code definitions

Table G.1 - Problem Code Definitions General Problem: —

unrecognisedPDU

signifies that the type of the APDU as evidenced by its Type identifier, is not defined in clause 11.

—

mistypedPDU

signifies that the structure of the APDU does not conform to that defined in clause 11.

—

badlyStructuredPDU

signifies that the structure of the APDU does not conform to the Standard notation and encoding rules, defined in ITU-T Recommendations X.680 and X.690.

Invoke problem: —

duplicatedInvocation

signifies that the Invoked-identifier parameter violates the assignment rules of ITU-T Recommendation X.880.

—

unrecognisedOperation

signifies that the type of the operation is not one of those supported.

—

mistypedArgument

signifies that the type of the operation argument supplied is not expected.

—

resourceLimitation

the performing PINX is not able to perform the invoked operation due to resource limitation.

—

initiatorReleasing

the association initiator is not willing to perform the invoked operation because it is about to attempt to release the application association.

—

unrecognisedLinkedId

signifies that there is no operation in progress with an Invoke identifier equal to the specified Linked identifier.

—

linkedResponseUnexpected signifies that the invoked operation referred to by the Linked identifier is not a parent operation.

—

unexpectedChildOperation signifies that the invoked child operation is not one that the invoked parent operation referred to by the Linked identifier allows.

Return result problem: —

unrecognisedInvocation

signifies that no operation with the specified invoke identifier is in progress.

—

resultResponseUnexpected signifies that the invoked operation does not report a result.

—

mistypedResult

signifies that the type of the Result parameter supplied is not expected.

Return error problem: —

unrecognisedInvocation

signifies that no operation with the specified invoke identifier is in progress.

—

errorResponseUnexpected signifies that the invoked operation does not report failure.

—

unrecognisedError

signifies that the reported error is not one expected.

—

unexpectedError

signifies that the reported error is not one that the invoked operation may report.

—

mistypedParameter

signifies that the type of the error parameter supplied is not one that is expected.

- 104 -

- 105 -

Annex H (deleted)

Bibliography

ITU-T Rec. X.208 Specification of Abstract Syntax Notation One (ASN.1) (Blue Book) (1988) ITU-T Rec. X.209 Encoding Rules for Abstract Syntax Notation One (ASN.1) (Blue Book) (1988) ITU-T Rec. X.219 Remote Operations Model, Notation and Service (Blue Book) (1988) ITU-T Rec. X.229 Remote Operations: Protocol Specification (1993)

- 106 -

- 107 -

Annex I ( in f o r ma tiv e )

Object identifiers defined in ECMA-165

This annex lists the object identifier values assigned in this Standard and data types, values, classes and macros that are exported from any modules identified by those values. All the object identifiers in this Standard are defined using the ISO object identifier tree. This means that each object identifier value is assigned in the tree: gfObjectIdTree ::= iso( 1) standard( 0) pss1-generic-procedures( 11582) Table I.1 lists the module number values and the data types, values, classes and macros which are exported from these modules. Ta b le I . 1 - A S N . 1 M o d u le O b j e c t id e n t if ie r s u s e d in EC M A - 1 6 5 Object Identifier

Reference

Notes

{ gfObjectIdTree msi-definition( 0) }

Table K.1, on page 115

Exports: Extension, EXTENSION

{ gfObjectIdTree association-control-apdus( 1) }

Table K.7, on page 120

Exports: AcseAPDU

{ gfObjectIdTree network-facility-extension( 2) }

Table K.3, on page 116

Exports: NetworkFacilityExtension

{ gfObjectIdTree interpretation-apdu( 3) }

Table K.4, on page 117

Exports: InterpretationApdu

{ gfObjectIdTree dialogue-service-pdus( 4) }

Table K.5, on page 118

Exports: DseAPDU

{ gfObjectIdTree remote-operations-apdus( 5) }

Table K.6, on page 119

Exports: RoseAPDU

{ gfObjectIdTree pss1-generic-parameters( 6) }

Table K.11, on page 126

Exports: PSS1InformationElement

{ gfObjectIdTree notification-data-structure( 7) }

Table K.8, on page 121

Exports: NotificationDataStructure

{ gfObjectIdTree network-protocol-profile-definition( 8) }

Table K.2, on page 116

Exports: NetworkProtocolProfile

{ gfObjectIdTree addressing-data-elements( 9) }

Table K.9, on page 122

Exports: PresentedAddressScreened, PresentedAddressUnscreened, PresentedNumberScreened, PresentedNumberUnscreened, Address, PartyNumber, PartySubaddress, ScreeningIndicator, PresentationAllowedIndicator

{ gfObjectIdTree notification-macro( 10) }

Table K.10, on page 125

Exports: NOTIFICATION, pss1IeNotification

{ gfObjectIdTree msi-class-asn1-97 ( 11) }

Table 14, on page 48

Exports : everything

{ gfObjectIdTree association-control-apdus-asn1-97( 12) }

Table 35, on page 63

Exports : everything

- 108 -

{ gfObjectIdTree network-facility-extension-asn1-97 ( 13) }

Table 31, on page 56

Exports : everything

{ gfObjectIdTree interpretation-apdu-asn1-97( 14) }

Table 32, on page 57

Exports : everything

{ gfObjectIdTree dialogue-service-pdus-asn1-97( 15) }

Table 33, on page 58

Exports : everything

{ gfObjectIdTree pss1-service-apdus-asn1-97( 16) }

Table 34, on page 60

Exports : everything

{ gfObjectIdTree pss1-generic-parameters-asn1-97( 17) }

Table B.3, on page 81

Exports : everything

{ gfObjectIdTree notification-data-structure-asn1-97( 18) }

Table 37, on page 65

Exports : everything

{ gfObjectIdTree network-protocol-profile-definition-asn1-97( Table 29, on page 56 19) }

Exports : everything

{ gfObjectIdTree addressing-data-elements-asn1-97( 20) }

Table B.1, on page 77

Exports : everything

{ gfObjectIdTree notification-class-asn1-97( 21) }

Table B.2, on page 80

Exports : everything

- 109 -

Annex J ( in f o r ma tiv e )

“Recipe” for migration of X.208 / X.209 based QSIG ASN.1 modules to X.680 / X.690 ASN.1

This annex gives a short introduction of how existing ITU-T Rec. X.208 / X.209 based Supplementary Service and Additional Network Feature ASN.1 modules have to be changed to gain conformance with ITU-T Rec. X.680 / X.690.

J.1

Module Header All ECMA-165 and PSS1 SS/ANF modules which are migrated to ITU-T Rec. X.680 / X.690 ASN.1 have get a new module number and name to all unambiguous references for IMPORT statements. Table J.1 shows an example. Ta b le J . 1 – M o d u le H e a d e r X.208 / X.209 ASN.1 code

X.680 / X.690 ASN.1 code

Example-Service-Name-Operations { iso ( 1) standard ( 0) pss1-name (xxx) example-service-name-operations( 0) }

Example-Service-Name-Operations-asn1-97 { iso ( 1) standard ( 0) pss1-name (xxx) example-service-name-operations-asn1-97( 1) }

DEFINITIONS ::=

-- This might alternatively be defined as -- DEFINITIONS EXPLICIT TAGS ::=

-- If defined as DEFINITIONS EXPLICIT TAGS ::= -- this shall not be changed.

BEGIN

- 110 -

J.2

IMPORTS and EXPORTS Table J.2 shows how the IMPORTS and EXPORTS sections of a ASN.1 module have to be changed to gain conformance with ITU-T Rec. X.680 / X.690. When importing from another PSS1 module (e.g. from ECMA-165 or any PSS1 SS/ANF) only the migrated version of the affected module shall be used, i.e. the IMPORT statement for that module has to be changed to the new module reference which is described in section J.1. Table J.2 only shows some general examples for those modules from which structures are imported most of the time. If definitions from other PSS1 modules are needed it is necessary to look up the new reference in the related ECMA Standard. If the module, from which a definition shall be imported, is not migrated to X.680 / X.690 ASN.1 then it first has to be migrated. For modules which are not defined within the PSS1 standards set it is necessary to use references to X.680 / X.680 conformant modules. Import statements to e.g. the General-Error-List (ITU-T Recommendation Q.950) shall be changed. Table J.2 – IMPORTS and EXPORTS Statements X.208 / X.209 ASN.1 code

X.680 / X.690 ASN.1 code

IMPORTS

OPERATION, ERROR FROM Remote-Operation-Notation { joint-iso-ccitt( 2) remote-operations( 4) notation( 0) }

OPERATION, ERROR FROM Remote-Operations-Information-Objects {joint-iso-itu-t remote-operations(4) informationObjects(5) version1(0)}

Extension FROM Manufacturer-specific-serviceextension-definition { iso standard pss1-generic-procedures (11582) msi-definition ( 0)}

EXTENSION, Extension{} FROM Manufacturer-specific-serviceextension-class-asn1-97 { iso standard pss1-generic-procedures (11582) msi-class-asn1-97 (11) } -- please note that there must not be a blank character -- between the word Extension and the following {}.

PartyNumber FROM Addressing-Data-Elements { iso standard pss1-generic-procedures (11582) addressing-data-elements ( 9)}

PartyNumber FROM Addressing-Data-Elements-asn1-97 { iso standard pss1-generic-procedures (11582) addressing-data-elements-asn1-97 ( 20)}

Name FROM Name-Operations { iso standard pss1-name (13868) name-operations ( 0)}

Name FROM Name-Operations-asn1-97 { iso standard pss1-name (13868) name-operations-asn1-97 ( 1)}

- 111 -

J.3

NOTIFICATION FROM Notification-Data-Structure {iso(1) standard(0)pss1-generic-procedures(11582) notification-data-structure(7)};

NOTIFICATION FROM Notification-Data-Structure-asn1-97 {iso(1) standard(0)pss1-generic-procedures(11582) notification-data-structure-asn1-97(18)};

EXPORTS Example1, Example2;

-- EXPORTS everything (Statement not needed)

Usage of Operations In the examples given in Table J.3 please note the change from capital to small letter in the name of operations. Ta b le J . 3 – O P ER A TI O N X.208 / X.209 ASN.1 code

X.680 / X.690 ASN.1 code -- this statement is new and should be included in new -- modules following the header ExampleModule-Operations OPERATION ::= { example1 | example2 | example3}

Example1 ::= OPERATION ARGUMENT ExampleArg RESULT ExampleRes ERRORS { error1, unspecified} example1

Example1

::=

localValue 2002

Example3 ::= OPERATION ARGUMENT ExampleArg ERRORS { error1, unspecified} example1

Example1

::=

OPERATION ::= { ARGUMENT ExampleArg RESULT ExampleRes ERRORS { error1 | unspecified} CODE local: 2001}

localValue 2001

Example2 ::= OPERATION ARGUMENT ExampleArg example2 Example2 ::=

example1

localValue 2003

example2 OPERATION ::= { ARGUMENT ExampleArg RETURN RESULT FALSE ALWAYS RESPONDS FALSE CODE local: 2002} example3

OPERATION ::= { ARGUMENT ExampleArg RETURN RESULT FALSE ERRORS { error1 | unspecified} ALWAYS RESPONDS FALSE CODE local: 2003}

- 112 -

J.4

Definition of ERRORS Ta b le J . 4 – ER R O R X.208 / X.209 ASN.1 code error1

ERROR ::= localValue 3001

Unspecified ERROR PARAMETER ExampleExt1

X.680 / X.690 ASN.1 code error1 ERROR ::= { CODE local: 3001} unspecified ERROR ::= { PARAMETER ExampleExt1 CODE local: 3003}

unspecified Unspecified ::= localValue 3003 Unspecified2 Extension

ERROR PARAMETER

unspecified2 Unspecified2

J.5

unspecified2

::= localValue 3003

ERROR ::= { PARAMETER Extension{{ExampleExtSet}} CODE local: 3003}

Usage of Extensions Table J.5 - Extensions X.208 / X.209 ASN.1 code ExampleArg ::=

SEQUENCE { something INTEGER, extension ExampleExt1}

ExampleExt1 ::= CHOICE { single [1] IMPLICIT Extension, multiple [2] IMPLICIT SEQUENCE OF Extension}

X.680 / X.690 ASN.1 code ExampleArg ::= SEQUENCE { something INTEGER, extension ExampleExt1} ExampleExt1 ::= CHOICE { single [1] IMPLICIT Extension{{ExampleExtSet}}, multiple [2] IMPLICIT SEQUENCE OF Extension{{ExampleExtSet}} } ExampleExtSet EXTENSION ::= {...}

- 113 -

J.6

Usage of Notification Table J.6 - Notifications X.208 / X.209 ASN.1 code

X.680 / X.690 ASN.1 code -- this statement is new and should be included -- in new modules following the header ExampleNotificationSet NOTIFICATION ::= { exampleNotification1 }

ExampleNotification1 ::= NOTIFICATION ARGUMENT NULL exampleNotification1 ExampleNotification1 ::= localValue 4001

J.7

exampleNotification1 NOTIFICATION ::= { ARGUMENT NULL CODE local: 4001 }

Element Names In many cases in already existing modules elements of data structures like SEQUENCE or CHOICE were defined by just indicating the type-name of the element. This is not longer allowed in X.680 / X.690 ASN.1. Table J.7 – Element Names X.208 / X.209 ASN.1 code

X.680 / X.690 ASN.1 code

ExampleRes ::=

SEQUENCE { INTEGER, ExampleExt2}}

ExampleRes ::= SEQUENCE { something INTEGER, extension ExampleExt2}

ExampleExt2 ::=

CHOICE { [0] NULL [1] IMPLICIT Extension, [2] IMPLICIT SEQUENCE OF Extension}

ExampleExt2 ::= CHOICE { null [0] NULL, single [1] IMPLICIT Extension{{ExampleExtSet}}, multiple [2] IMPLICIT SEQUENCE OF Extension{{ExampleExtSet}} }

J.8

END Statement The END statement shall indicate the new module name as a comment. Table J.8 – END Statement X.208 / X.209 ASN.1 code END

X.680 / X.690 ASN.1 code END -- of Example-Service-Name-Operations-asn1-97

- 114 -

- 115 -

Annex K ( in f o r ma tiv e )

ASN.1 definitions according to ITU-T Recs. X.208 / X.209

This annex lists all ASN.1 modules as they were defined in the third edition of ECMA-165, i.e. based on ITU-T Recommendations X.208 / X.209, which are expected to be withdrawn. Starting with the fourth edition the ASN.1 modules within ECMA-165 comply with ITU-T Recommendations X.680 / X.690. Please note that regardless of which of the modules is used as a base of a QSIG implementation, the encoded hex-string will stay identical. The formal rose definitions for the modules listed in this annex can be found in ITU-T Rec. X.219. NOTE The modules as defined in annex F are not listed in here, as the changes applied to them due to the migration to ITUT Recommendations X.680 / X.690 can also be applied to the previously defined modules without changing their functionality when used with ITU-T Recommendations X.208 / X.209. Table K.1 - Manufacturer specific extension mechanism A S N . 1 d e f in it io n c o n f o r m in g t o I TU - T R e c s . X . 2 0 8 / X . 2 0 9 Manufacturer-specific-service-extension-definition { iso( 1) standard( 0) pss1-generic-procedures( 11582) msi-definition( 0) } BEGIN DEFINITIONS

::=

BEGIN EXPORTS

Extension, EXTENSION;

EXTENSION MACRO TYPE NOTATION VALUE NOTATION Argument NamedType END -- of EXTENSION macro

::= ::= Argument ::= Value (VALUE(OBJECT IDENTIFIER)) ::= "Argument" NamedType ::= identifier type|type

Extension

END

::=

SEQUENCE { manufacturer ANY DEFINED BY }

EXTENSION, manufacturer

-- of Manufacturer-specific-service-extension-definition

- 116 -

Ta b le K . 2 - N e t wo r k P r o t o c o l P r o f ile A S N . 1 d e f in it io n c o n f o r m in g t o I TU - T R e c s . X . 2 0 8 / X . 2 0 9 Network-Protocol-Profile-definition { iso( 1) standard( 0) pss1-generic-procedures( 11582) network-protocol-profile-definition( 8) } DEFINITIONS BEGIN EXPORTS

::= NetworkProtocolProfile;

NetworkProtocolProfile

::=

[18] IMPLICIT INTEGER { acse( 19), dse( 32) } (0..254)

END -- of Network Protocol Profile definition

Table K.3 - Network Facility Extension A S N . 1 d e f in it io n c o n f o r m in g t o I TU - T R e c s . X . 2 0 8 / X . 2 0 9 Network-Facility-Extension { iso( 1) standard( 0) pss1-generic-procedures( 11582) network-facility-extension( 2) } DEFINITIONS ::= BEGIN EXPORTS IMPORTS

NetworkFacilityExtension; PartyNumber FROM Addressing-Data-Elements { iso( 1) standard( 0) pss1-generic-procedures( 11582) addressing-data-elements( 9) };

ENUMERATED { endPINX( 0), anyTypeOfPINX( 1) }

AddressInformation ::= END

PartyNumber

-- of Network Facility Extension

OPTIONAL, OPTIONAL

- 117 -

Table K.4 - Interpretation APDU A S N . 1 d e f in it io n c o n f o r m in g t o I TU - T R e c s . X . 2 0 8 / X . 2 0 9 Interpretation-Apdu { iso( 1) standard( 0) pss1-generic-procedures( 11582) interpretation-apdu( 3) } DEFINITIONS BEGIN EXPORTS

::= InterpretationApdu;

InterpretationApdu ::= [11] IMPLICIT ENUMERATED { discardAnyUnrecognisedInvokePdu( 0), clearCallIfAnyInvokePduNotRecognised( 1), -- this value also applies to Call independent signalling connections -- see clause 8.1.2 rejectAnyUnrecognisedInvokePdu( 2) -- this coding is implied by the absence of an -- interpretation APDU. } END

-- of Interpretation-Apdu

- 118 -

Table K.5 – Dialog Servcice PDUs A S N . 1 d e f in it io n c o n f o r m in g t o I TU - T R e c s . X . 2 0 8 / X . 2 0 9 Dialog-Service-Pdus {iso( 1) standard( 0) pss1-generic-procedures( 11582) dialog-service-pdus( 4) } DEFINITIONS ::= BEGIN EXPORTS DseAPDU; IMPORTS RoseAPDU FROM Remote-Operations-Apdus { iso( 1) standard( 0) pss1-generic-procedures( 11582) remote-operations-apdus( 5) } AcseAPDU FROM Association-Control-Apdus { iso( 1) standard( 0) pss1-generic-procedures( 11582) association-control-apdus( 1) } Extension FROM Manufacturer-specific-service-extension-definition { iso( 1) standard( 0) pss1-generic-procedures( 11582) msi-definition( 0) }; DseAPDU ::=

DialogBeginPDU

DialogEndPDU

CHOICE { begin end continue abort

OPTIONAL }

::= SEQUENCE { DestinationDialogId, RemoteOperationsPortion

OPTIONAL

}

OPTIONAL

}

::= SEQUENCE { OriginationDialogId, DestinationDialogId, RemoteOperationsPortion

::= SEQUENCE { DestinationDialogId, CHOICE { P-AbortCause, UserAbortInformation

OriginationDialogId

::= [0] IMPLICIT OCTET STRING SIZE(0..8)

DestinationDialogId

::= [1] IMPLICIT OCTET STRING SIZE(0..8)

P-AbortCause

}

::= SEQUENCE { OriginationDialogId, RemoteOperationsPortion

DialogContinuePDU

DialogAbortPDU

[12] IMPLICIT DialogBeginPDU, [14] IMPLICIT DialogEndPDU, [15] IMPLICIT DialogContinuePDU, [17] IMPLICIT DialogAbortPDU

::= [2] IMPLICIT INTEGER { unrecognisedDseApdu( 0), unrecognisedDialogId( 1), badlyFormattedDseApdu( 2), incorrectDseApdu( 3), resourceLimitation( 4)

} (0..255)

UserAbortInformation ::= [3] IMPLICIT Extension RemoteOperationsPortion ::= [4] IMPLICIT SEQUENCE OF CHOICE { [17] RoseAPDU, [19] AcseAPDU END

-- of Dialog-Service-Pdus

}

- 119 -

Table K.6 - ROSE APDUs A S N . 1 d e f in it io n c o n f o r m in g t o I TU - T R e c s . X . 2 0 8 / X . 2 0 9 ( s h e e t 1 o f 2 ) Remote-Operations-Apdus { iso( 1) standard( 0) pss1-generic-procedures( 11582) remote-operations-apdus( 5) } DEFINITIONS BEGIN

::=

EXPORTS IMPORTS

RoseAPDU; OPERATION, ERROR FROM Remote-Operations-Notation { joint-iso-ccitt( 2) remote-operations( 4) notation( 0) };

RoseAPDU

::= CHOICE { invoke retResult retError reject

InvokePDU

::= SEQUENCE { invokeID linkedID operationValue argument

[1] IMPLICIT [2] IMPLICIT [3] IMPLICIT [4] IMPLICIT

InvokePDU, ReturnResultPDU, ReturnErrorPDU, RejectPDU }

InvokeIDType, [0] IMPLICIT InvokeIDType OPTIONAL, OPERATION, ANY DEFINED BY operationValue OPTIONAL }

ReturnResultPDU

::= SEQUENCE { invokeID InvokeIDType, SEQUENCE { operationValue OPERATION, result ANY DEFINED BY operationValue } OPTIONAL }

ReturnErrorPDU

::= SEQUENCE { invokeID errorValue parameter

RejectPDU

::= SEQUENCE { invokeID problem

InvokeIDType, ERROR, ANY DEFINED BY errorValue OPTIONAL

}

CHOICE { InvokeIDType, NULL }, CHOICE { [0] IMPLICIT GeneralProblem, [1] IMPLICIT InvokeProblem, [2] IMPLICIT ReturnResultProblem, [3] IMPLICIT ReturnErrorProblem }

InvokeIDType

::=

INTEGER(-32768..32767)

GeneralProblem

::=

INTEGER { unrecognisedAPDU( 0), mistypedAPDU( 1), badlyStructuredAPDU( 2)

} (0..255)

INTEGER { duplicateInvocation( 0), unrecognisedOperation( 1), mistypedArgument( 2), resourceLimitation( 3), initiatorReleasing( 4), unrecognisedLinkedIdentifier( 5), linkedResponseUnexpected( 6), unexpectedChildOperation( 7)

} (0..255)

InvokeProblem

::=

}

- 120 -

Table K.6 - ROSE APDUs A S N . 1 d e f in it io n c o n f o r m in g t o I TU - T R e c s . X . 2 0 8 / X . 2 0 9 ( s h e e t 2 o f 2 ) ReturnResultProblem

::=

INTEGER { unrecognisedInvocation( 0), resultResponseUnexpected( 1), mistypedResult( 2) } (0..255)

ReturnErrorProblem

::=

INTEGER { unrecognisedInvocation( 0), errorResponseUnexpected( 1), unrecognisedError( 2), unexpectedError( 3), mistypedParameter( 4) } (0..255)

END

-- of Remote-Operations-Apdus

Table K.7 - ACSE APDUs A S N . 1 d e f in it io n c o n f o r m in g t o I TU - T R e c s . X . 2 0 8 / X . 2 0 9 Association-Control-Apdus {iso( 1) standard( 0) pss1-generic-procedures( 11582) association-control-apdus( 1) } DEFINITIONS

::=

BEGIN EXPORTS

AcseAPDU;

IMPORTS ACSE-apdu FROM ACSE-1 { joint-iso-ccitt association-control( 2) abstract-syntax( 1) apdus( 0) version( 1) }; AcseAPDU

::= ACSE-apdu

END --of Association-Control-Apdus

- 121 -

Table K.8 - ASN.1 encoded Notification Data Structure A S N . 1 d e f in it io n c o n f o r m in g t o I TU - T R e c s . X . 2 0 8 / X . 2 0 9 Notification-Data-Structure { iso( 1) standard( 0) pss1-generic-procedures( 11582) notification-data-structure( 7) } DEFINITIONS ::= BEGIN EXPORTS

NotificationDataStructure;

NotificationDataStructure

::= SEQUENCE { notificationTypeID notificationArgument

-- ANY is filled by the single ASN.1 type following -- the keyword ARGUMENT in the type definition of a particular -- notification END -- of Notification-Data-Structure

NOTIFICATION, ANY DEFINED BY notificationTypeID }

- 122 -

Table K.9 - Addressing information definitions A S N . 1 d e f in it io n c o n f o r m in g t o I TU - T R e c s . X . 2 0 8 / X . 2 0 9 ( s h e e t 1 o f 3 ) Addressing-Data-Elements {iso( 1) standard( 0) pss1-generic-procedures( 11582) addressing-data-elements( 9)} DEFINITIONS EXPLICIT TAGS ::= BEGIN EXPORTS

PresentedAddressScreened, PresentedAddressUnscreened, PresentedNumberScreened, PresentedNumberUnscreened, Address, PartyNumber, PartySubaddress, ScreeningIndicator, PresentationAllowedIndicator;

PresentedAddressScreened ::= CHOICE { presentationAllowedAddress [0] IMPLICIT AddressScreened, presentationRestricted [1] IMPLICIT NULL, numberNotAvailableDueToInterworking [2] IMPLICIT NULL, presentationRestrictedAddress [3] IMPLICIT AddressScreened} PresentedAddressUnscreened ::= CHOICE { presentationAllowedAddress [0] IMPLICIT Address, presentationRestricted [1] IMPLICIT NULL, numberNotAvailableDueToInterworking [2] IMPLICIT NULL, presentationRestrictedAddress [3] IMPLICIT Address} PresentedNumberScreened ::= CHOICE { presentationAllowedAddress [0] IMPLICIT NumberScreened, presentationRestricted [1] IMPLICIT NULL, numberNotAvailableDueToInterworking [2] IMPLICIT NULL, presentationRestrictedAddress [3] IMPLICIT NumberScreened} PresentedNumberUnscreened ::= CHOICE { presentationAllowedAddress [0] PartyNumber, presentationRestricted [1] IMPLICIT NULL, numberNotAvailableDueToInterworking [2] IMPLICIT NULL, presentationRestrictedAddress [3] PartyNumber} AddressScreened

::=

SEQUENCE { PartyNumber, ScreeningIndicator, PartySubaddress OPTIONAL}

NumberScreened

::= SEQUENCE { PartyNumber, ScreeningIndicator}

Address

::= SEQUENCE { PartyNumber, PartySubaddress OPTIONAL}

- 123 -

Table K.9 - Addressing information definitions A S N . 1 d e f in it io n c o n f o r m in g t o I TU - T R e c s . X . 2 0 8 / X . 2 0 9 ( s h e e t 2 o f 3 ) PartyNumber

::= CHOICE { unknownPartyNumber [0] IMPLICIT NumberDigits, -- the numbering plan is the default numbering -- plan of the network. It is recommanded that -- this value is used. publicPartyNumber [1] IMPLICIT PublicPartyNumber, -- the numbering plan is according to -- Recommendation E.163 and E.164. dataPartyNumber [3] IMPLICIT NumberDigits, -- not used, value reserved. telexPartyNumber [4] IMPLICIT NumberDigits, -- not used, value reserved. privatePartyNumber [5] IMPLICIT PrivatePartyNumber, nationalStandardPartyNumber [8] IMPLICIT NumberDigits} -- not used, value reserved.

PublicPartyNumber

::= SEQUENCE { publicTypeOfNumber PublicTypeOfNumber, publicNumberDigits NumberDigits}

PrivatePartyNumber ::= SEQUENCE { privateTypeOfNumber PrivateTypeOfNumber, privateNumberDigits NumberDigits} NumberDigits

::=

NumericString (SIZE(1..20))

::= CHOICE { UserSpecifiedSubaddress, -- not recommended. NSAPSubaddress} -- according to Recommendation X.213.

UserSpecifiedSubaddress ::= SEQUENCE { SubaddressInformation, oddCountIndicator BOOLEAN OPTIONAL} -- used when the coding of subaddress is BCD NSAPSubaddress

::= OCTET STRING (SIZE(1..20)) -- specified according to X.213. Some networks may -- limit the subaddress value to some other length -- e.g. 4 octets

- 124 -

Table K.9 - Addressing information definitions A S N . 1 d e f in it io n c o n f o r m in g t o I TU - T R e c s . X . 2 0 8 / X . 2 0 9 ( s h e e t 3 o f 3 ) SubaddressInformation ::= OCTET STRING (SIZE(1..20)) -- coded according to user requirements. Some networks -- may limit the subaddress value to some other length -- e.g. 4 octets ScreeningIndicator

PresentationAllowedIndicator

::=

END -- of Addressing-Data-Elements

BOOLEAN

- 125 -

Table K.10 - NOTIFICATION macro definition A S N . 1 d e f in it io n c o n f o r m in g t o I TU - T R e c s . X . 2 0 8 / X . 2 0 9 Notification-macro { iso( 1) standard( 0) pss1-generic-procedures( 11582) notification-macro( 10) } DEFINITIONS

::=

BEGIN EXPORTS

NOTIFICATION, pss1IeNotification;

IMPORTS PSS1InformationElement FROM PSS1-generic-parameters-definition { iso( 1) standard( 0) pss1-generic-procedures( 11582) pss1-generic-parameters( 6)}; NOTIFICATION MACRO BEGIN

::=

TYPE NOTATION

::= Argument

VALUE NOTATION

::= value ( VALUE CHOICE { localValue globalValue

Argument

::= “ARGUMENT” NamedType

NamedType

::= identifier type | type

INTEGER, OBJECT IDENTIFIER

END -- of NOTIFICATION MACRO -- this notification is used to convey information elements used as notifications -- across a PISN pss1IeNotification

END -- of Notification-macro

NOTIFICATION ARGUMENT PSS1InformationElement ::= localValue2001

})

- 126 -

Table K.11 - PSS1 information element A S N . 1 d e f in it io n c o n f o r m in g t o I TU - T R e c s . X . 2 0 8 / X . 2 0 9 PSS1-generic-parameters-definition { iso( 1) standard( 0) pss1-generic-procedures( 11582) pss1-generic-parameters( 6)} DEFINITIONS BEGIN EXPORTS

::=

PSS1InformationElement;

PSS1InformationElement

::= [APPLICATION 0] IMPLICIT

END -- of PSS1 Generic parameters definition

OCTET STRING

- 127 -

Annex L ( in f o r ma tiv e )

Technical changes since third edition of ECMA-165

This annex lists the technical changes made to this Standard since its third edition. Additional editorial changes have been applied, but are not detailed in this annex.

L.1

General changes

General changes have been applied due to migration from ITU-T Recs. X.208 / X.209 ASN.1 notation to ITU-T Recs. X.680 / X.690 ASN.1 notation. All ASN.1 modules in this Standard have been changed. Annex K shows the original ASN.1 modules from the third edition, i.e. conforming to ITU-T Recs. X.208 / X.209. All differences with ISO/IEC 11582 (1995) have been deleted in this edition of ECMA-165. Especially all information about Transit Counter was deleted from this Standard, as ECMA-225 reflects all Transit Counter issues relevant for the Generic Functional Protocol.

L.2 L.2.1

Further technical changes to specific sections Changes in clause 7.3.1.9 Transport of APDUs associated with a call independent signalling connection Text in third edition: Sub-clause 7.1.1 shall apply, with the exception that the term ‘call’ shall be interpreted as ‘Call independent signalling connection’. Text in fourth edition: When requested by GFT-Control, the Facility information element may be sent in a call establishment or a call clearing message (see clause 10) of the connection oriented, call independent signalling connection or in a FACILITY message during Active state of the connection oriented, call independent signalling connection.

L.2.2

Changes in clause 7.3.1.10 Protocol error handling Text in third edition: ... – if a SETUP ACKNOWLEDGE, ALERTING, DISCONNECT or PROGRESS message (defined in ECMA-143) is received in any state (except the Null state, where invalid call reference error procedures apply) it shall be treated as an unexpected or unrecognised message in accordance with 9.2.4 of ECMA-143. Text in fourth edition: ... – if a SETUP ACKNOWLEDGE, ALERTING, INFORMATION, DISCONNECT or PROGRESS message (defined in ECMA-143) is received in any state (except the Null state, where invalid call reference error procedures apply) it shall be treated as an unexpected or unrecognised message in accordance with 9.2.4 of ECMA-143.

Free printed copies can be ordered from: ECMA 114 Rue du Rhône CH-1204 Geneva Switzerland Fax: Email:

+41 22 849.60.01 [email protected]

Files of this Technical Report can be freely downloaded from the ECMA web site (www.ecma.ch). This site gives full information on ECMA, ECMA activities, ECMA Standards and Technical Reports.

ECMA 114 Rue du Rhône CH-1204 Geneva Switzerland See inside cover page for obtaining further soft or hard copies.

ECMA-165 — Private Integrated Services Network (PISN) - Generic functional protocol for the support of supplementary services - Inter-exchange signalling procedures and protocol (QSIG-GF) (June 2001)

Related documents