Standard ECMA-344 June 2003
International
Standardizing
Information
and
Communication
Systems
Private Integrated Services Network (PISN) – Inter-Exchange Signalling Protocol – Make Call Request Supplementary Service
Phone/Fax: +41 22 849.60.00/01
-
http://www.ecma-international.org
-
mailto: h e l p d e s k @ e c m a . c h
.
Standard ECMA-344 June 2003
International
Standardizing
Information
and
Communication
Systems
Private Integrated Services Network (PISN) – Inter-Exchange Signalling Protocol – Make Call Request Supplementary Service (QSIG-MCR)
Phone/Fax: +41 22 849.60.00/01 IW
Ecma-344.doc
02-07-03 11,39
-
http://www.ecma-international.org
-
mailto: h e l p d e s k @ e c m a . c h
.
Brief History
This Standard is one of a series of ECMA Standards defining services and signalling protocols applicable to Private Integrated Services Networks (PISNs). The series uses ISDN concepts as developed by ITU-T and conforms to the framework of International Standards for Open Systems Interconnection as defined by ISO/IEC. It has been produced under ETSI work item DTS/ECMA-00232. This particular Standard specifies the signalling protocol for use at the Q reference point in support of the Make Call Request supplementary service. The protocol defined in this Standard forms part of the PSS1 protocol (informally known as QSIG). 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.
This ECMA Standard has been adopted by the General Assembly of June 2003.
- i -
Table of contents 1
Scope
1
2
Conformance
1
3
References (normative)
1
4
Definitions
2
E x te r n a l d e f in itio n s
2
4 . 2 O th e r d e f in itio n s 4.2.1 Co - o p e r a tin g P I N X 4.2.2 Co - o p e r a tin g U s e r 4.2.3 Destination PINX 4.2.4 Destination User 4.2.5 Ma k e Ca ll Re q u e s t 4.2.6 Original Call 4.2.7 Requested Call 4.2.8 Re q u e s tin g P I N X 4.2.9 Re q u e s tin g U s e r
2 2 2 2 2 2 2 3 3 3
5
List of acronyms
3
6
Signalling Protocol for the support of SS-MCR
3
S S - MCR d e s c r ip tio n
3
4.1
6.1
6 . 2 S S - MCR 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 Re q u e s tin g P I N X 6.2.2 Re q u ir e me n ts o n a Co - o p e r a tin g P I N X 6.2.3 Re q u ir e me n ts o n a D e s tin a tio n P I N X 6.2.4 Re q u ir e me n ts o n a T r a n s it P I N X
3 3 3 4 4
6 . 3 S S - MCR c o d in g r e q u ir e me n ts 6.3.1 Operations 6.3.2 I n f o r ma t i o n e l e me n t s 6.3.3 Messages
5 5 8 8
6 . 4 S S - MCR s ta te d e f in itio n s 6.4.1 States at the Requesting PINX 6.4.2 States at the Co-operating PINX 6.4.3 States at the Destination PINX
8 8 8 8
6 . 5 S S - MCR s ig n a llin g p r o c e d u r e s 6.5.1 A c tio n s a t th e Re q u e s tin g P I N X 6.5.2 A c tio n s a t th e Co - o p e r a tin g P I N X 6.5.3 Actions at the Destination PINX 6.5.4 Actions at a Transit PINX
9 9 10 11 11
- ii -
6.6
S S - MCR imp 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
11
6.7
S S - MCR imp a c t o f in te r w o r k in g w ith n o n - I S D N s
11
6 . 8 P r o to c o l in te r a c tio n s b e tw e e n S S - MCR a n 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.8.1 Calling Line Identification Presentation (SS-CLIP) 6.8.2 C o n n e c t e d L i n e I d e n t i f i c a t io n P r e s e n ta tio n ( S S - CO L P ) 6.8.3 Ca llin g /Co n n e c te d L in e I d e n tif ic a tio n Re s tr ic tio n ( S S - CL I R) 6.8.4 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 ( S S - C N I P ) 6.8.5 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 ( S S - C N I R ) 6.8.6 C o n n e c t e d N a me I d e n t i f i c a t io n P r e s e n ta tio n ( S S - CO N P ) 6.8.7 C o mp l e t i o n o f C a l l t o B u s y S u b s c r i b e r ( S S - C C B S ) 6.8.8 Co mp le tio n o f Ca ll o n N o Re p ly ( S S - CCN R) 6.8.9 Call Transfer (SS-CT) 6.8.10 Ca ll F o r w a r d in g U n c o n d itio n a l ( S S - CF U ) 6.8.11 C a l l F o r w a r d in g B u s y ( S S - C F B ) 6.8.12 Ca ll F o r w a r d in g N o Re p ly ( S S - CF N R) 6.8.13 Call Deflection (SS-CD) 6.8.14 P a t h R e p l a c e me n t ( A N F - P R ) 6.8.15 Call Offer (SS-CO) 6.8.16 Ca ll I n tr u s io n ( S S - CI ) 6.8.17 Do not Disturb (SS-DND) 6.8.18 Do not Disturb Override (SS-DNDO) 6.8.19 A d v ic e o f Ch a r g e ( S S - A O C) 6.8.20 Recall (SS-RE) 6.8.21 Call Interception (ANF-CINT) 6.8.22 T r a n s it Co u n te r ( A N F - T C) 6.8.23 R o u te R e s t r i c t i o n C l a s s ( A N F - R R C ) 6.8.24 Me s s a g e W a itin g I n d ic a tio n ( S S - MW I ) 6.8.25 W ir e le s s T e r min a l L o c a tio n Re g is tr a tio n ( S S - W T L R) 6.8.26 W ir e l e s s T e r mi n a l I n c o min g C a l l ( A N F - W T MI ) 6.8.27 W ir e l e s s T e r mi n a l O u t g o in g C a l l ( A N F - W T M O ) 6.8.28 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 o f a W T M U s e r ( S S - W T A T ) 6.8.29 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 o f t h e P I S N ( S S - W T A N ) 6.8.30 P r i v a t e U s e r M o b i l i t y I n c o min g C a l l ( A N F - P U M I ) 6.8.31 P r i v a t e U s e r M o b i l i t y O u t g o in g C a l l ( A N F - P U M O ) 6.8.32 P r i v a t e U s e r M o b i l i t y R e g is t r a t i o n ( S S - P U M R ) 6.8.33 C o mmo n I n f o r ma t i o n ( A N F - C MN ) 6.8.34 Call Priority Interruption (Protection) (SS-CPI(P)) 6.8.35 Single Step Call Transfer (SS-SSCT) 6.3.36 S i mp l e D i a l o g ( S S - S D ) 6.8.37 G lo b a l Ca ll I d e n tif ic a tio n a n d Ca ll L in k a g e ( A N F - CI D L ) 6.8.38 Short Message Service (SS-SMS) 6.8.39 Me s s a g e Ce n tr e Mo n ito r in g ( S S - MCM) 6.8.40 Ma ilb o x I d e n tif ic a tio n ( S S - MI D )
11 11 12 12 12 12 12 12 12 12 12 12 12 12 12 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 13 14 14 14 14 14 14 14 14
6 . 9 S S - MC R p a r a me t e r v a l u e s ( T i me r s ) 6.9.1 T i me r T 1
14 14
- iii -
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
15
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
21
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 g ua 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
27
1
Scope This Standard specifies the signalling protocol for the support of the Make Call Request supplementary service (SS-MCR) at the Q reference point between Private Integrated services Network eXchanges (PINXs) connected together within a Private Integrated Services Network (PISN). Supplementary service MCR enables a Requesting User to request a Co-operating User to establish a new Requested Call to a Destination User. This new Requested Call between the Co-operating and Destination User can be either a Basic call or a Call Independent Signalling Connection. The Q reference point is defined in ECMA-133. Service specifications are produced in three stages and according to the method specified 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-343. The signalling protocol for SS-MCR 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 SS-MCR and other supplementary services and ANFs. This Standard is applicable to PINXs, which can interconnect to form a PISN.
2
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 SS-MCR 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.
3
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-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-343
Private Integrated Services Network (PISN) – Specification, Functional Model and Information Flows - Make Call Request Supplementary Service
ECMA-345
Private Integrated Services Network (PISN) – Use of QSIG for Message Centre Access (MCA) Profile Standard
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)
- 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.950 Digital Subscriber Signalling System No. 1 (DSS 1) – Supplementary services protocols, structure and general principles (2000) ITU-T Rec. Z.100 Specification and Description Language (1999)
4
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
− Application Protocol Data Unit (APDU)
(ECMA-165)
− Call, Basic call
(ECMA-165)
− Call Independent Signalling Connection
(ECMA-165)
− Call-Independent
(ECMA-165)
− Gateway PINX
(ECMA-165)
− Originating PINX
(ECMA-165)
− 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-165)
− Transit PINX
(ECMA-165)
Other definitions
4.2.1
C o - o p e r a t in g P I N X The PINX where the Co-operating User is located.
4.2.2
C o - o p e r a t in g U s e r The user who receives a Make Call Request and who shall set up a new Requested Call to the Destination User.
4.2.3
D e s t in a t io n P I N X The PINX where the Destination User is located.
4.2.4
D e s t in a t io n U s e r The called user of the Requested Call i.e. the user to whom the Co-operating User shall establish a Requested Call.
4.2.5
M a k e C a ll R e q u e s t A request from the Requesting User for a new call (i.e. Requested Call) between a Co-operating User and a Destination User.
4.2.6
O r ig in a l C a ll The call between the Requesting User and the Co-operating User. The Original Call can be either a Basic call or a Call Independent Signalling Connection and is correlated with the Requested Call.
- 3 -
4.2.7
R e q u e s t e d C a ll The call between the Co-operating User and the Destination User that is established by the Co-operating User due to a Make Call Request from the Requesting User. The Requested Call can either be a Basic call (with a specific Basic Service) or a Call Independent Signalling Connection and is correlated with the Original Call.
4.2.8
R e q u e s t in g P I N X The PINX where the Requesting User is located.
4.2.9
R e q u e s t in g U s e r The User who sends a Make Call Request to the Co-operating User with the request to establish a specific Requested Call to the Destination User.
5
List of acronyms
6
ANF
Additional Network Feature
APDU
Application Protocol Data Unit
ASN.1
Abstract Syntax Notation One
CISC
Call Independent Signalling Connection
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
SS
Supplementary Service
SS-MCR
Supplementary Service Make Call Request
Signalling Protocol for the support of SS-MCR
6.1
SS-MCR description The supplementary service MCR enables a Requesting User to request a Co-operating User to establish a new Requested Call to a Destination User. This new Requested Call between the Co-operating User and the Destination User can either be a Basic call or a Call Independent Signalling Connection. The new Requested Call is correlated to the Original Call between the Requesting and Co-operating User.
6.2 6.2.1
SS-MCR operational requirements Requirements on a Requesting PINX Call establishment procedures for the incoming and outgoing side of an inter-PINX link and call release procedures, as specified in ECMA-143, shall apply. Generic procedures for call-related control of supplementary services, as specified in ECMA-165 for an End PINX, shall apply. Generic procedures for the call-independent control (connection-oriented) of supplementary services, as specified in ECMA-165 for an Originating PINX and for a Terminating PINX, shall apply.
6.2.2
Requirements on a Co-operating PINX Call establishment procedures for the incoming and outgoing side of an inter-PINX link and call release procedures, as specified in ECMA-143, shall apply.
- 4 -
Generic procedures for call-related control of supplementary services, as specified in ECMA-165 for an End PINX, shall apply. Generic procedures for the call-independent control (connection-oriented) of supplementary services, as specified in ECMA-165 for a Terminating PINX and for an Originating PINX, shall apply. 6.2.3
Requirements on a Destination PINX Call establishment procedures for the incoming and outgoing side of an inter-PINX link and call release procedures, as specified in ECMA-143, shall apply. Generic procedures for call-related control of supplementary services, as specified in ECMA-165 for an End PINX, shall apply. Generic procedures for the call-independent control (connection-oriented) of supplementary services, as specified in ECMA-165 for a Terminating PINX and for an Originating PINX, shall apply.
6.2.4
Requirements on a Transit PINX Basic call procedures specified in ECMA-143 for a Transit PINX shall apply. Generic procedures for call-related control of supplementary services, as specified in ECMA-165 for a Transit PINX, shall apply. Generic procedures for the call-independent control (connection-oriented) of supplementary services, as specified in ECMA-165 for a Transit PINX, shall apply.
- 5 -
6.3 6.3.1
SS-MCR coding requirements 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. Table 1 – Operations in support of SS-MCR
SS-MCR-Operations-asn97 {iso (1) identified-organization (3) icd-ecma (12) standard (0) qsig-make-call-request (344) make-call-request-operations (0)} 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) } Name FROM Name-Operations-asn1-97 { iso (1) standard (0) pss1-name (13868) name-operations-asn1-97 (1) } BasicService FROM Call-Diversion-Operations-asn1-97 { iso (1) standard (0) pss1-call-diversion (13873) call-diversion-operations-asn1-97 (1) } basicServiceNotProvided, supplementaryServiceInteractionNotAllowed, userNotSubscribed FROM General-Error-List {itu-t (0) recommendation (0) q (17) 950 (950) general-error-list (1)} PresentedAddressUnscreened FROM Addressing-Data-Elements-asn1-97 { iso (1) standard (0) pss1-generic-procedures (11582) addressing-data-elements-asn1-97 (20) } CallIdentity, establishmentFailure FROM Path-Replacement-Operations-asn1-97 {iso (1) standard (0) pss1-path-replacement (13874) pr-operations-asn1-97(1)} ; Make-Call-Request-Operations OPERATION::= { mCRequest | mCAlerting | mCInform }
- 6 -
Table 1 – Operations in support of SS-MCR (continued) mCRequest
OPERATION ::= { ARGUMENT MCRequestArg RESULT MCRequestResult ERRORS {userNotSubscribed| basicServiceNotProvided| supplementaryServiceInteractionNotAllowed| invalidDestinationNumber| invalidCooperationNumber| mCRequestNotAllowed| mCExecutionNotAllowed| mCDestUserBusy| mCCoopUserBusy| mCCoopUserRejected| establishmentFailure| unspecified} CODE local: 112 }
mCInform
OPERATION ::= { ARGUMENT MCInformArg RETURN RESULT FALSE ALWAYS RESPONDS FALSE ERRORS {userNotSubscribed| basicServiceNotProvided| supplementaryServiceInteractionNotAllowed| invalidDestinationNumber| mCExecutionNotAllowed| mCDestUserBusy| unspecified} CODE local: 113 }
mCAlerting
OPERATION ::= { ARGUMENT MCAlertingArg RETURN RESULT FALSE ALWAYS RESPONDS FALSE CODE local: 114 }
MCRequestArg ::= SEQUENCE { callType retainOrigCall destinationAddress requestingAddress cooperatingAddress correlation extensions ... }
CallType, BOOLEAN DEFAULT TRUE, PresentedAddressUnscreened, [0] PresentedAddressUnscreened OPTIONAL, [1] PresentedAddressUnscreened OPTIONAL, Correlation, MCRExtensions OPTIONAL,
MCRequestResult ::= { extensions ... }
MCRExtensions
SEQUENCE OPTIONAL,
- 7 -
Table 1 – Operations in support of SS-MCR (concluded) MCInformArg
::= SEQUENCE { requestingAddress cooperatingAddress correlation extensions ... }
[0] PresentedAddressUnscreened OPTIONAL, [1] PresentedAddressUnscreened OPTIONAL, Correlation, MCRExtensions OPTIONAL,
MCAlertingArg ::= SEQUENCE { correlation Correlation, extensions MCRExtensions ... } CallType ::= CHOICE { basicService BasicService, cisc NULL } ::= SEQUENCE { correlationData CallIdentity, correlationReason CorrelationReason } CorrelationReason ::= INTEGER { unknown (0), mCACommunication (1), cTIApplication (2) } (0..255)
OPTIONAL,
Correlation
OPTIONAL
MCRExtensions ::= CHOICE { none NULL, single [0] IMPLICIT Extension { { MakeCallRequestExtension } } , multiple [1] IMPLICIT SEQUENCE OF Extension { { MakeCallRequestExtension } } } MakeCallRequestExtension EXTENSION::= {...} invalidDestinationNumber invalidCooperationNumber mCRequestNotAllowed mCExecutionNotAllowed mCDestUserBusy mCCoopUserBusy mCCoopUserRejected unspecified
END
ERROR ::= {CODE local : 1030} ERROR ::= {CODE local : 1031} ERROR ::= {CODE local : 1032} ERROR ::= {CODE local : 1033} ERROR ::= {CODE local : 1034} ERROR ::= {CODE local : 1035} ERROR ::= {CODE local : 1036} ERROR ::= {PARAMETER Extension { { MakeCallRequestExtension } } CODE local : 1008 }
-- of SS-MCR-Operations
- 8 -
6.3.2 Information elements 6.3.2.1 Facility information element The operations defined in 6.3.1 shall be coded in the Facility information element in accordance with ECMA-165. When conveying the invoke APDUs of the operations defined in 6.3.1, the destination Entity data element of the NFE shall contain the value endPINX. When conveying the invoke APDU of operation mCRequest defined in 6.3.1, the interpretation APDU shall be set to value rejectAnyUnrecognisedInvokePdu or shall be omitted. When conveying the invoke APDU of operation mCInform or mCAlerting defined in 6.3.1, the interpretation APDU shall be set to value discardAnyUnrecognisedInvokePdu. 6.3.2.2 6.3.3
6.4
Other information elements Any other information element shall be coded in accordance with ECMA-143. Messages The Facility information element shall be conveyed in messages as specified in clause 10 of ECMA-165.
SS-MCR state definitions
6.4.1
S t a t e s a t t h e R e q u e s t in g P I N X The procedures for the Requesting PINX are written in terms of the following conceptual states existing within the SS-MCR Control entity in that PINX in association with a particular SS-MCR request from the Requesting User.
6.4.1.1
S t a t e M C R - I d le SS-MCR is not operating.
6.4.1.2
S t a t e M C R - A c t iv e SS-MCR is operating. A mCRequest invoke APDU was sent to the Co-operating PINX. The Requesting PINX awaits the result of this operation.
6.4.2
S t a t e s a t t h e C o - o p e r a t in g P I N X The procedures for the Co-operating PINX are written in terms of the following conceptual states existing within the SS-MCR Control entity in that PINX.
6.4.2.1
S t a t e M C R - I d le SS-MCR is not operating.
6.4.2.2
S t a t e M C R - A c t iv e SS-MCR is operating. Call establishment of the requested call is initiated by the Co-operating PINX and a mCInform invoke APDU was sent towards the Destination PINX. The Co-operating PINX awaits the result of the call establishment.
6.4.3
S t a t e s a t t h e D e s t in a t io n P I N X No SS-MCR specific states required.
- 9 -
6.5
SS-MCR signalling procedures Examples of message sequences are shown in annex B.
6.5.1
A c t io n s a t t h e R e q u e s t in g P I N X The SDL representation of procedures at the Requesting PINX is shown in clause C.1 of annex C.
6.5.1.1 Normal procedures 6 . 5 . 1 . 1 . 1 A c t iv a t io n / d e a c t iv a t io n / in t e r r o g a t io n Not applicable. 6.5.1.1.2
I n v o c a t io n a n d o p e r a t io n In state MCR-Idle, due to a request from the Requesting User, the Requesting PINX shall send a mCRequest invoke APDU to the Co-operating PINX, start Timer T1 and enter state MCR-Active. For the transport of this mCRequest invoke APDU the Requesting PINX shall either use the Call Reference of an already existing Basic Call or an already existing Call Independent Signalling Connection or set up a new Call Independent Signalling Connection in accordance with the procedures specified in 7.3 of ECMA-165. In the case of set up of a new Call Independent Signalling Connection, the Requesting PINX is responsible for the clearing of this connection. The elements callType, retainOrigCall, destinationAddress, requestingAddress, cooperatingAddress and correlation of the mCRequest invoke APDU shall be set according to the request of the Requesting User. NOTE Provision of element cooperatingAddress is required when a new CISC is to be established. If mCRequest.inv is sent on the call reference of an already existing connection, the Co-operating User is the User served on this call reference at the Co-operating PINX. In state MCR-Active, on receipt of a mCAlerting invoke APDU from the Co-operating PINX, the Requesting PINX may indicate the result to the Requesting User, if the capability exists, and remain in state MCR-Active. In state MCR-Active, on receipt of a mCRequest return result APDU from the Co-operating PINX, the Requesting PINX shall stop Timer T1, may indicate the result to the Requesting User if the capability exists, and shall enter state MCR-Idle.
6.5.1.2 Ex c e p t io n a l p r o c e d u r e s 6 . 5 . 1 . 2 . 1 A c t iv a t io n / d e a c t iv a t io n / in t e r r o g a t io n Not applicable. 6.5.1.2.2
I n v o c a t io n a n d o p e r a t io n In state MCR-Active, on receipt of either a mCRequest reject APDU or a mCRequest return error APDU from the Co-operating PINX or on Timer T1 expiry, the Requesting PINX may send an appropriate error indication to the Requesting User if the capability exists, shall stop Timer T1 if running, and shall enter state MCR-Idle.
- 10 -
6.5.2
A c t io n s a t t h e C o - o p e r a t in g P I N X The SDL representation of procedures at the Co-operating PINX is shown in clause C.2 of annex C.
6.5.2.1 Normal procedures 6 . 5 . 2 . 1 . 1 A c t iv a t io n / d e a c t iv a t io n / in t e r r o g a t io n Not applicable. 6.5.2.1.2
I n v o c a t io n a n d o p e r a t io n In State MCR-Idle, on receipt of a mCRequest invoke APDU from the Requesting PINX, the Co-operating PINX examines the received information and checks whether the make call request is allowed to be performed. If necessary, the Co-operating User may be prompted in an implementation specific manner prior to sending the SETUP message for the Requested Call. NOTE A successful check may depend on the necessary Bearer Capability, user prompting and other implementations specific options. If SS-MCR is allowed to be performed, the Co-operating PINX shall store the information received in elements correlation and retainOrigCall for further usage and send a SETUP message towards the Destination PINX conveying •
a Called Party IE with the information as received in element destinationAddress,
•
a Bearer Capability IE and a Channel Identification IE appropriate for the information received in element callType,
•
a Facility IE with a mCInform invoke APDU conveying information as received in the elements • requestingAddress, • cooperatingAddress, • and correlation of the mCRequest invoke APDU.
NOTE Other additional Facility IEs may be sent together with this SETUP message. Afterwards the Co-operating PINX shall enter State MCR-Active. In State MCR-Active, on receipt of an ALERTING message from the Destination PINX, the Co-operating PINX shall send a mCAlerting invoke APDU towards the Requesting PINX in a FACILITY message. The element correlation shall be set as received in the mCRequest invoke APDU. In State MCR-Active, on receipt of a CONNECT message from the Destination PINX, the Co-operating PINX shall send a mCRequest return result APDU towards the Requesting PINX in a FACILITY message or, in the first call clearing message, if element retainOrigCall with value FALSE was received in State MCR-Idle. 6.5.2.2 Ex c e p t io n a l p r o c e d u r e s 6 . 5 . 2 . 2 . 1 A c t iv a t io n / d e a c t iv a t io n / in t e r r o g a t io n Not applicable. 6.5.2.2.2
I n v o c a t io n a n d o p e r a t io n In State MCR-Idle on receipt of a mCRequest invoke APDU from the Requesting PINX, if •
the make call request is not allowed to be performed or
•
the Co-operating User is found busy or
•
the Co-operating User rejects the request after prompting,
the Co-operating PINX shall send a mCRequest return error APDU indicating an appropriate error condition towards the Requesting PINX and remain in State MCR-Idle.
- 11 -
In State MCR-Active, on call failure, unexpected call clearing or receipt of a busy indication from the Destination User, the Co-operating PINX shall send a mCRequest return error APDU indicating an appropriate error condition in a FACILITY message or in the first call clearing message, if retainOrigCall was set to FALSE, towards the Requesting PINX and enter State MCR-Idle. In State MCR-Active, on receipt of a mCInform return error APDU from the Destination PINX the Co-operating PINX shall map the mCInform return error APDU into a mCRequest return error APDU indicating the same error condition, send it in a FACILITY message or in the first call clearing message, if retainOrigCall was set to FALSE, towards the Requesting PINX and enter State MCR-Idle. 6.5.3
A c t io n s a t t h e D e s t in a t io n P I N X The SDL representation of procedures at the Destination PINX is shown in clause C.3 of annex C.
6.5.3.1 Normal procedures 6 . 5 . 3 . 1 . 1 A c t iv a t io n / d e a c t iv a t io n / in t e r r o g a t io n Not applicable. 6.5.3.1.2
I n v o c a t io n a n d o p e r a t io n On receipt of a mCInform invoke APDU from the Co-operating PINX, the Destination PINX may indicate the received information to the Destination User if the capability exists.
6.5.3.2 Ex c e p t io n a l p r o c e d u r e s 6 . 5 . 3 . 2 . 1 A c t iv a t io n / d e a c t iv a t io n / in t e r r o g a t io n Not applicable. 6.5.3.2.2
6.5.4
6.6
I n v o c a t io n a n d o p e r a t io n On receipt of the mCInform invoke APDU from the Co-operating PINX, and if the Destination User is found busy or another error condition is found, the Destination PINX shall send a mCInform return error APDU indicating the appropriate error condition towards the Co-operating PINX.
A c t io n s a t a Tr a n s it P I N X Not applicable.
SS-MCR impact of interworking with public ISDNs Not applicable.
6.7
SS-MCR impact of interworking with non-ISDNs Not applicable.
6.8
Protocol interactions between SS-MCR 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 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 SS-MCR and another supplementary service or 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. NOTE Specific applications of this Standard may restrict these interactions.
6.8.1
Calling Line Identification Presentation (SS-CLIP) No protocol interaction.
- 12 -
6.8.2
Connected Line Identification Presentation (SS-COLP) No protocol interaction.
6.8.3
C a l l i n g /C o n n e c t e d L i n e I d e n t i f i c a t i o n R e s t r i c t i o n ( S S - C L I R ) No protocol interaction.
6.8.4
Calling Name Identification Presentation (SS-CNIP) No protocol interaction.
6.8.5
Calling Name Identification Presentation (SS-CNIR) No protocol interaction.
6.8.6
Connected Name Identification Presentation (SS-CONP) No protocol interaction.
6.8.7
Completion of Call to Busy Subscriber (SS-CCBS) No protocol interaction.
6.8.8
Completion of Call on No Reply (SS-CCNR) No protocol interaction.
6.8.9
C a ll Tr a n s f e r ( S S - C T) No protocol interaction.
6.8.10
C a ll F o r wa r d in g U n c o n d it io n a l ( S S - C F U ) If the Co-operating User has activated SS-CFU, the request to establish a new Requested Call shall not be forwarded. The Co-operating PINX shall, as an implementation option, either override execution of SS-CFU and prompt the Co-operating User as specified in 6.5.2.1.2 or send a mCRequest return error APDU indicating an appropriate error value towards the Requesting PINX. SS-CFU, activated at the Destination User, is not affected by SS-MCR, i.e. the Requested Call may be forwarded.
6.8.11
C a ll F o r wa r d in g Bu s y ( S S - C F B) If a Co-operating User has activated SS-CFB, the request to establish a new Requested Call shall not be forwarded and the Co-operating PINX shall send a mCRequest return error APDU indicating an appropriate error value towards the Requesting PINX. SS-CFB, activated at the Destination User, is not affected by SS-MCR, i.e. the Requested Call may be forwarded.
6.8.12
C a ll F o r wa r d in g N o R e p ly ( S S - C F N R ) If the Co-operating User has activated SS-CFNR, the request to establish a new Requested Call shall not be forwarded. The Co-operating PINX shall, as an implementation option, either override execution of SS-CFNR and prompt the Co-operating User as specified in 6.5.2.1.2 or send a mCRequest return error APDU indicating an appropriate error value towards the Requesting PINX. SS-CFNR, activated at the Destination User, is not affected by SS-MCR, i.e. the Requested Call may be forwarded.
6.8.13
C a ll D e f le c t io n ( S S - C D ) Deflection of the request to establish a new Requested Call shall not be allowed. The Co-operating PINX shall, as an implementation option, either override execution of SS-CD and prompt the Co-operating User as specified in 6.5.2.1.2 or send a mCRequest return error APDU indicating an appropriate error value towards the Requesting PINX. SS-CD, activated at the Destination User, is not affected by SS-MCR, i.e. the Requested Call may be deflected.
6.8.14
Path Replacement (ANF-PR) No protocol interaction.
- 13 -
6.8.15
C a ll O f f e r ( S S - C O ) No protocol interaction.
6.8.16
C a ll I n t r u s io n ( S S - C I ) No protocol interaction.
6.8.17
Do not Disturb (SS-DND) On receipt of a mCRequest invoke APDU and if the Co-operating User has activated SS-DND, it is an implementation option whether SS-DND or SS-MCR is performed. If SS-DND overrides, the Cooperating PINX shall send a mCRequest return error APDU indicating an appropriate error value towards the Requesting PINX. On receipt of a mCInform invoke APDU and if the Destination User has activated SS-DND, it is an implementation option whether SS-DND or SS-MCR is performed. If SS-DND overrides, the Destination PINX shall send a mCInform return error APDU indicating an appropriate error value towards the Co-Operating PINX.
6.8.18
Do not Disturb Override (SS-DNDO) No protocol interaction.
6.8.19
A d v ic e o f C h a r g e ( S S - A O C ) No protocol interaction.
6.8.20
R e c a ll ( S S - R E) No protocol interaction.
6.8.21
Call Interception (ANF-CINT) No protocol interaction.
6.8.22
Tr a n s it C o u n t e r ( A N F - TC ) No protocol interaction.
6.8.23
Route Restriction Class (ANF-RRC) No protocol interaction.
6.8.24
M e s s a g e W a it in g I n d ic a t io n ( S S - M W I ) No protocol interaction.
6.8.25
W i r e l e s s T e r m i n a l L o c a t io n R e g i s t r a t i o n ( S S - W T L R ) No protocol interaction.
6.8.26
Wireless Terminal Incoming Call (ANF-WTMI) No protocol interaction.
6.8.27
Wireless Terminal Outgoing Call (ANF-WTMO) No protocol interaction.
6.8.28
Wireless Terminal Authentication of a WTM User (SS-WTAT) No interaction
6.8.29
Wireless Terminal Authentication of the PISN (SS-WTAN) No protocol interaction.
6.8.30
Private User Mobility Incoming Call (ANF-PUMI) No protocol interaction.
6.8.31
P r i v a t e U s e r M o b i l i t y O u t g o in g C a l l ( A N F - P U M O ) No protocol interaction.
6.8.32
P r i v a t e U s e r M o b i l i t y R e g is t r a t i o n ( S S - P U M R ) No protocol interaction.
- 14 -
6.8.33
Common Information (ANF-CMN) No protocol interaction.
6.8.34
C a ll P r io r it y I n t e r r u p t io n ( P r o t e c t i o n ) ( S S - C P I ( P ) ) No protocol interaction.
6.8.35
Single Step Call Transfer (SS-SSCT) No protocol interaction.
6.3.36
S im p le D ia lo g ( S S - S D ) No protocol interaction.
6.8.37
G lo b a l C a ll I d e n t if ic a t io n a n d C a ll Lin k a g e ( A N F - C I D L) On receipt of a callIdentificationAssign invoke APDU together with a mCRequest invoke APDU from the Requesting PINX, the Co-operating PINX shall send a callIdentificationAssign invoke APDU using the same threadID as received from the Requesting PINX towards the Destination PINX together with the mCInform invoke APDU.
6.8.38
Short Message Service (SS-SMS) No protocol interaction.
6.8.39
Message Centre Monitoring (SS-MCM) No protocol interaction.
6.8.40
M a ilb o x I d e n t if ic a t io n ( S S - M I D ) No protocol interaction.
6.9 6.9.1
SS-MCR parameter values (Timers) Timer T1 This timer shall be started by the Requesting PINX when a mCRequest invoke APDU is sent to the Co-operating PINX. The timer shall be stopped on receipt of a return result, return error or reject APDU of the mCRequest operation. The expiry of this timer shall be equivalent to the receipt of a reject APDU. Timer T1 shall have a value not less than 50 seconds. NOTE When setting timer T1, the value of Basic Call timer T310 as administrated in the PISN should be considered.
- 15 -
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 PICSs; − 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);
o
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;
x
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.
- 16 -
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 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.
- 17 -
A.3
PICS proforma for ECMA-344
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 supplier’s 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)
- 18 -
A.3.3
General
Item
Question/feature
A1
Behaviour as Requesting PINX for SS-MCR
o.1
Yes [ ] No[ ]
A2
Behaviour as Co-operating PINX for SS-MCR
o.1
Yes [ ] No[ ]
A3
Behaviour as Destination PINX for SS-MCR
o.1
Yes [ ] No[ ]
A.3.4
References
Status
N/A
Support
Procedures
Item
Question/feature
References
Status
N/A
Support
B1
Support of relevant ECMA-143 and ECMA-165 procedures at the Requesting PINX
6.2.1
A1:m
[]
m:Yes [ ]
B2
Support of relevant ECMA-143 and ECMA-165 procedures at the Co-operating PINX
6.2.2
A2:m
[]
m:Yes [ ]
B3
Support of relevant ECMA-143 and ECMA-165 procedures at the Destination PINX
6.2.3
A3:m
[]
m:Yes [ ]
B4
Procedures at the Requesting PINX for invocation and operation
6.5.1
A1:m
[]
m:Yes [ ]
B5
Procedures at the Co-operating PINX for invocation and operation
6.5.2
A2:m
[]
m:Yes [ ]
B6
Procedures at the Destination PINX for invocation and operation
6.5.3
A3:m
[]
m:Yes [ ]
- 19 -
A.3.5
Coding
Item
Question/feature
References
Status
N/A
Support
C1
Sending of mCRequest invoke APDU to the Co-operating PINX
6.5.1
A1:m
[]
m:Yes [ ]
C2
Receipt of mCRequest return result APDU or mCRequest return error from the Co-operating PINX
6.5.1
A1:m
[]
m:Yes [ ]
C3
Receipt of mCRequest invoke APDU from the Requesting PINX
6.5.2
A2:m
[]
m:Yes [ ]
C4
Sending of mCRequest return result APDU or mCRequest return error APDU in case of an error indication
6.5.2
A2:m
[]
m:Yes [ ]
C5
Sending of mCAlerting invoke APDU to the Requesting PINX
6.5.2
A2:m
[]
m:Yes [ ]
C6
Receipt of mCAlerting invoke APDU from the Co-operating PINX
6.5.1
A1:m
[]
m:Yes [ ]
C7
Sending of mCInform invoke APDU to the Destination PINX
6.5.2
A2:m
[]
m:Yes [ ]
C8
Receipt of mCInform return error APDU from the Destination PINX
6.5.2
A2:m
[]
m:Yes [ ]
C9
Receipt of mCInform invoke APDU from the Co-operating PINX
6.5.3
A3:m
[]
m:Yes [ ]
C10
Sending of mCInform return error APDU to the Co-operating PINX
6.5.3
A3:m
[]
m:Yes [ ]
A.3.6
Timers
Item
Question/feature
References
Status
N/A
Support
D1
Support of timer T1
6.9.1
A1:m
[]
m: Yes [ ] Value [. . . .]
- 20 -
- 21 -
Annex B ( in f o r ma tiv e )
Examples of Message Sequences
This annex describes some typical message flows for SS-MCR. The following conventions are used in the figures of this annex. 1. The following notation is used: Basic call message containing SS-MCR information Basic call message without SS-MCR information Call Independent Signalling Connection messages containing SS-MCR information Call Independent Signalling Connection messages without SS-MCR information SS-MCR information for the connected users
xxx.inv xxx.rr xxx.re
Invoke APDU for operation xxx Return result APDU for operation xxx Return error APDU for operation xxx
2. The figures show messages exchanged via Protocol Control between PINXs involved in SS-MCR. Only messages relevant to SS-MCR are shown. 3. Only the relevant information content (e.g. remote operation APDUs, notifications, information elements) is listed below each message name. The Facility and Notification indicator information elements containing remote operation APDUs and notifications are not explicitly shown. Information with no impact on SS-MCR is not shown.
- 22 -
B.1 B.1.1
Example message sequences for invocation and operation of SS-MCR Example message sequences without prior existing connection Figure B.1 shows an example of successful invocation and operation of SS-MCR. The Requesting PINX initiates establishment of a Basic Call. A CISC is to be established before invocation of SS-MCR. The connection between Requesting PINX and Co-operating PINX is released after successful Call establishment as requested in the mCRequest invoke APDU. Requesting PINX
Co- operating PINX SETUP mCRequest .inv CONNE CT FACILITY
Destination PINX SETUP mCInform . inv CALL PROC
ALERTING
mCAlerting.inv
RELEASE
CONNE CT
mCRequest .rr RELEASE COMPLE TE Basic Call
F ig u r e B. 1 – Ex a m p le o f s u c c e s s f u l in v o c a t io n a n d o p e r a t io n o f S S - M C R
- 23 -
Figure B.2 shows an example of successful invocation and operation of SS-MCR initiated by the Requesting PINX in case of an already existing CISC before invocation of SS-MCR. The connection between Requesting PINX and Co-operating PINX is retained after successful Call establishment. Requesting PINX
Co-operating PINX
Destination PINX
CISC Connection FACILITY
SETUP
mCRequest.inv
mCInform.inv CALL PROC
FACILITY
ALERTING
mCAlerting.inv FACILITY
CONNECT
mCRequest.rr
Basic Call
F ig u r e B. 2 – Ex a m p le o f s u c c e s s f u l in v o c a t io n a n d o p e r a t io n o f S S - M C R using an already existing CISC
- 24 -
Figure B.3 and B.4 show examples of unsuccessful invocation and operation of SS-MCR initiated by the Requesting PINX due to different error conditions.
Requesting PINX
Co-operating PINX
Destination Destination PINX User
CISC FACILITY
SETUP
mCRequest.inv
mCInform.inv
Setup ind.
CALL PROC
RELEASE
FACILITY
Busy ind.
mCRequest.re REL COMP
CISC
F ig u r e B. 3 – Ex a m p le o f u n s u c c e s s f u l in v o c a t io n o f S S - M C R due to busy Destination User
Requesting PINX
Co-operating PINX
Destination PINX
CISC FACILITY mCRequest.inv FACILITY mCRequest.re
CISC
F ig u r e B. 4 – Ex a m p le o f u n s u c c e s s f u l in v o c a t io n o f S S - M C R due to not allowed request
- 25 -
B.1.2
Example message sequences of a successful communication with a message centre Figure B.5 shows an example for an application of SS-MCR for a Message Centre Application. Here the Requesting and Destination PINX are co-located at a Message Centre PINX complying with Profile-4 as defined in ECMA-345. SS-MCR is used in order to switch on/off a B-Channel for listening to a message. An already established CISC is used to signal to the Served/Co-operating PINX, that an additional BChannel is needed. After retrieval of the message the B-channel is switched off again. Requesting/ Destination PINX
Co-operating PINX
CISC (1) FACILITY (1) mCRequest.inv SETUP (2) mCInform.inv CONNECT (2)
FACILITY (1) mCRequest.res Basic Call (2) DISCONNECT (2) CISC (1)
F ig u r e B. 5 – Ex a m p le o f s u c c e s s f u l in v o c a t io n f o r S S - M C R w i t h p r i o r e x i s t i n g c o n n e c t i o n b e t we e n a C o - o p e r a t in g P I N X a n d a c o - lo c a t e d R e q u e s t in g /D e s t in a t io n P I N X
- 26 -
- 27 -
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 Rec. Z.100 (1999). Each diagram represents the behaviour of an SS-MCR 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. 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. 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. The following abbreviations are used: .inv
invoke APDU
.re
return error APDU
.rej
reject APDU
.res
return result APDU
- 28 -
C.1
SDL representation of SS-MCR at the Requesting PINX Figures C.1 show the behaviour of an SS-MCR Supplementary Service Control entity within the Requesting PINX. Input signals from the right and output signals to the right represent primitives from and to the Requesting User and internal signalling, e.g. timer expiry. Input signals from the left and output signals to the left represent primitives from and to the Coordination Function in respect of messages received and sent. MCR idle
Make Call Request ind.
to Co-operating PINX
mCRequest.inv
Start Timer T1
MCR wait
from Co-operating PINX
MClRequest.res
mCRequest.rej/err
Make Call succesful ind.
Timer T1 Expiry
Make Call unsuccesful ind.
MCAlerting.inv
Make Call Alerting ind.
MCR idle
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 S S - M C R a t t h e R e q u e s t in g P I N X
- 29 -
C.2
SDL representation of SS-MCR at the Co-operating PINX Figures C.2 show the behaviour of an SS-MCR Supplementary Service Control entity within the Co-operating PINX. Input signals from the right and output signals to the right represent primitives from and to the Co-operating User. Input signals from the left and output signals to the left represent primitives from and to the Coordination Function in respect of messages received and sent.
MCR_idle
From Requesting PINX
mCRequest.inv
no Request Allowed?
yes
Prompt Co-Operating User?
no
yes Make Call Request ind.
Reject ind.
Accept ind.
To Destination PINX
mClnform.inv
MCR_Active
mCInform.re
mCRequest.re
CONNECT
mCRequest.res
From Destination PINX
ALERTING
To Requesting PINX
mCAlerting.inv
MCR_idle
Figure C.2 – SDL representation of SS-MCR at the Co-operating PINX
- 30 -
C.3
SDL representation of SS-MCR at the Destination PINX Figures C.3 show the behaviour of an SS-MCR Supplementary Service Control entity within the Destination PINX. Input signals from the right and output signals to the right represent primitives from and to the Destination User. Input signals from the left and output signals to the left represent primitives from and to the Coordination Function in respect of messages received and sent. MCR idle
mCInform.inv
Make Call Information ind.
Alert/Connect ind.
Busy ind.
ALERTING/ CONNECT
Error ind.
mCInform.re
MCR idle
F ig u r e C . 3 – S D L r e p r e s e n t a t io n o f S S - M C R a t t h e D e s t in a t io n P I N X
.
.
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.