Conceptio › Archive › ECMA International

ECMA Internationalopen access

ECMA-251 — Private Integrated Services Network (PISN) - Inter-exchange signalling protocol - Common information additional network feature (QSIG-CMN) (December 2001)

ECMA International · ECMA International

ECMA International · Standards · License: Open Access

additional common ecma ecmainternational exchange feature information integrated

ecma, standard, ecma international, specification, ecma-251, ecma 251, 251, private, integrated, services, network, pisn, inter-exchange, signalling, protocol, common, information, additional, feature, qsig-cmn

S tandard ECMA-251

3rd Edition - December 2001

Standardizing Information

and

Communication

Systems

Private Integrated Services Network (PISN) Inter-Exchange Signalling Protocol Common Information Additional Network Feature

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

S tandard ECMA-251

3rd Edition - December 2001

Standardizing

Information

and

Communication

Systems

Private Integrated Services Network (PISN) Inter-Exchange Signalling Protocol Common Information Additional Network Feature (QSIG-CMN)

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

Ecma-251.doc

14-01-02 10,15

Brief History

This Standard is one of a series of ECMA standards defining services and signalling protocols applicable to Private Integrated Services Networks. The series uses ISDN concepts as developed by ITU-T and conforms to the framework of standards for Open Systems Interconnection as defined by ISO/IEC. This particular Standard specifies the signalling protocol for use at the Q reference point in support of the Common Information additional network feature. The 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 1st Edition of Standard ECMA-251 (published by ECMA in December 1996), the 2nd Edition incorporated changes to achieve complete alignment with International Standard ISO/IEC 15772:1998(E) published by ISO/IEC in November 1998. Compared to the 2nd Edition of Standard ECMA-251 (published by ECMA in December 1998), this 3rd Edition incorporates migration to ASN.1 version 1997.

Adopted as 3rd Edition of Standard ECMA-251 by the General Assembly of December 2001.

- i -

Table of contents 1

Scope

Conformance

References (normative)

Definitions E x te r n a l d e f in itio n s

2 2

List of acronyms

4 4.1 5 6

Signalling protocol for the support of ANF-CMN 6 . 1 A N F - CMN d e s c r ip tio n 6 . 2 A N F - CMN o p e r a tio n a l r e q u ir e me n ts 6.2.1 Re q u ir e me n ts o n a n O r ig in a tin g P I N X 6.2.2 Re q u ir e me n ts o n a T e r min a tin g P I N X 6.2.3 Re q u ir e me n ts o n a T r a n s it P I N X 6 . 3 A N F - CMN c o d in g r e q u ir e me n ts 6.3.1 Operations 6.3.2 Notifications 6.3.3 I n f o r ma t i o n e l e me n t s 6.3.4 Messages 6 . 4 A N F - CMN S ta te d e f in itio n s 6.4.1 States at the Originating PINX 6.4.2 S t a t e s a t t h e T e r mi n a t i n g P I N X 6 . 5 A N F - CMN S ig n a llin g p r o c e d u r e s f o r a c tiv a tio n , d e a c tiv a tio n a n d r e g is tr a tio n 6 . 6 A N F - CMN S ig n a llin g p r o c e d u r e s f o r in v o c a tio n a n d o p e r a tio n 6.6.1 Actions at the Originating PINX 6.6.2 A c t i o n s a t t h e T e r mi n a t i n g P I N X 6.6.3 Actions at a Transit PINX 6 . 7 A N F - CMN I mp a c t o f in te r w o r k in g w ith p u b lic I S D N s 6 . 8 A N F - CMN I mp a c t o f in te r w o r k in g w ith n o n - I S D N s 6 . 9 P r o to c o l in te r a c tio n s b e tw e e n A N F - CMN an d o th e r s u p p le me n ta r y s e r v ic e s a n d A N F s 6.9.1 I n t e r a c t i o n s w i t h C a l l i n g N a me I d e n t i f i c a t i o n P r e s e n t a t i o n ( C N I P ) 6.9.2 I n t e r a c t i o n s w i t h C o n n e c t e d N a me I d e n t i f i c a t i o n P r e s e n t a t i o n ( C O N P ) 6.9.3 I n te r a c tio n s w ith Ca ll F o r w a r d in g U n c o n d itio n a l ( CF U ) 6.9.4 I n t e r a c t i o n s w i t h C a l l F o r w a r d in g B u s y ( C F B ) 6.9.5 I n te r a c tio n s w ith Ca ll F o r w a r d in g N o Re p ly ( CF N R) 6.9.6 Interactions with Call Deflection (CD) 6.9.7 Interactions with Call Transfer (CT) 6.9.8 I n t e r a c t i o n s w i t h C o mp l e t i o n o f C a l l o n B u s y S u b s c r i b e r ( C C B S ) 6.9.9 I n te r a c tio n s w ith Co mp le tio n o f Ca ll o n N o Re p ly ( CCN R) 6.9.10 Interactions with Call Intrusion (CI)

3 3 3 3 3 3 4 4 7 7 7 7 7 7 7 7 7 9 10 10 10 10 10 10 10 10 10 11 11 11 11 11

- ii -

6.9.11 Interactions with Call Offer (CO) 6.9.12 Interactions with Do Not Disturb (DND) 6.9.13 Interactions with Do Not Disturb Override (DNDO) 6.9.14 Interactions with Call Interception (CINT) 6.9.15 I n te r a c tio n s w ith A d v ic e O f Ch a r g e ( A O C) 6.9.16 I n te r a c tio n s w ith Me s s a g e W a itin g I n d ic a tio n ( MW I ) 6.9.17 I n t e r a c t i o n s w i t h P a t h R e p l a c e me n t ( P R ) 6.9.18 Interactions with Recall (RE) 6.9.19 I n t e r a c t i o n s w i t h W ir e l e s s T e r mi n a l M o b i l i t y , O u t g o in g c a l l ( W T M O ) 6.9.20 I n t e r a c t i o n s w i t h W ir e l e s s T e r mi n a l M o b i l i t y , I n c o min g c a l l ( W T M I ) 6.9.21 I n t e r a c t i o n s w i t h W ir e l e s s T e r mi n a l , L o c a t i o n R e g is t r a t i o n ( W T L R ) 6.9.22 I n t e r a c t i o n s w i t h W ir e l e s s T e r mi n a l , A u t h e n t i c a t i o n ( W T A N , W T A T ) 6.9.23 I n te r a c tio n s w ith T r a n s it Co u n te r ( T C) 6.10 A N F - C MN P a r a me t e r v a l u e s ( t i me r s )

11 11 11 11 11 11 11 12 12 12 12 12 12 12

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 ) p r o f o r m a

A n n e x B - Ex a m p le s o f m e s s a g e s e q u e n c e s

A n n e x C - S p e c i f i c a t i o n a n d D e s c r i p t i o n L a n gu a g e ( S D L ) r e p r e s e n t a t i o n o f p r o c e d u r e s

A n n e x D - 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

Scope This Standard specifies the signalling protocol for the support of the Common Information additional network feature (ANF-CMN) at the Q reference point between Private Integrated services Network eXchanges (PINX) connected together within a Private Integrated Services Network (PISN). ANF-CMN is an additional network feature which enables the exchange of Common Information between entities acting on behalf of the two ends of a connection through a PISN. This Common Information is a collection of miscellaneous information that relates to the user or equipment at one end of a connection and includes one or more of the following: Feature Identifiers, Party Category, Equipment Identity. This information, when received by an entity, can be used for any purpose, e.g. as the basis for indications to the local user or to another network or in order to filter feature requests. The Q reference point is defined in ECMA-133. Additional network feature specifications are produced in three stages and according to the method described in ETS 300 387. This Standard contains the stage 3 specification for the Q reference point and satisfies the requirements identified by the stage 1 and stage 2 specifications in ECMA-250. The signalling protocol for ANF-CMN operates on top of the signalling protocol for basic circuit switched call control, as specified in ECMA-143, and uses certain aspects of the generic procedures for the control of supplementary services specified in ECMA-165. This Standard also specifies additional signalling protocol requirements for the support of interactions at the Q reference point between ANF-CMN and other supplementary services and ANFs. NOTE 1 Additional interactions that have no impact on the signalling protocol at the Q reference point can be found in the relevant stage 1 specifications. This Standard is applicable to PINXs which can interconnect to form a PISN.

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. Conformance to this Standard includes conforming to those clauses that specify protocol interactions between ANF-CMN and other supplementary services and ANFs for which signalling protocols at the Q reference point are supported in accordance with the stage 3 standards concerned.

References (normative) The following standards contain provisions which, through reference in this text, constitute provision 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-143

Private Integrated Services Network (PISN) - Circuit mode bearer services - Interexchange signalling procedures and protocol (International Standard ISO/IEC 11572)

ECMA-165

Private Integrated Services Network (PISN) - Generic functional protocol for the support of supplementary services - Inter-exchange signalling procedures and protocol (International Standard ISO/IEC 11582)

ECMA-174

Private Integrated Services Network (PISN) - Inter-exchange signalling protocol - Call diversion supplementary services (International Standard ISO/IEC 13873)

- 2 -

ECMA-221

Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol - Call Interception Supplementary Service (International Standard ISO/IEC 15054)

ECMA-250

Private Integrated Services Network (PISN) - Specification, Functional Model and Information Flows - Common Information Additional Network Feature (International Standard ISO/IEC 15771)

ECMA-304

Private Integrated Services Network (PISN) - Inter-Exchange Signalling Protocol Wireless Terminal Call Handling Additional Network Features (International Standard ISO/IEC 15431)

ETS 300 387

Private Telecommunication Network (PTN); Method for the specification of basic and supplementary services (1994)

ITU-T Rec. I.112

Vocabulary of terms for ISDNs (1993)

ITU-T Rec. I.210

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

ITU-T Rec. Q.950 Supplementary services protocols, structure and general principles (2000) ITU-T Rec. Z.100 Specification and description language (1999)

Definitions For the purpose of this Standard the following definitions apply.

4.1

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

− ANF-CMN user

(ECMA-250)

− Application Protocol Data Unit (APDU)

(ECMA-165)

− Backward direction

(ECMA-250)

− Basic Service

(ITU-T Rec. I.210)

− Call, Basic Call

(ECMA-165)

− Equipment Identity

(ECMA-250)

− Feature Identifier

(ECMA-250)

− Forward direction

(ECMA-250)

− Originating PINX

(ECMA-143)

− Party Category

(ECMA-250)

− Private Integrated Services Network (PISN)

(ECMA-133)

− Private Integrated services Network eXchange (PINX)

(ECMA-133)

− Signalling

(ITU-T Rec. I.112)

− Supplementary Service

(ITU-T Rec. I.210)

− Supplementary Service Control Entity

(ECMA-165)

− Terminating PINX

(ECMA-143)

− Transit PINX

(ECMA-143)

List of acronyms ANF

Additional Network Feature

ANF-CMN

Additional Network Feature Common Information

- 3 -

APDU

Application Protocol Data Unit

ASN.1

Abstract Syntax Notation no.1

ISDN

Integrated Services Digital Network

NFE

Network Facility Extension

PICS

Protocol Implementation Conformance Statement

PINX

Private Integrated services Network eXchange

PISN

Private Integrated Services Network

SDL

Specification and Description Language

Supplementary Service

Signalling protocol for the support of ANF-CMN

6.1

ANF-CMN description ANF-CMN is an additional network feature which enables the exchange of Common Information between ANF-CMN users acting on behalf of the two ends of a connection through a PISN. This Common Information is a collection of miscellaneous information that relates to the user or equipment at one end of a connection and includes one or more of the following: Feature Identifiers, Party Category, Equipment Identity. This information, when received by an ANF-CMN user, can be used for any purpose, e.g. as the basis for indications to the local user or to another network or in order to filter feature requests. A solicited and an unsolicited service is offered to an ANF-CMN user. The solicited service enables the ANF-CMN user to request the Common Information from a remote ANFCMN user. The unsolicited service supplies the Common Information to an ANF-CMN user. These services may be combined and are not mutually exclusive. The Common Information contains the SS/ANF-identifiers supported by the ANF-CMN user and available for the particular call, the possible options and - if applicable - details of the SS/ANF. Additionally, equipment identity and party category are contained.

6.2 6.2.1

ANF-CMN operational requirements Requirements on an Originating PINX Call establishment procedures for the outgoing side of an inter-PINX link and call release procedures, as specified in ECMA-143, shall apply. Generic procedures for the call-related control of supplementary services, as specified in ECMA-165 for an End PINX, shall apply.

6.2.2

Requirements on a Terminating PINX Call establishment procedures for the incoming side of an inter-PINX link and call release procedures, as specified in ECMA-143, shall apply. Generic procedures for the call-related control of supplementary services, as specified in ECMA-165 for an End PINX, shall apply.

6.2.3

Requirements on a Transit PINX Basic call procedures as specified in ECMA-143 for a Transit PINX shall apply. Generic procedures for the call-related control of supplementary services, as specified in ECMA-165 for a Transit PINX, shall apply.

- 4 -

6.3

ANF-CMN coding requirements

6.3.1

O p e r a t io n s The operations defined in Abstract Syntax Notation number 1 (ASN.1) in table 1 shall apply. The notation is in accordance with ITU-T Rec. X.680 and X.690. The ITU-T Rec. X.208 and X.209 superseded version is in annex D. Table 1 - Operations in Support of ANF-CMN

Common-Information-Operations-asn1-97 {iso (1) standard (0) pss1-common-information (15772) operations-asn1-97 (1)} DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS

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

CMN-Operations OPERATION ::= {cmnRequest | cmnInform } cmnRequest

cmnInform

CmnArg

OPERATION ::= { ARGUMENT RESULT ALWAYS RESPONDS CODE

DummyArg CmnArg FALSE local: 84}

OPERATION ::= { ARGUMENT RETURN RESULT ALWAYS RESPONDS CODE

CmnArg FALSE FALSE local: 85}

::= SEQUENCE { featureIdentifier [2] IMPLICIT FeatureIdList OPTIONAL, ssDNDOprotectionLevel [3] IMPLICIT INTEGER (0..3) OPTIONAL, -- Supplementary Service Do Not Disturb Override Protection level, -- meaningful only in backward direction; inclusion indicates -- support of SS-DNDO as well as the applicable protection level. ssCIprotectionLevel [4] IMPLICIT INTEGER (0..3) OPTIONAL, -- Supplementary Service Call Intrusion Protection level, -- meaningful both in forward & backward direction; inclusion indicates support -- of SS-CI as an Unwanted user PINX (forward direction) or as a Terminating -- PINX (backward direction), as well as the applicable protection level. equipmentIdentity [5] IMPLICIT EquipmentId OPTIONAL, partyCategory [6] IMPLICIT PartyCategory OPTIONAL, extension CHOICE { single [7] IMPLICIT Extension{{CMNExtSet}}, multiple [8] IMPLICIT SEQUENCE OF Extension{{CMNExtSet}} } OPTIONAL }

- 5 -

Table 1 - Operations in Support of ANF-CMN (continued) DummyArg

::=

CHOICE { null single multiple }

FeatureIdList

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

::= BIT STRING { -- bit set to ONE means the corresponding feature -- is available for this call reserved (0), -- this Bit shall be reserved ssCFreRoutingSupported (1), -- Call Forwarding rerouting supported -- meaningful only in forward direction -- during call establishment ssCTreRoutingSupported (2), -- Call Transfer rerouting supported -- meaningful both in forward & backward -- direction during call establishment ssCCBSpossible (3), -- CCBS possible -- meaningful only in backward direction -- before receipt of ALERTING/CONNECT ssCCNRpossible (4), -- CCNR possible -- meaningful only in backward direction -- before receipt of CONNECT ssCOsupported (5), -- Call Offer supported -- meaningful only in backward direction -- during call establishment

ssCIforcedRelease ssCIisolation ssCIwaitOnBusy

(6), (7), (8),

-- Call Intrusion -- meaningful only in backward direction -- meaningful only in backward direction -- meaningful only in backward direction

ssAOCsupportChargeRateProvAtGatewPinx ssAOCsupportInterimChargeProvAtGatewPinx ssAOCsupportFinalChargeProvAtGatewPinx

anfPRsupportedAtCooperatingPinx

anfCINTcanInterceptImmediate anfCINTcanInterceptDelayed

-- Advice of Charge -- meaningful only in -- backward direction (10), -- meaningful only in -- backward direction (11), -- meaningful only in -- backward direction (9),

(12), -- Path replacement -- meaningful both in forward & -- backward direction -- Call Interception (13), -- meaningful only in -- forward direction (14), -- meaningful only in -- forward direction

- 6 -

Table 1 - Operations in Support of ANF-CMN (continued) anfWTMIreRoutingSupported

anfPUMIreRoutingSupported

ssSSCTreRoutingSupported

(15), -- Incoming WTM call -- meaningful only in -- forward direction (16), -- Incoming PUM call -- meaningful only in -- forward direction (17) -- Single Step Call Transfer rerouting -- supported -- meaningful both in forward and -- backward direction during call -- establishment

} (SIZE (1..64)) EquipmentId

::= SEQUENCE { nodeId groupId unitId }

[1] IMPLICIT IA5String (SIZE (1..10)) OPTIONAL, [2] IMPLICIT IA5String (SIZE (1..10)) OPTIONAL, [3] IMPLICIT IA5String (SIZE (1..10)) OPTIONAL

-- NOTE: -- The purpose of the Equipment Id is to indicate, to another user or to another PINX, information about a -- calling or called party involved in a call. -- Assignment of network wide unique Equipment Id values is outside the scope of this Standard. PartyCategory

::= ENUMERATED { unknown extension pisnAttendant emergExt }

(0), (1), (2), (3)

-- NOTE: -- The purpose of the Party category is to indicate, to another user or to another PINX, the category of a user -- involved in a call. An Originating PINX may include an indication of the calling user's category in the SETUP -- message sent across an inter-PINX link. A Terminating PINX may include an indication of the called user's -- category in an ALERTING message or CONNECT message sent across an inter-PINX link. A received -- Party category information may be used for display at the user's terminal or for PINX internal call handling, -- e.g. depending on whether the calling or called party is an extension or a PISN attendant, the PINX internal -- call handling may invoke different options of a supplementary service related to that call. CMNExtSet EXTENSION ::= {...}

END

-- of Common-Information-Operations-asn1-97

- 7 -

6.3.2

N o t if ic a t io n s Not applicable.

6.3.3 Information elements 6.3.3.1 Facility information element The operations defined in 6.3.1 shall be coded in the Facility information element in accordance with ECMA-165. The Facility information element shall contain a NFE with the destinationEntity element having the value endPINX. A Facility information element conveying a CmnInform invoke APDU shall also contain an Interpretation APDU with the value discardAnyUnrecognisedInvokePdu. In a Facility information element conveying a CmnRequest invoke APDU, the Interpretation APDU shall either be omitted or included with the value rejectAnyUnrecognisedInvokePdu. 6.3.3.2 6.3.4

6.4

Other information elements No other information elements used. Messages The Facility information element shall be conveyed in the messages as specified in clause 10 of ECMA-165.

ANF-CMN State definitions

6.4.1

S t a t e s a t t h e O r ig in a t in g P I N X The procedures for the Originating PINX are written in terms of the following conceptual states existing within the ANF-CMN Supplementary Service Control entity in that PINX in association with a particular call.

6.4.1.1

S t a t e C M N - I d le ANF-CMN is not operating.

6.4.1.2

S t a t e C M N - W a it - A n s we r The Originating PINX has requested common information and is waiting for an answer from the Terminating PINX.

6.4.2

States at the Terminating PINX The procedures for the Terminating PINX are written in terms of the following conceptual states existing within the ANF-CMN Supplementary Service Control entity in that PINX in association with a particular call.

6.4.2.1

S t a t e C M N - I d le ANF-CMN is not operating.

6.4.2.2

S t a t e C M N - W a it - A n s we r The Terminating PINX has requested common information and is waiting for an answer from the Originating PINX (ANF-CMN invoked in backward direction).

6.5

ANF-CMN Signalling procedures for activation, deactivation and registration Not applicable.

6.6

ANF-CMN Signalling procedures for invocation and operation The procedures described in the following for the invocation of ANF-CMN at call establishment are mandatory, whereas the procedures for the invocation in the active phase of a call are optional. Examples of message sequences are shown in annex B.

6.6.1

A c t io n s a t t h e O r ig in a t in g P I N X The SDL representation of procedures at the Originating PINX is shown in C.1 of annex C.

- 8 -

6.6.1.1

Normal procedures To invoke the solicited service of ANF-CMN, i.e. to request common information from the remote side, the Originating PINX shall send a CmnRequest invoke APDU. For invocation during the establishment phase of a call, the APDU may either be sent within a SETUP message or within a FACILITY message using the call reference of that call. However, the FACILITY message shall not be used before the first end-to-end basic call message (i.e. ALERTING, CONNECT, PROGRESS) has been received. For invocation during the active phase of a call, the APDU shall be sent within a FACILITY message using the call reference of that call. Only if the CmnRequest invoke APDU is sent in a FACILITY message, timer T1 shall be started. If the CmnRequest invoke APDU is sent in a SETUP message, basic call timers provide sufficient protection. In both cases, after sending the CmnRequest invoke APDU, the Originating PINX shall enter the CMN-Wait-Answer state. In the CMN-Wait-Answer state, upon receipt of a CmnRequest return result APDU in a basic call message (e.g. ALERTING, CONNECT, PROGRESS) or in a FACILITY message, the Originating PINX shall stop timer T1, if running, and enter the CMN-Idle state. NOTE The common information contained in the received CmnRequest return result APDU should be conveyed to the ANF-CMN user. To invoke the unsolicited service of ANF-CMN, i.e. to send unsolicited common information to the remote side, the Originating PINX shall send a CmnInform invoke APDU. For invocation during the establishment phase of a call, the APDU may either be sent within a SETUP message or within a FACILITY message using the call reference of that call. However, the FACILITY message shall not be used before the first end-to-end basic call message (i.e. ALERTING, CONNECT, PROGRESS) has been received. For invocation during the active phase of a call, the APDU shall be sent within a FACILITY message using the call reference of that call. NOTE The CmnInform invoke APDU contains the common information provided by the ANF-CMN user. If the solicited service of ANF-CMN is invoked in backward direction, i.e. upon receipt of a CmnRequest invoke APDU in a basic call message (e.g. ALERTING, CONNECT, PROGRESS) or in a FACILITY message in the CMN-Idle state, the Originating PINX, if common information is available, shall send a CmnRequest return result APDU in order to send the solicited common information to the remote side and remain in the CMN-Idle state. The CmnRequest return result APDU shall be sent within a FACILITY message using the call reference of that call. NOTE The invocation of ANF-CMN, solicited service, should be indicated to the ANF-CMN user. The common information contained in the CmnRequest return result APDU to be sent has to be provided by the ANF-CMN user. Upon receipt of a CmnInform invoke APDU in any message, the Originating PINX shall remain in the CMN-Idle state. NOTE The common information contained in the received CmnInform invoke APDU should be conveyed to the ANF-CMN user.

6.6.1.2

Ex c e p t io n a l p r o c e d u r e s In the CMN-Wait-Answer state, upon receipt of any message containing a CmnRequest reject APDU, the Originating PINX shall stop timer T1, if running, and enter the CMN-Idle state, and the call shall continue in accordance with ECMA-143. Upon expiry of timer T1 the Originating PINX shall enter the CMN-Idle state and the call shall continue in accordance with ECMA-143. In the CMN-Wait-Answer state, if timer T1 is not running (i.e. the CmnRequest invoke APDU was sent in a SETUP message), the receipt of a CONNECT message that does not contain a CmnRequest return result or reject APDU shall cause state CMN-Idle to be entered.

- 9 -

If the basic call is cleared, while in the CMN-Wait-Answer state, timer T1 shall be stopped and the CMN-Idle state shall be entered. NOTE Failure of ANF-CMN should be indicated to the ANF-CMN user. 6.6.2 6.6.2.1

Actions at the Terminating PINX The SDL representation of procedures at the Terminating PINX is shown in C.2 of annex C. Normal procedures Upon receipt of a CmnRequest invoke APDU in a SETUP or a FACILITY message, the Terminating PINX, if common information is available, shall send a CmnRequest return result APDU in order to send the solicited common information to the remote side and remain in the CMN-Idle state. The CmnRequest return result APDU may either be sent within a basic call message (e.g. ALERTING, CONNECT, PROGRESS) or within a FACILITY message using the call reference of that call. However, if the CmnRequest invoke APDU was received in a SETUP message, the CmnRequest return result APDU shall be sent within the CONNECT message, if not already sent. NOTE The invocation of ANF-CMN, solicited service, should be indicated to the ANF-CMN user. The common information contained in the CmnRequest return result APDU to be sent has to be provided by the ANF-CMN user. Upon receipt of a CmnInform invoke APDU in any message, the Terminating PINX shall remain in the CMN-Idle state. NOTE The common information contained in the received CmnInform invoke APDU should be conveyed to the ANF-CMN user. To invoke the solicited service of ANF-CMN in backward direction, the Terminating PINX shall send a CmnRequest invoke APDU, start timer T1 and enter the CMN-Wait-Answer state. For invocation during the establishment phase of a call, the APDU may either be sent within a basic call message (e.g. ALERTING, CONNECT, PROGRESS) or within a FACILITY message using the call reference of that call. For invocation during the active phase of a call, the APDU shall be sent within a FACILITY message using the call reference of that call. In the CMN-Wait-Answer state, upon receipt of a CmnRequest return result APDU in a FACILITY message, the Terminating PINX shall stop timer T1 and enter the CMN-Idle state. NOTE The common information contained in the received CmnRequest return result APDU should be conveyed to the ANF-CMN user. To invoke the unsolicited service of ANF-CMN in backward direction, the Terminating PINX shall send a CmnInform invoke APDU. For invocation during the establishment phase of a call, the APDU may either be sent within a basic call message (e.g. ALERTING, CONNECT, PROGRESS) or within a FACILITY message using the call reference of that call. For invocation during the active phase of a call, the APDU shall be sent within a FACILITY message using the call reference of that call. NOTE The CmnInform invoke APDU contains the common information provided by the ANF-CMN user.

6.6.2.2

Ex c e p t io n a l p r o c e d u r e s In the CMN-Wait-Answer state, upon receipt of any message containing a CmnRequest reject APDU, the Terminating PINX shall stop timer T1 and enter the CMN-Idle state, and the call shall continue in accordance with ECMA-143. Upon expiry of timer T1 the Terminating PINX shall enter the CMN-Idle state and the call shall continue in accordance with ECMA-143. If the basic call is cleared, while in the CMN-Wait-Answer state, timer T1 shall be stopped and the CMN-Idle state shall be entered.

- 10 -

NOTE Failure of ANF-CMN should be indicated to the ANF-CMN user. 6.6.3

6.7

A c t io n s a t a Tr a n s it P I N X Not applicable.

ANF-CMN Impact of interworking with public ISDNs At the time of publication of this Standard, no equivalent service exists in public ISDNs. In case of interworking with a public ISDN, the Incoming Gateway PINX shall behave as an Originating PINX for ANF-CMN and the Outgoing Gateway PINX shall behave as a Terminating PINX. Any information obtained from the public ISDN concerning availability of supplementary services shall, if possible, be mapped to Common Information in the Gateway PINX and vice versa.

6.8

ANF-CMN Impact of interworking with non-ISDNs In case of interworking with a non-ISDN, the Incoming Gateway PINX shall behave as an Originating PINX for ANF-CMN and the Outgoing Gateway PINX shall behave as a Terminating PINX. Any information obtained from the non- ISDN concerning availability of supplementary services shall, if possible, be mapped to Common Information in the Gateway PINX and vice versa.

6.9

Protocol interactions between ANF-CMN and other supplementary services and ANFs This clause specifies protocol interactions with other supplementary services and ANFs for which stage 3 standards had been published at the time of publication of this Standard. For interactions with other supplementary services and ANFs for which stage 3 standards are published subsequent to the publication of this Standard, see those other stage 3 standards. NOTE Simultaneous conveyance of APDUs for ANF-CMN and another supplementary service and ANF in the same message, each in accordance with the requirements of its respective stage 3 standard, does not, on its own, constitute a protocol interaction.

6.9.1

Interactions with Calling Name Identification Presentation (CNIP) No interaction.

6.9.2

Interactions with Connected Name Identification Presentation (CONP) No interaction.

6.9.3

I n t e r a c t io n s wit h C a ll F o r wa r d in g U n c o n d it io n a l ( C F U ) The following interaction shall apply if SS-CFU is supported in accordance with ECMA-174.

6.9.3.1

A c t io n s a t a S S - C F U R e r o u t in g P I N X When executing SS-CFU, the Rerouting PINX shall include a CmnRequest invoke APDU (for the ANF-CMN solicited service) or a CmnInform invoke APDU (for the unsolicited service) in the SETUP message to the Diverted-to PINX if this was included in the SETUP message to the Served User PINX.

6.9.4

I n t e r a c t io n s wit h C a ll F o r wa r d in g Bu s y ( C F B) If SS-CFB is supported in accordance with ECMA-174, the procedures specified in 6.9.3 of this Standard shall apply, with SS-CFU replaced by SS-CFB.

6.9.5

I n t e r a c t io n s wit h C a ll F o r wa r d in g N o R e p ly ( C F N R ) The following interaction shall apply if SS-CFNR is supported in accordance with ECMA-174.

6.9.5.1

A c t io n s a t a S S - C F N R R e r o u t in g P I N X When executing SS-CFNR, the Rerouting PINX shall include a CmnInform invoke APDU (for the unsolicited service) in the SETUP message to the Diverted-to PINX if this was included in the SETUP message to the Served User PINX.

- 11 -

A CmnRequest invoke APDU (for the solicited service), if included in the SETUP message to the Served User PINX shall not be forwarded to the Diverted-to PINX. 6.9.6

Interactions with Call Deflection (CD) If SS-CD is supported in accordance with ECMA-174, in case of Call Deflection Immediate, the procedures specified in 6.9.3 of this Standard shall apply, with SS-CFU replaced by SS-CD. If SS-CD is supported in accordance with ECMA-174, in case of Call Deflection from Alert, the procedures specified in 6.9.5 of this Standard shall apply, with SS-CFNR replaced by SS-CD.

6.9.7

I n t e r a c t io n s wit h C a ll Tr a n s f e r ( C T) No interaction. NOTE Common Information may be exchanged between primary PINX and secondary PINX subsequent to call transfer. In this case the primary PINX is considered to be the originating PINX and the secondary PINX to be the terminating PINX.

6.9.8

Interactions with Completion of Call on Busy Subscriber (CCBS) No interaction.

6.9.9

I n t e r a c t i o n s wit h C o m p l e t i o n o f C a l l o n N o R e p l y ( C C N R ) No interaction.

6.9.10

I n t e r a c t io n s wit h C a ll I n t r u s io n ( C I ) No interaction.

6.9.11

Interactions with Call Offer (CO) No interaction.

6.9.12

I n t e r a c t i o n s wit h D o N o t D i s t u r b ( D N D ) No interaction.

6.9.13

Interactions with Do Not Disturb Override (DNDO) No interaction.

6.9.14

Interactions with Call Interception (CINT) The following interaction shall apply if ANF-CINT is supported in accordance with ECMA-221.

6.9.14.1

Actions at an ANF-CINT Intercepting PINX When executing ANF CINT immediate procedures, the Intercepting PINX shall include a CmnRequest invoke APDU (for the ANF-CMN solicited service) or a CmnInform invoke APDU (for the unsolicited service) in the SETUP message to the Intercepted-to PINX if this was included in the SETUP message to the Terminating PINX. When executing ANF CINT delayed procedures, the Intercepting PINX shall include a CmnInform invoke APDU (for the unsolicited service) in the SETUP message to the Intercepted-to PINX if this was included in the SETUP message to the Terminating PINX. When executing ANF CINT delayed procedures, a CmnRequest invoke APDU (for the solicited service), if included in the SETUP message to the Terminating PINX shall not be forwarded to the Intercepted-to PINX.

6.9.15

I n t e r a c t io n s wit h A d v ic e O f C h a r g e ( A O C ) No interaction.

6.9.16

I n t e r a c t io n s wit h M e s s a g e W a it in g I n d ic a t io n ( M W I ) No interaction.

6.9.17

Interactions with Path Replacement (PR) No interaction.

- 12 -

6.9.18

Interactions with Recall (RE) When executing SS-RE, the SS-RE Served User PINX may send a cmnInform invoke APDU together with the recallAnswered invoke APDU to the SS-RE Primary PINX. This cmnInform invoke APDU shall convey the Common Information of the SS-RE served user.

6.9.19

I n t e r a c t i o n s w i t h W i r e l e s s T e r m in a l M o b i l i t y , O u t g o i n g c a l l ( W T M O ) No interaction.

6.9.20

I n t e r a c t i o n s w i t h W i r e l e s s T e r m in a l M o b i l i t y , I n c o m i n g c a l l ( W T M I ) The following interaction shall apply if ANF-WTMI is supported in accordance with ECMA-304.

6.9.20.1

A c t io n s a t a n A N F - W TM I R e r o u t in g P I N X o r W TM I - D e t e c t P I N X When executing ANF-WTMI, the Rerouting PINX or (in case of forward switching) the WTMIDetect PINX shall include a CmnRequest invoke APDU (for the ANF-CMN solicited service) or a CmnInform invoke APDU (for the unsolicited service) in the SETUP message to the Visitor PINX if this was included in the SETUP message to the WTMI-Detect PINX.

6.9.21

I n t e r a c t i o n s w i t h W i r e l e s s T e r m in a l , L o c a t i o n R e g i s t r a t i o n ( W T L R ) No interaction.

6.9.22

I n t e r a c t i o n s w i t h W i r e l e s s T e r m in a l , A u t h e n t i c a t i o n ( W T A N , W T A T ) No interaction.

6.9.23

I n t e r a c t io n s wit h Tr a n s it C o u n t e r ( TC ) No interaction.

6.10

ANF-CMN Parameter values (timers) Timer T1 Timer T1 shall operate during the CMN-Wait-Answer state, if the CmnRequest invoke APDU was not sent in a SETUP message. Its purpose is to protect against an absence of response to ANF-CMN invocation for the solicited service. Timer T1 shall have a value of not less than 30 s.

- 13 -

Annex A ( n o r ma tiv e )

Protocol Implementation Conformance Statement (PICS) proforma

A.1

Introduction The supplier of a protocol implementation which is claimed to conform to this Standard 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 Standard's PICS proforma; − by the user or potential user of the implementation, as a basis for initially checking the possibility of interworking with another implementation - 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; <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).

- 14 -

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 this Standard. 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.

- 15 -

A.3

PICS proforma for ANF-CMN

A.3.1

Implementation identification Supplier Contact point for queries about the PICS Implementation Name(s) and Version(s) Other information necessary for full identification, e.g., name(s) and version(s) for machines and/or operating systems; system name(s)

Only the first three items are required for all implementations; other information may be completed as appropriate in meeting the requirement for full identification. 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 Protocol version

1.0

Addenda Implemented (if applicable) Amendments Implemented Have any exception items been required (see A.2.3)?

Date of Statement

No [ ] Yes [ ] (The answer Yes means that the implementation does not conform to this Standard)

- 16 -

A.3.3

General

Item

Question/feature

Support of ANF-CMN solicited service in an originating PINX

o.1

Yes[ ] No[ ]

Support of ANF-CMN unsolicited service in an originating PINX

o.1

Yes[ ] No[ ]

Support of ANF-CMN solicited service in a terminating PINX

o.1

Yes[ ] No[ ]

Support of ANF-CMN unsolicited service in a terminating PINX

o.1

Yes[ ] No[ ]

Support of ANF-CMN solicited service as Incoming Gateway PINX

o.1

Yes[ ] No[ ]

Support of ANF-CMN unsolicited service as Incoming Gateway PINX

o.1

Yes[ ] No[ ]

Support of ANF-CMN solicited service as Outgoing Gateway PINX

o.1

Yes[ ] No[ ]

Support of ANF-CMN unsolicited service as Outgoing Gateway PINX

o.1

Yes[ ] No[ ]

A.3.4

References

Status

N/A

Support

Procedures

Item

Question/feature

References

Status

N/A

Support

Support of relevant procedures as specified in ECMA-143 and ECMA-165 for an originating PINX

6.2.1

c.1

[]

m:Yes[ ]

Support of relevant procedures as specified in ECMA-143 and ECMA-165 for a terminating PINX

6.2.2

c.2

[]

m:Yes[ ]

Support of signalling procedures for the invocation of the solicited service at call establishment at the originating PINX

6.6.1

A1: m

[]

m:Yes[ ]

Support of signalling procedures for the invocation of the solicited service in active call at the originating PINX

6.6.1

A1: o

[]

Yes[ ] No[ ]

Support of signalling procedures for responding to the solicited service at the originating PINX

6.6.1

A1: m

[]

m:Yes[ ]

Support of signalling procedures for the invocation of the unsolicited service at call establishment at the originating PINX

6.6.1

A2: m

[]

m:Yes[ ]

Support of signalling procedures for the invocation of the unsolicited service in active call at the originating PINX

6.6.1

A2: o

[]

Yes[ ] No[ ]

- 17 -

Support of signalling procedures for the receipt of the unsolicited service at the originating PINX

6.6.1

A2: m

[]

m:Yes[ ]

Support of signalling procedures for the invocation of the solicited service at call establishment at the terminating PINX

6.6.2

A3: m

[]

m:Yes[ ]

B10

Support of signalling procedures for the invocation of the solicited service in active call at the terminating PINX

6.6.2

A3: o

[]

Yes[ ] No[ ]

B11

Support of signalling procedures for responding to the solicited service at the terminating PINX

6.6.2

A3: m

[]

m:Yes[ ]

B12

Support of signalling procedures for the invocation of the unsolicited service at call establishment at the terminating PINX

6.6.2

A4: m

[]

m:Yes[ ]

B13

Support of signalling procedures for the invocation of the unsolicited service in active call at the terminating PINX

6.6.2

A4: o

[]

Yes[ ] No[ ]

B14

Support of signalling procedures for the receipt of the unsolicited service at the terminating PINX

6.6.2

A4: m

[]

m:Yes[ ]

B15

Support of signalling procedures for the interworking with public ISDNs

6.7

c.3

[]

m:Yes[ ]

B16

Support of signalling procedures for the interworking with non-ISDNs

6.8

c.3

[]

m:Yes[ ]

References

Status

N/A

Support

c.1 = IF(A1 OR A2 OR A5 OR A6) THEN m, ELSE N/A c.2 = IF(A3 OR A4 OR A7 OR A8) THEN m, ELSE N/A c.3 = IF(A5 OR A6 OR A7 OR A8) THEN m, ELSE N/A

A.3.5

Coding

Item

Question/feature

Sending of CmnRequest invoke and receipt of CmnRequest return result

6.3.1

c.1

[]

m:Yes[ ]

Receipt of CmnRequest invoke and sending of CmnRequest return result

6.3.1

c.2

[]

m:Yes[ ]

Sending of CmnInform invoke

6.3.1

c.3

[]

m:Yes[ ]

Receipt of CmnInform invoke

6.3.1

c.4

[]

m:Yes[ ]

c.1 = IF(B3 OR B4 OR B9 OR B10) THEN m, ELSE N/A c.2 = IF(B5 OR B11) THEN m, ELSE N/A c.3 = IF(B6 OR B7 OR B12 OR B13) THEN m, ELSE N/A c.4 = IF(B8 OR B14) THEN m, ELSE N/A

- 18 -

A.3.6

Timer

Item

Question/feature

References

Status

N/A

Support

Support of Timer T1 at an originating PINX

6.10

B4: m

[]

m:Yes[ ]

Support of Timer T1 at a terminating PINX

6.10

c.1

[]

m:Yes[ ]

References

Status

N/A

Support

[]

Yes[ ] No[ ]

E1: m

[]

m:Yes[ ]

Status

N/A

Support

[]

Yes[ ] No[ ]

F1: m

[]

m:Yes[ ]

Status

N/A

Support

[]

Yes[ ] No[ ]

6.9.5

G1: m

[]

m:Yes[ ]

References

Status

N/A

Support

[]

Yes[ ] No[ ]

H1: m

[]

m:Yes[ ]

c.1 = IF(B9 OR B10) THEN m, ELSE N/A

A.3.7

Interactions between ANF-CMN and SS-CFU

Item

Question/feature

Support of SS-CFU as a rerouting PINX

Support of procedures for interaction with SS-CFU

A.3.8

Interactions between ANF-CMN and SS-CFB

Item

Question/feature

Support of SS-CFB as a rerouting PINX

Support of procedures for interaction with SS-CFB

A.3.9

6.9.3

References

6.9.4

Interactions between ANF-CMN and SS-CFNR

Item

Question/feature

Support of SS-CFNR as a rerouting PINX

Support of procedures for interaction with SS-CFNR

References

A.3.10 Interactions between ANF-CMN and SS-CD Item

Question/feature

Support of SS-CD as a rerouting PINX

Support of procedures for interaction with SS-CD

6.9.6

- 19 -

A.3.11 Interactions between ANF-CMN and SS-CINT Item

Question/feature

Support of SS-Call Interception as an intercepting PINX

Support of procedures for interaction with SS-CINT

References

Status

N/A

Support

[]

Yes[ ] No[ ]

I1: m

[]

m:Yes[ ]

Status

N/A

Support

[]

Yes[ ] No[ ]

J1: m

[]

m:Yes[ ]

Status

N/A

Support

[]

Yes[ ] No[ ]

K1: o

[]

Yes[ ] No[ ]

6.9.14

A.3.12 Interactions between ANF-CMN and ANF-WTMI Item

Question/feature

Support of ANF-WTMI as a rerouting PINX or (in case of forward switching) as a WTMI detect PINX

Support of procedures for interaction with ANF-WTMI

References

6.9.20

A.3.13 Interactions between ANF-CMN and SS-RE Item

Question/feature

Support of SS-RE as a Served User PINX

Support of procedures for interaction with SS-RE

References

6.9.18

- 20 -

- 21 -

Annex B ( in f o r ma tiv e )

Examples of message sequences

This annex describes some typical message flows for ANF-CMN. The following conventions are used in the figures of this annex. 1. The following notation is used: Basic call message containing ANF-CMN information Call related signalling message containing ANF-CMN information Symbolic primitive carrying ANF-CMN information xxx.inv

Invoke APDU for operation xxx

xxx.rr

Return result APDU for operation xxx

2. The figures show messages exchanged via Protocol Control between PINXs involved in ANF-CMN. Only messages relevant to ANF-CMN are shown. 3. Only the relevant information content (e.g. remote operation APDUs, information elements) is listed below each message name. The Facility information elements containing remote operation APDUs are not explicitly shown. Information with no impact on ANF-CMN is not shown. 4. Some interactions with users are included in the form of symbolic primitives. The actual protocol at the terminal equipment interface is outside the scope of this Standard.

- 22 -

B.1

Example message sequence for normal operation of ANF-CMN for the solicited service Figure B.1 shows an example of normal operation of ANF-CMN for the solicited service using basic call messages.

ANF-CMN user

Originating PINX

CMN_REQ req

Transit PINX

SETUP Cmn-Request.inv

ALERTING CMN_REQ conf

Cmn-Request.rr (cmn)

Terminating PINX

SETUP

ANF-CMN user

CMN_REQ ind

Cmn-Request.inv

ALERTING

CMN_REQ resp

Cmn-Request.rr (cmn)

F ig u r e B. 1 - Ex a m p le o f n o r m a l o p e r a t io n o f A N F - C M N ( s o l i c i t e d s e r v i c e )

- 23 -

B.2

Example message sequences for normal operation of ANF-CMN for the unsolicited service Figure B.2 shows an example of normal operation of ANF-CMN for the unsolicited service using the FACILITY message in forward direction. Figure B.3 shows an example of mutual exchange of common information during call establishment using the unsolicited service.

ANF-CMN user

Originating PINX

CMN_INF req

Transit PINX

FACILITY

Terminating PINX

FACILITY

Cmn-Inform.inv (cmn)

ANF-CMN user

CMN_INF ind

Cmn-Inform.inv (cmn)

Figure B.2 - Example of normal operation of ANF-CMN in forward direction (unsolicited service)

ANF-CMN user

Originating PINX

CMN_INF req

Transit PINX

SETUP Cmn-Inform.inv (cmn)

ALERTING CMN_INF ind

Cmn-Inform.inv (cmn)

Terminating PINX

SETUP

ANF-CMN user

CMN_INF ind

Cmn-Inform.inv (cmn)

ALERTING

CMN_INF req

Cmn-Inform.inv (cmn)

Figure B.3 - Example of normal operation of ANF-CMN in both directions (unsolicited service)

- 24 -

B.3

Example message sequence for normal operation of ANF-CMN for the combined service Figure B.4 shows an example of normal operation of ANF-CMN for the combined solicited and unsolicited service during call establishment.

ANF-CMN user

Originating PINX

CMN_INF req CMN_REQ req

Transit PINX

SETUP Cmn-Inform.inv (cmn) Cmn-Request.inv

ALERTING CMN_REQ conf

Cmn-Request.rr (cmn)

Terminating PINX

SETUP Cmn-Inform.inv (cmn) Cmn-Request.inv

ALERTING

ANF-CMN user

CMN_INF ind CMN_REQ ind

CMN_REQ resp

Cmn-Request.rr (cmn)

F ig u r e B. 4 - Ex a m p le o f n o r m a l o p e r a t io n o f A N F - C M N (solicited and unsolicited service combined)

- 25 -

Annex C ( in f o r ma tiv e )

Specification and Description Language (SDL) representation of procedures

The diagrams in this annex use the Specification and Description Language defined in ITU-T Recommendation Z.100 (1999). Each diagram represents the behaviour of an ANF-CMN Supplementary Service Control entity at a particular type of PINX. In accordance with the protocol model described in ECMA-165, the Supplementary Service Control entity uses, via the Coordination Function, the services of Generic Functional Procedures Control and Basic Call Control. Where an output symbol represents a primitive to the Coordination Function, and that primitive results in a message being sent, the output symbol bears the name of the message and any remote operations APDU(s) or notification(s) contained in that message. In the case of a message specified in ECMA-143, basic call actions associated with the sending of that message are deemed to occur. Where an input symbol represents a primitive from the Coordination Function, and that primitive is the result of a message being received, the input symbol bears the name of the message and any remote operations APDU(s) or notification(s) contained in that message. In the case of a message specified in ECMA-143, basic call actions associated with the receipt of that message are deemed to have occurred. The following abbreviations are used: inv.

invoke APDU

res.

return result APDU

err.

return error APDU

rej.

reject APDU

C.1

SDL representation of ANF-CMN at the Originating PINX Figure C.1 shows the behaviour of an ANF-CMN Supplementary Service Control entity within the Originating PINX. Input signals from the left and output signals to the left represent primitives to and from the user. Input signals from the right and output signals to the right represent primitives to and from the Coordination Function in respect of messages received and sent. Also protocol timer expiry is indicated by an input signal from the right.

- 26 -

CMNIdle

CMN_INF Request

CMN_REQ Request

Get CMN

message with CmnInform inv.

CMNIdle

CMN_INF + CMN_REQ Request

message with CmnRequest inv.

Get CMN

message with CmnInform inv.

message with CmnRequest res.

message with CmnRequest inv.

CMNIdle

message with CmnInform inv.

CMN_INF Indication

CMNIdle

This may be the same message.

Start Timer T1, if applicable

CMNWait-Answer

message with CmnRequest inv.

T1 only started if CmnRequest inv. is sent in FACILITY message

message with CmnRequest res.

message with CmnRequest rej.

basic call cleared

Stop Timer T1, if running

CMN_REQ Confirm

CMN-Error Indication

CMNIdle

CONNECT without CmnReq. res.

Timer T1 expiry

message with CmnRequest inv.

Get CMN

CMN-Error Indication

message with CmnRequest res.

CMNWait-Answer

F ig u r e C . 1 - S D L R e p r e s e n t a t io n o f A N F - C M N a t t h e O r ig in a t in g P I N X

message with CmnInform inv.

CMN_INF Indication

CMNWait-Answer

- 27 -

C.2

SDL representation of ANF-CMN at the Terminating PINX Figure C.2 shows the behaviour of an ANF-CMN Supplementary Service Control entity within the Terminating PINX. Input signals from the right and output signals to the right represent primitives to and from the user. Input signals from the left and output signals to the left represent primitives to and from the Coordination Function in respect of messages received and sent. Also protocol timer expiry is indicated by an input signal from the left.

- 28 -

CMNIdle

message with CmnRequest inv.

Get CMN

message with CmnInform inv.

CMN_INF Indication

message with CmnRequest res.

CMNIdle

message with CmnRequest inv.

Get CMN, if available

message with CmnInform inv.

CMN_INF Indication

CMNWait-Answer

CMN_REQ Request

CMN_INF + CMN_REQ Request

Get CMN

message with CmnInform inv.

CMNIdle

message with CmnRequest res.

CMNWait-Answer

CMN_INF Request

message with CmnRequest inv.

Start Timer T1

CMNWait-Answer

This may be the same message

message with CmnRequest res.

message with CmnRequest rej.

basic call cleared

Stop Timer T1

CMN_REQ Confirm

CMN-Error Indication

Timer T1 expiry

CMN-Error Indication

CMNIdle

Figure C.2 - SDL Representation of ANF-CMN at the Terminating PINX

- 29 -

Annex D ( n 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 second edition of ECMA-251, i.e. based on ITU-T Recommendations X.208 / X.209. Starting with the third edition the ASN.1 modules within ECMA-251 comply with ITU-T Recommendations X.680 / X.690. Please note that regardless of which version of these modules is used as a base of a QSIG implementation, the line encoding remains unchanged. Changes in future editions to modules based on X.680 / X.690 ASN.1 are not reflected in the modules in this annex. Ta b le D . 1 - C o m m o n - I n f o r m a t io n - O p e r a t io n s – b a s e d o n I TU - T R e c s . X . 2 0 8 / X . 2 0 9 Common-Information-Operations {iso (1) standard (0) pss1-common-information (15772) operations (0)} DEFINITIONS EXPLICIT TAGS ::= BEGIN IMPORTS

OPERATION, ERROR FROM Remote-Operation-Notation {joint-iso-ccitt (2) remote-operations (4) notation (0)} Extension FROM Manufacturer-specific-service-extension-definition {iso (1) standard (0) pss1-generic-procedures (11582) msi-definition (0)};

CmnRequest

::= OPERATION ARGUMENT RESULT

DummyArg CmnArg

::= OPERATION ARGUMENT

CmnArg

CmnInform

CmnArg

- 30 -

Ta b le D . 1 - C o m m o n - I n f o r m a t io n - O p e r a t io n s – b a s e d o n I TU - T R e c s . X . 2 0 8 / X . 2 0 9 ( c o n t in u e d ) extension

CHOICE { single [7] IMPLICIT Extension, multiple [8] IMPLICIT SEQUENCE OF Extension } OPTIONAL

} DummyArg

::=

CHOICE { null single multiple }

FeatureIdList

NULL, [1] IMPLICIT Extension, [2] IMPLICIT SEQUENCE OF Extension

ssCIforcedRelease ssCIisolation ssCIwaitOnBusy

(6), (7), (8),

-- Call Intrusion -- meaningful only in backward direction -- meaningful only in backward direction -- meaningful only in backward direction

ssAOCsupportChargeRateProvAtGatewPinx ssAOCsupportInterimChargeProvAtGatewPinx ssAOCsupportFinalChargeProvAtGatewPinx

anfPRsupportedAtCooperatingPinx

-- Advice of Charge -- meaningful only in -- backward direction (10), -- meaningful only in -- backward direction (11), -- meaningful only in -- backward direction (9),

(12), -- Path replacement -- meaningful both in forward & -- backward direction

- 31 -

Ta b le D . 1 - C o m m o n - I n f o r m a t io n - O p e r a t io n s – b a s e d o n I TU - T R e c s . X . 2 0 8 / X . 2 0 9 ( c o n c lu d e d ) anfCINTcanInterceptImmediate anfCINTcanInterceptDelayed

-- Call Interception (13), -- meaningful only in -- forward direction (14), -- meaningful only in -- forward direction

anfCTMIreRoutingSupported

(15)

anfPUMIreRoutingSupported

(16)

ssSSCTreRoutingSupported

(17)

-- Incoming CTM call -- meaningful only in -- forward direction -- Incoming PUM call -- meaningful only in -- forward direction -- Single Step Call Transfer rerouting -- supported -- meaningful both in forward and -- backward direction during call -- establishment

} (SIZE (1..64)) EquipmentId

::= SEQUENCE { nodeId groupId unitId }

[1] IMPLICIT IA5String (SIZE (1..10)) OPTIONAL, [2] IMPLICIT IA5String (SIZE (1..10)) OPTIONAL, [3] IMPLICIT IA5String (SIZE (1..10)) OPTIONAL

::= ENUMERATED { unknown extension pisnAttendant emergExt }

(0), (1), (2), (3)

CmnRequest CmnInform

::= localValue 84 ::= localValue 85

END

-- of Common-Information-Operations

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 Standard 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-251 — Private Integrated Services Network (PISN) - Inter-exchange signalling protocol - Common information additional network feature (QSIG-CMN) (December 2001)

Related documents