Standard ECMA-343 June 2003
International
Standardizing
Information
and
Communication
Systems
Private Integrated Services Network (PISN) – Specification, Functional Model and Information Flows – 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-343 June 2003
International
Standardizing
Information
and
Communication
Systems
Private Integrated Services Network (PISN) – Specification, Functional Model and Information Flows – Make Call Request Supplementary Service (MCRSD)
Phone/Fax: +41 22 849.60.00/01 IW
Ecma-343.doc
02-07-03 11,38
-
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-00231. This particular Standard specifies the Make Call Request supplementary service. 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 4 . 1 E x te r n a l d e f in itio n s 4 . 2 O th e r d e f in itio n s 4.2.1 Co - o p e r a tin g U s e r 4.2.2 Destination User 4.2.3 Ma k e Ca ll Re q u e s t 4.2.4 Original Call 4.2.5 Requested Call 4.2.6 Re q u e s tin g U s e r
2 2 2 2 2 2 2 2 2
5
List of acronyms
2
6
S S - M C R s t a g e 1 s p e c if ic a t io n 6 . 1 D e s c r ip tio n 6.1.1 G e n e r a l d e s c r ip tio n 6.1.2 Q u a l i f i c a t i o n s o n a p p l i c a b i l i t y t o t e l e c o mmu n ic a t i o n s e r v i c e s 6.2 Procedures 6.2.1 P r o v is io n / w ith d r a w a l 6.2.2 N o r ma l p r o c e d u r e s 6.2.3 E x c e p tio n a l p r o c e d u r e s 6 . 3 I n t e r a c t i o n s w i t h o t h e r S u p p l e me n t a r y S er v i c e s / A d d i t i o n a l N e t w o r k F e a t u r e s 6.3.1 Calling Line Identification Presentation (SS-CLIP) 6.3.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.3.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.3.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.3.5 Ca llin g /Co n n e c te d N a me I d e n tif ic a tio n Re s tr ic tio n ( S S - CN I R) 6.3.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.3.7 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.3.8 C a l l F o r w a r d in g B u s y ( S S - C F B ) 6.3.9 Ca ll F o r w a r d in g N o Re p ly ( S S - CF N R) 6.3.10 Call Deflection (SS-CD) 6.3.11 P a t h R e p l a c e me n t ( A N F - P R ) 6.3.12 Call Transfer (SS-CT) 6.3.13 C o mp l e t i o n o f C a l l s t o B u s y S u b s c r i b e r s ( S S - C C B S ) 6.3.14 C o mp l e t i o n o f C a l l s o n N o R e p ly ( S S - C C N R ) 6.3.15 Call Offer (SS-CO) 6.3.16 Do Not Disturb (SS-DND)
3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 5
- ii -
7
6.3.17 Do Not Disturb Override (SS-DNDO) 6.3.18 Call Intrusion (SS-CI) 6.3.19 A d v ic e o f Ch a r g e ( S S - A O C) 6.3.20 Recall (SS-RE) 6.3.21 Call Interception (SS-CINT) 6.3.22 T r a n s it Co u n te r ( A N F - T C) 6.3.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.3.24 Me s s a g e W a itin g I n d ic a tio n ( S S - MW I ) 6.3.25 W ir e l e s s T e r mi n a l L o c a t i o n Re g is tr a tio n ( S S - W T L R) 6.3.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 ( S S - W T MI ) 6.3.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 ( S S - W T M O ) 6.3.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.3.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.3.30 C o mmo n I n f o r ma t i o n ( S S - C MN ) 6.3.31 Call Priority Interruption (Protection) (SS-CPI(P)) 6.3.32 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.3.33 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.3.34 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.3.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.3.37 Call Identification and Call Linkage (ANF-CIDL) 6.3.38 Short Message Service (SS-SMS) 6.3.39 Me s s a g e Ce n tr e Mo n ito r in g ( S S - MCM) 6.3.40 Ma ilb o x I d e n tif ic a tio n ( S S - MI D ) 6 . 4 I n te r w o r k in g c o n s id e r a tio n s 6.5 Overall SDL
5 5 5 5 5 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 7
S S - M C R s t a g e 2 s p e c if ic a t io n 7 . 1 F u n c tio n a l mo d e l 7.1.1 F u n c tio n a l mo d e l d e s c r ip tio n 7.1.2 Description of Functional Entities 7 . 2 I n f o r ma t i o n f l o w s 7.2.1 D e f in itio n o f in f o r ma tio n f lo w s 7.2.2 Re la tio n s h ip o f in f o r ma tio n f lo w s to Ba s ic Ca ll in f o r ma tio n f lo w s 7.2.3 I n f o r ma tio n f lo w s e q u e n c e s 7.3 Functional Entity actions 7.3.1 Functional Entity actions of FE1 7.3.2 Functional Entity actions of FE2 7.3.3 Functional Entity actions of FE3 7.3.4 Functional Entity actions of FE4 7.3.5 Functional Entity actions of FE5 7.3.6 Functional Entity actions of FE6 7 . 4 F u n c t i o n a l E n t i t y b e h a v io u r 7.4.1 Be h a v io u r o f F E 1 7.4.2 Be h a v io u r o f F E 2 7.4.3 Be h a v io u r o f F E 3
9 9 9 9 11 11 13 13 13 13 14 14 14 14 14 15 15 16 17
- iii -
7.4.4 Be h a v io u r o f F E 4 7.4.5 Be h a v io u r o f F E 5 7.4.6 Be h a v io u r o f F E 6 7 . 5 A l l o c a t i o n o f F u n c t i o n a l E n t i t i e s t o p h ys i c a l e q u ip me n t 7 . 6 I n te r w o r k in g c o n s id e r a tio n s
18 18 19 19 20
1
Scope This Standard specifies supplementary service Make Call Request (SS-MCR), which is related, but not limited, to various basic services supported by Private Integrated Services Networks (PISNs). Basic services are specified in ECMA-142. 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 and Destination User can be either a Basic call or call independent signalling connection. Service specifications are produced in three stages, according to the method described in ETS 300 387. This Standard contains the stage 1 and stage 2 specifications of SS-MCR. The stage 1 specification (clause 6) specifies the supplementary service as seen by users of PISNs. The stage 2 specification (clause 7) specifies the functional entities involved in the supplementary service and the information flows between them.
2
Conformance In order to conform to this Standard, a stage 3 standard shall specify signalling protocols and equipment behaviour that are capable of being used in a PISN which supports the supplementary service specified in this Standard. This means that, to claim conformance, a stage 3 standard is required to be adequate for the support of those aspects of clause 6 (stage 1) and clause 7 (stage 2) which are relevant to the interface or equipment to which the stage 3 standard applies.
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-142
Private Integrated Services Network (PISN) – Circuit-mode 64 kbit/s Bearer Services – Service Description, Functional Capabilities and Information Flows (International Standard ISO/IEC 11574)
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)
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. Z.100 Specification and Description Language (1999)
- 2 -
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
5
− Basic Service
(ECMA-142)
− Call, Basic call
(ECMA-165)
− Call independent signalling connection
(ECMA-165)
− Call Independent
(ECMA-165)
− Call Related
(ECMA-165)
− Private Integrated services Network eXchange (PINX)
(ECMA-133)
− Private Integrated Services Network (PISN)
(ECMA-133)
− Service
(ITU-T Rec. I.112)
− Signalling
(ITU-T Rec. I.112)
− Supplementary Service
(ITU-T Rec. I.210)
− User
(ECMA-142)
Other definitions
4.2.1
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.2
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.3
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.4
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.
4.2.5
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.6
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.
List of acronyms ANF
Additional Network Feature
FE
Functional Entity
ISDN
Integrated Services Digital Network
MCR
Make Call Request
- 3 -
6
PINX
Private Integrated services Network eXchange
PISN
Private Integrated Services Network
SDL
Specification and Description Language
SS
Supplementary Service
SS-MCR stage 1 specification
6.1
Description
6.1.1
General 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 shall be correlated to the Original Call between the Requesting User and the Co-operating User.
6.1.2
Qualifications on applicability to telecommunication services This supplementary service is applicable to all basic telecommunication services.
6.2
Procedures
6.2.1
P r o v is io n / wit h d r a wa l SS-MCR may be provided or withdrawn after pre-arrangement with the service provider or may be generally available to all users.
6.2.2 Normal procedures 6.2.2.1 A c t iv a t io n , d e a c t iv a t io n a n d in t e r r o g a t io n Not applicable. 6.2.2.2
I n v o c a t io n a n d o p e r a t io n A Requesting User may use SS-MCR to request the set up of a new Requested Call between a Co-operating User and a Destination User. NOTE The Requesting User and the Destination User can be the same user (e.g. Requesting/Destination User is a Message Centre) To invoke SS-MCR the Requesting User may use, if available, an existing signalling connection (either call-related or call-independent) with the Co-operating User, otherwise the Requesting User shall establish a call independent signalling connection to the Co-operating User in order to convey the following information: •
address information of the Destination User (e.g. Party Number);
•
optionally, number information of the Co-operating User (e.g. Party Number);
•
optionally, number information of the Requesting User (e.g. Party Number);
•
an indication for a Basic Service, if a Basic call is requested, otherwise an indication for a call independent signalling connection;
•
a correlation ID for the Original Call and the Requested Call;
•
an indication whether to retain the Original Call after successful establishment of the Requested Call.
- 4 -
If the entity serving the Co-operating User supports SS-MCR, this entity may check whether the Requesting User is allowed to invoke SS-MCR and if a call independent signalling connection or a Basic call with the indicated Bearer Service can be established. Afterwards, the Co-operating User may be informed about the SS-MCR request. The Requested Call shall be either a Basic call with the requested Basic Service or a call independent signalling connection, due to the received request. Additionally the following information shall be sent to the Destination User: •
address information of the Requesting User and Co-operating User (i.e. Party Number of the Requesting User) if received;
•
a correlation ID for the Original Call and the Requested Call.
If the Requested Call is successfully established, an appropriate indication shall be sent to the Requesting User. The Original Call shall be retained or cleared immediately after successful establishment of the Requested Call dependent on the corresponding indication received in the initial Make Call Request from the Requesting User. The Co-operating User is responsible for clearing of the Requested Call. In case of retention of the Original Call the Requesting User is responsible for clearing of the Original Call to the Co-operating User. 6.2.3 Ex c e p t io n a l p r o c e d u r e s 6.2.3.1 A c t iv a t io n , d e a c t iv a t io n a n d in t e r r o g a t io n Not applicable. 6.2.3.2
I n v o c a t io n a n d o p e r a t io n If the entity serving the Co-operating User does not support SS-MCR or if the validation of the request from the Requesting user fails or a call independent signalling connection or a Basic call with the indicated Basic Service cannot be established, an appropriate error indication shall be sent to the Requesting User. The Requesting User is responsible for clearing of the Original Call. If the Co-operating User is busy when SS-MCR is invoked, an appropriate error indication shall be sent to the Requesting User. The Requesting User is responsible for clearing the Original Call.
6.3
Interactions with other Supplementary Services / Additional Network Features Interactions with other supplementary services and ANFs for which PISN standards were available at the time of publication of this Standard are specified below.
6.3.1
Calling Line Identification Presentation (SS-CLIP) No interaction.
6.3.2
Connected Line Identification Presentation (SS-COLP) No interaction.
6.3.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 interaction.
6.3.4
Calling Name Identification Presentation (SS-CNIP) No interaction.
6.3.5
C a l l i n g /C o n n e c t e d N a m 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 N I R ) No interaction.
6.3.6
Connected Name Identification Presentation (SS-CONP) No interaction.
6.3.7
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 set up a new Requested Call shall not be forwarded. It is an implementation option for the entity serving the Co-operating User to either provide SS-MCR or to send an error indication towards the Requesting User. SS-CFU, activated at the Destination User, is not affected by SS-MCR , i.e. the Requested Call may be forwarded.
- 5 -
6.3.8
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 and is in busy condition, the request to set up a new Requested Call shall not be forwarded and an error indication shall be provided towards the Requesting user. SS-CFB, activated at the Destination User, is not affected by SS-MCR, i.e. the Requested Call may be forwarded.
6.3.9
C a l l F o r wa r d i n g N o R e p l y ( S S - C F N R ) If the Co-operating User has activated SS-CFNR and does not answer, the request to set up a new Requested Call shall not be forwarded. It is an implementation option for the entity serving the Cooperating User to either continue providing SS-MCR or to send an error indication towards the Requesting User. SS-CFNR, activated at the Destination User, is not affected by SS-MCR, i.e. the Requested Call may be forwarded.
6.3.10
C a ll D e f le c t io n ( S S - C D ) Deflection of the request to set up a new Requested Call shall not be allowed. The request to set up a new Requested Call shall not be deflected. It is an implementation option for the entity serving the Cooperating User to either provide SS-MCR or to send an error indication towards the Requesting User. SS-CD, activated at the Destination User, is not affected by SS-MCR, i.e. the Requested Call may be deflected.
6.3.11
Path Replacement (ANF-PR) No interaction.
6.3.12
C a ll Tr a n s f e r ( S S - C T) No interaction.
6.3.13
Completion of Calls to Busy Subscribers (SS-CCBS) No interaction.
6.3.14
Completion of Calls on No Reply (SS-CCNR) No interaction.
6.3.15
C a ll O f f e r ( S S - C O ) No interaction.
6.3.16
Do Not Disturb (SS-DND) If the Co-operating User has activated SS-DND, it is an implementation option for the entity serving the Co-operating User to either provide SS-MCR or to send an error indication towards the Requesting User. If the Destination User has activated SS-DND, it is an implementation option for the entity serving the Destination User to either present the Requested Call to the Destination User or to send an error indication towards the Co-operating User.
6.3.17
Do Not Disturb Override (SS-DNDO) No interaction.
6.3.18
C a ll I n t r u s io n ( S S - C I ) No interaction.
6.3.19
A d v ic e o f C h a r g e ( S S - A O C ) No interaction.
6.3.20
R e c a ll ( S S - R E) No interaction.
6.3.21
Call Interception (SS-CINT) No interaction.
- 6 -
6.3.22
Tr a n s it C o u n t e r ( A N F - TC ) No interaction.
6.3.23
Route Restriction Class (ANF-RRC) No interaction.
6.3.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 interaction.
6.3.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 interaction.
6.3.26
Wireless Terminal Incoming Call (SS-WTMI) No interaction.
6.3.27
Wireless Terminal Outgoing Call (SS-WTMO) No interaction.
6.3.28
Wireless Terminal Authentication of a WTM User (SS-WTAT) No interaction.
6.3.29
Wireless Terminal Authentication of the PISN (SS-WTAN) No interaction.
6.3.30
C o m m o n I n f o r m a t io n ( S S - C M N ) No interaction.
6.3.31
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 interaction.
6.3.32
Private User Mobility Incoming Call (ANF-PUMI) No interaction.
6.3.33
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 interaction.
6.3.34
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 interaction.
6.3.35
Single Step Call Transfer (SS-SSCT) No interaction.
6.3.36
S im p le D ia lo g ( S S - S D ) No interaction.
6.3.37
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) If applicable, the same Thread ID shall be used for the call between Requesting User and Co-operating User and the call between Co-operating User and Destination User.
6.3.38
Short Message Service (SS-SMS) No interaction.
6.3.39
Message Centre Monitoring (SS-MCM) No interaction.
6.3.40
M a ilb o x I d e n t if ic a t io n ( S S - M I D ) No interaction.
6.4
Interworking considerations If an adjacent network supports an equivalent feature, interworking between the PISN and the other network is allowed.
- 7 -
6.5
Overall SDL Figure 1 contains the dynamic description of SS-MCR using the Specification and Description Language (SDL) defined in ITU-T Rec. Z.100 (1999). The SDL process represents the behaviour of the network in providing SS-MCR. Input signals from the left and output signals to the left represent primitives from and to the Requesting User. Input signals from the right and output signals to the right represent primitives from and to the Co-operating User.
- 8 -
MCR idle
MCRequest indication from the Requesting User
NO
establish new connection between Requesting and Cooperating User
Connection between Requesting and Cooperating User established ?
YES
MCRequest to Cooperating User
MCRequest allowed at the Cooperating User ?
NO
YES Basic Service for the new call possible ?
NO
YES Cooperating User initiates new connection to Destination User
MCRequest successful ?
NO
YES MCRequest successful indication
MCRequest unsuccessful indication
MCR idle
F ig u r e 1 – S S - M C R O v e r a ll S D L
- 9 -
7
SS-MCR stage 2 specification
7.1
Functional model
7.1.1
Functional model description The functional model shall comprise the following Functional Entities (FEs): FE1
Requesting User's User Agent;
FE2
Requesting User's control entity;
FE3
Co-operating User's control entity;
FE4
Co-operating User's User Agent;
FE5
Destination User's control entity;
FE6
Destination User's User Agent.
The following relationship shall exist between these FEs: ra
between FE1 and FE2;
rb
between FE2 and FE3;
rc
between FE3 and FE4;
rd
between FE3 and FE5;
re
between FE5 and FE6.
Figure 2 shows these FEs and relationships.
FE1
ra
FE2
rb
FE3
rd
FE5
re
FE6
rc FE4 F ig u r e 2 – F u n c t io n a l m o d e l f o r S S - M C R 7.1.2 D e s c r ip t io n o f F u n c t io n a l En t it ie s 7.1.2.1 R e q u e s t in g U s e r 's U s e r A g e n t , F E1 This Functional Entity:
7.1.2.2
-
receives a request for a call from the requesting user and sends an indication to FE2;
-
receives a notification about the progress of call establishment of the Requested Call from FE2;
-
receives a confirmation for the Requested Call from FE2.
R e q u e s t in g U s e r 's C o n t r o l e n t it y , F E2 This Functional Entity: -
receives a request to establish a new call from FE1;
-
establishes a signalling connection to FE3, if necessary;
-
sends an indication to FE3 to establish a new call from FE3 to FE5;
-
receives a notification about the progress of call establishment of the Requested Call from FE3 and sends a notification to FE1;
- 10 -
7.1.2.3
7.1.2.4
7.1.2.5
7.1.2.6
receives a confirmation from FE3 for the Requested Call from FE3 to FE5 and sends a notification to FE1.
Co-operating User's Control entity, FE3 This Functional Entity: -
receives a request to establish a new call from FE2;
-
sends a corresponding indication to FE4;
-
checks if the request to establish a new call is allowed to be performed;
-
initiates new call establishment and sends an indication about call request to FE5;
-
sends a notification about the progress of call establishment of the Requested Call to FE2;
-
sends a confirmation for the Requested Call to FE2.
Co-operating User's User Agent, FE4 This Functional Entity: -
receives an indication about call establishment from FE3;
-
notifies the Co-operating user.
D e s t in a t io n U s e r 's C o n t r o l e n t it y , F E5 This Functional Entity: -
receives a request for call establishment from FE3;
-
establishes a new call to FE3 and sends a corresponding indication to FE6.
D e s t in a t io n U s e r 's U s e r A g e n t , F E6 This Functional Entity: -
receives an indication about call establishment from FE5;
-
notifies the destination user.
- 11 -
7.2
Information flows
7.2.1
7.2.1.1
D e f in it io n o f in f o r m a t io n f lo ws In the tables listing the elements in information flows, the column headed "Request" indicates which of these elements are mandatory (M) and which are optional (O) in a request/indication information flow, and the column headed "Confirm" (confirmed information flows only) indicates which of these elements are mandatory (M) and which are optional (O) in a response/confirmation information flow. M C R _ C a llR e q u e s t MCR_CallRequest is a confirmed information flow across ra from FE1 to FE2 and rb from FE2 to FE3 used by the Requesting User to initiate establishment of a new call from FE4 to FE6. Table 1 lists the elements within the MCR_CallRequest information flow. Table 1 – Content of MCR_CallRequest Element
Request
Confirm
NOTE
Destination Address
M
1
Requesting Address
O
2
Co-operating Address
O
3
Call Type
M
4
Correlation
M
5
Retain Original Call
O
6
Result
M
7
NOTE 1 This is the Destination User's Party Number (e.g. PISN number). NOTE 2 This is the Requesting User's Party Number (e.g. PISN number). NOTE 3 This is the Co-operating User's Party Number (e.g. PISN number). NOTE 4 This is an indication whether a basic call with a certain basic service or call-independent signalling connection is requested. NOTE 5 This is an indication for correlation of the Requested Call with the original call. NOTE 6 This is an indication whether the original call shall be retained or cleared after establishment of the Requested Call. NOTE 7 This indicates acceptance or the reason for rejection. 7.2.1.2
MCR_PromptCoop MCR_PromptCoop is a confirmed information flow across rc from FE3 to FE4 used by the Co-operating User's Control Entity to prompt the Co-operating User prior to establishment of the Requested Call from FE4 to FE6. MCR_PromptCoop is an internal message flow within the Co-Operating PINX between FE3 and FE4. Therefore this information flow is not visible on the external interface. Table 2 lists the elements within the MCR_PromptCoop information flow.
- 12 -
Ta b le 2 – C o n t e n t o f M C R _ P r o m p t C o o p Element
Request
Confirm
NOTE
Requesting Address
O
1
Destination Address
M
2
Call Type
M
3
Result
M
4
NOTE 1 This is the Requesting User's identity (e.g. PISN number). NOTE 2 This is the Destination User's identity (e.g. PISN number). NOTE 3 This is an indication whether a basic call or call-independent signalling connection is requested. NOTE 4 This indicates acceptance or the reason for rejection. 7.2.1.3
MCR_Inform MCR_Inform is an unconfirmed information flow across rd from FE3 to FE5 and re from FE5 to FE6 used by the Co-operating User's Control Entity to notify the Destination User about establishment of the Requested Call from FE4 to FE6. Table 3 lists the elements within the MCR_Inform information flow. Table 3 – Content of MCR_Inform Element
Request
Confirm
NOTE
Requesting Address
O
1
Co-operating Address
O
2
Correlation
M
3
NOTE 1 This is the Requesting User's identity (e.g. PISN number). NOTE 2 This is the Co-operating User's identity (e.g. PISN number). NOTE 3 This is an indication for correlation of the Requested Call with the Original call. 7.2.1.4
M C R _ A le r t in g MCR_Alerting is an unconfirmed information flow across rb from FE3 to FE2 and ra from FE2 to FE1 used by the Co-operating User's Control Entity to notify the Requesting User that the Requested Call from FE4 to FE6 has reached the Call Delivered state. Table 4 lists the elements within the MCR_Alerting information flow. Ta b le 4 – C o n t e n t o f M C R _ A le r t in g Element
Request
Correlation
M
Confirm
NOTE 1
- 13 -
NOTE 1 This is an indication for correlation of the Requested Call with the Original call. 7.2.2
R e la t io n s h ip o f in f o r m a t io n f lo ws t o Ba s ic C a ll in f o r m a t io n f lo ws The MCR_Inform request/indication information flow shall be sent across rd in conjunction with the basic call r1_setup request/indication, which is sent to initiate call establishment by the Co-operating User.
7.2.3
I n f o r m a t io n f lo w s e q u e n c e s A stage 3 standard for SS-MCR shall provide signalling procedures in support of the information flow sequences specified below. In addition, signalling procedures should be provided to cover other sequences arising from error situations, interactions with Basic Call, interactions with other supplementary services, different topologies, etc. The following abbreviations are used: req
request;
ind
indication;
res
response;
con
confirm.
7.2.3.1
M a k e C a ll R e q u e s t p r o c e d u r e s o f S S - M C R Figure 3 shows in generic form the information flow sequence for invocation of SS-MCR.
FE1
FE2
CCA 101
FE3
CC ra_MCR_CallRequest req/ind
CC rb_MCR_CallRequest
201
req/ind
301
rc_MCR_PromptCoop req/ind rc_MCR_PromptCoop con/res
302
102 103
ra_MCR_Alerting req/ind ra_MCR_CallRequest con/res
202 203
rb_MCR_Alerting req/ind rb_MCR_CallRequest con/res
rd_MCR_Inform req/ind
FE5
FE6
CCA
CC
CCA
401 402 501
re_MCR_CallInfo req/ind
SETUP
SETUP
req/ind
req/ind
REPORT
REPORT [“User being alerted”]
303 [“User being alerted”] 304
FE4
req/ind SETUP
req/ind SETUP
res/con
res/con
601
F ig u r e 3 – I n f o r m a t io n f lo w s e q u e n c e f o r in v o c a t io n o f S S - M C R
7.3 7.3.1
Functional Entity actions F u n c t io n a l En t it y a c t io n s o f F E1 101 sends ra_MCR_CallRequest req/ind to FE2 indicating the necessary information needed to establish a call from FE4 to FE6. 102
receives ra_MCR_Alerting req/ind from FE2 indicating alerting of the Requested Call.
103
receives ra_MCR_CallRequest res/con from FE2 indicating successful or unsuccessful call establishment of the Requested Call.
- 14 -
7.3.2
7.3.3
7.3.4
F u n c t io n a l En t it y a c t io n s o f F E2 201 receives ra_MCR_CallRequest req/ind from FE1, checks if the Requesting User request is valid and allowed to be performed, and sends rb_MCR_CallRequest req/ind to FE3 indicating the necessary information needed to establish a call from FE4 to FE6. 202
receives rb_MCR_Alerting req/ind from FE3 and sends the ra_MCR_Alerting req/ind to FE1.
203
receives rb_MCR_CallRequest res/con from FE3 indicating successful or unsuccessful call establishment of the Requested Call and sends the corresponding ra_MCR_CallRequest res/con to FE1.
F u n c t io n a l En t it y a c t io n s o f F E3 301 receives rb_MCR_CallRequest req/ind from FE2 and sends rc_MCR_PromptCoop req/ind to FE4. 302
receives rc_MCR_PromptCoop res/con from FE4 and sends rd_MCR_Inform req/ind to FE5.
303
receives REPORT req/ind indicating rb_MCR_Alerting req/ind to FE2.
304
receives SETUP res/con from FE5 and sends rb_MCR_CallRequest res/con to FE2.
"User
being
alerted"
from
FE5
and
sends
F u n c t io n a l En t it y a c t io n s o f F E4 401 receives rd_MCR_Inform req/ind from FE3 and indicates the information to the Co-operating User. 402
sends rc_MCR_PromptCoop res/con to FE3.
7.3.5
F u n c t io n a l En t it y a c t io n s o f F E5 501 receives rd_MCR_Inform req/ind from FE3, checks if the Served User is not busy and sends re_MCR_Inform req/ind to FE6.
7.3.6
F u n c t io n a l En t it y a c t io n s o f F E6 601 receives re_MCR_Inform req/ind from FE5, and sends SETUP res/con to FE5.
- 15 -
7.4
Functional Entity behaviour The FE behaviours shown below are intended to illustrate typical FE behaviour in terms of information flows sent and received. The behaviour of each FE is shown using the Specification and Description Language (SDL) defined in IUT-T Rec. Z.100 (1999).
7.4.1
Be h a v io u r o f F E1 Figure 4 shows the normal behaviour of FE1. Output signals to the left and input signals from the left represent information flows to and from FE2. Output signals to the right and input signals from the right represent information flows to and from the User.
MCR_Idle
Indication for Make_Call_Request
ra_MCR_CallRequest req/ind
101 to FE2
MCR_Active
103 from FE2
ra_MCR_CallRequest con/res (accepted)
Make_Call_Request successful indication
ra_MCR_CallRequest con/res (rejected)
102 from FE2
ra_MCR_Alerting ind
Make_Call_Request unsuccessful indication
MCR_Idle
Figure 4 – SDL for MCR Procedures for FE1, Requesting User's User Agent
- 16 -
7.4.2
Be h a v io u r o f F E2 Figure 5 shows the normal behaviour of FE2. Output signals to the left and input signals from the left represent primitives to and from the FE1. Output signals to the right and input signals from the right represent information flows from and to FE3.
MCR_Idle
ra_MCR_CallRequest req/ind
rb_MCR_CallRequest req/ind
201 from FE1
201 to FE3
MCR_Active
203 from FE3
203 to FE1
rb_MCR_CallRequest con/res (accepted)
rb_MCR_CallRequest con/res (rejected)
ra_MCR_CallRequest con/res (accepted)
ra_MCR_CallRequest con/res (rejected)
202 from FE1
202 to FE1
rb_MCR_Alerting req/ind
ra_MCR_Alerting req/ind
MCR_Idle
Figure 5 – SDL for MCR Procedures for FE2, Requesting User's control entity
- 17 -
7.4.3
Be h a v io u r o f F E3 Figure 6 shows the normal behaviour of FE3. Output signals to the left and input signals from the left represent primitives to and from the FE2. Output signals to the right and input signals from the right represent primitives to and from the FE4 and FE5.
MCR_Idle
301 from FE2
rb_MCR_CallRequest req/ind
no Request allowed yes Bearer Service acceptable
no
yes no
User Prompt Required yes rc_MCR_PromptCoop req/ind
301 to FE4
rc_MCR_PromptCoop res/con (accepted)
rd_MCR_Inform req/ind
rc_MCR_PromptCoop res/con (rejected)
302 from FE4
302 to FE5
MCR_Active
303 from FE5
303 to FE2
Call Alerting
rb_MCR_Alerting req/ind
304 from FE5
304 to FE2
Call establishment successful
rb_MCR_CallRequest con/res (accepted)
Call establishment unsuccessful
rb_MCR_CallRequest con/res (rejected)
MCR_Idle
Figure 6 – SDL for MCR Procedures for FE3, Co-operating User's control entity
- 18 -
7.4.4
Be h a v io u r o f F E4 Figure 7 shows the normal behaviour of FE4. Output signals to the left and input signals from the left represent primitives to and from the FE3. MCR idle
rc_MCR_Prompt req/ind
yes
402 to FE3
Accept?
rc_MCR_PromptCoop con/res (accepted)
401 from FE3
no
rc_MCR_PromptCoop con/res (rejected)
402 to FE3
MCR idle
Figure 7 – SDL for MCR Procedures for FE4, Co-operating User's User Agent 7.4.5
Be h a v io u r o f F E5 Figure 8 shows the normal behaviour of FE5. Output signals to the left and input signals from the left represent primitives to and from the FE3. Output signals to the right and input signals from the right represent primitives to and from the FE6. MCR idle
rd_MCR_Inform req/ind
re_MCR_Inform req/ind
501 from FE3
501 to FE6
MCR idle
Figure 8 – SDL for MCR Procedures for FE5, Destination User's control entity
- 19 -
7.4.6
Be h a v io u r o f F E6 Figure 9 shows the normal behaviour of FE6. Output signals to the left and input signals from the left represent primitives to and from the FE5. MCR idle
re_MCR_Inform req/ind
601 from FE5
MCR idle
Figure 9 – SDL for MCR Procedures for FE6, Destination User's User Agent
7.5
Allocation of Functional Entities to physical equipment The allocation of FEs to physical locations shall apply as shown in table 5. Table 5 – Scenarios for the allocation of FEs to physical equipment for SS-MCR FE1
FE2
FE3
Scenario 1
Requesting User
Requesting User PINX
Co-operating User PINX
Scenario 2
Message Centre
Message Centre PINX
Served User PINX
FE4
FE5
FE6
Scenario 1
Co-operating User
Destination User PINX
Destination User
Scenario 2
Served User
Message Centre PINX
Message Centre
- 20 -
7.6
Interworking considerations The allocation of FEs to physical locations in the case of interworking with other networks that support a compatible service shall apply as shown in table 6. Table 6 – Scenarios for the allocation of FEs to physical equipment for SS-MCR in the case of interworking with other networks FE1
FE2
FE3
Scenario 3
Requesting User
Requesting User PINX
Co-operating User PINX
Scenario 4
Other network
Other network
Served User PINX
Scenario 5
Requesting User
Requesting User PINX
Other network
Scenario 6
Other network
Other network
Served User PINX
Scenario 7
Requesting User
Requesting User PINX
Other network
Scenario 8
Other network
Other network
Other network
FE4
FE5
FE6
Scenario 3
Co-operating User
Other network
Other network
Scenario 4
Served User
Destination User PINX
Destination User
Scenario 5
Other network
Destination User PINX
Destination User
Scenario 6
Served User
Other network
Other network
Scenario 7
Other network
Other network
Other network
Scenario 8
Other network
Destination User PINX
Destination User
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.