S tandard ECMA-220
3rd Edition - December 2001
Standardizing Information
and
Communication
Systems
Private Integrated Services Network (PISN) Specification, Functional Model and Information Flows Call Interception 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-220
3rd Edition - December 2001
Standardizing
Information
and
Communication
Systems
Private Integrated Services Network (PISN) Specification, Functional Model and Information Flows Call Interception Additional Network Feature (ANF-CINTSD)
Phone: +41 22 849.60.00 - Fax: +41 22 849.60.01 - URL: http://www.ecma.ch - Internet: [email protected] IW
Ecma-220.doc
14-01-02 10,09
.
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. This particular Standard specifies the Call Interception additional network feature. This Standard is based upon the practical experience of ECMA member companies and the results of their active and continuous participation in the work of ISO/IEC JTC1, ITU-T, ETSI and other international and national standardization bodies. It represents a pragmatic and widely based consensus. Compared to the 1st Edition of Standard ECMA-220 (published by ECMA in March 1995), the 2nd Edition (published by ECMA in June 1997) incorporated changes in order to achieve complete alignment with International Standard ISO/IEC 15053:1997(E) published by ISO/IEC in May 1997.
Adopted as 3rd Edition of Standard ECMA-220 by the General Assembly of December 2001.
- 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 A d d itio n a l N e tw o r k F e a tu r e 4.2.2 ANF-CINT user 4.2.3 Bu sy 4.2.4 Call, basic call 4.2.5 Ca lle d u s e r 4.2.6 Intercepted-to user 4.2.7 Interception cause 4.2.8 I n te r c e p tio n d e la ye d 4.2.9 I n t e r c e p t i o n i mme d i a t e 4.2.10 W a itin g o n b u s y
1 1 2 2 2 2 2 2 2 2 3 3 3
5 6
List of acronyms A N F - C I N T 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 te r a c tio n s w ith 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.3.1 Calling Line Identification Presentation (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 at i o n P r e s e n t a t i o n ( C O 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 ( 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 ( C N I P ) 6.3.5 C o n n e c t e d N a me I d e n t i f i c at i o n P r e s e n t a t i o n ( C O N P ) 6.3.6 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 ( CN I R) 6.3.7 Call Diversion (CFU, CFB, CFNR, CD) 6.3.8 Do Not Disturb (DND) 6.3.9 Do Not Disturb Override (DNDO) 6.3.10 C a l l C o mp l e t i o n t o B u s y S u b s c r i b e r ( C C B S ) 6.3.11 C a l l C o mp l e t i o n o n N o R e p ly ( C C N R ) 6.3.12 Call Offer (CO)
3 3 3 3 4 4 4 4 5 5 6 6 6 6 6 6 6 6 6 6 6 6
- ii -
7
6.3.13 Call Intrusion (CI) 6.3.14 Call Transfer (CT) 6.3.15 P a t h R e p l a c e me n t ( P R ) 6.3.16 Advice Of Charge (AOC/S/D/E) 6.3.17 Recall (RE) 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
7 7 7 7 7 7 7
A N F - C I N T 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.1.3 Re la tio n s h ip o f f u n c tio n a l mo d e l to b a s ic c a ll f u n c tio n a l mo d e l 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 b a s ic c a 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 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
12 12 12 12 13 13 13 20 20 27 27 27 27 28 28 28 28 29 30 31 33 34 36 37 38
1
Scope This Standard specifies Additional Network Feature Call Interception (ANF-CINT), which is applicable to various basic services supported by Private Integrated Services Networks (PISN). Basic services are specified in ECMA-142. ANF-CINT is an additional network feature which enables calls that cannot be completed due to certain conditions to be redirected to a pre-defined intercepted-to user. ANF 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 ANF-CINT. The stage 1 specification (clause 6) specifies the feature as seen by users of PISNs. The stage 2 specification (clause 7) identifies the functional entities involved in the feature 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 feature 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-155
Private Integrated ISO/IEC 11571)
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. I.221
Common specific characteristics of services (1993)
Services
Networks
-
Addressing
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: − Basic Service
(ITU-T Rec. I.210)
− Connection
(ITU-T Rec. I.112)
(International
Standard
- 2 -
− Network Determined User Busy
(ITU-T Rec. I.221)
− Private Integrated Services Network (PISN)
(ECMA-133)
− Private Integrated services Network eXchange (PINX)
(ECMA-133)
− PISN Number
(ECMA-155)
− Service
(ITU-T Rec. I.112)
− Signalling
(ITU-T Rec. I.112)
− Supplementary Service
(ITU-T Rec. I.210)
− User Determined User Busy
(ITU-T Rec. I.221)
− User (except in the context of ANF-CINT user)
(ECMA-142)
This Standard refers to the following basic call functional entities (FEs) defined in ECMA-142: − Call Control (CC) − Call Control Agent (CCA). This Standard refers to the following basic call inter-FE relationships defined in ECMA-142: − r1 − r2 − r3 This Standard refers to the following basic call information flows defined in ECMA-142: − Disconnect request/indication − Setup request/indication − Setup response/confirmation − Report request/indication − Release request/indication
4.2
Other definitions
4.2.1
A d d it io n a l N e t wo r k F e a t u r e A capability, over and above that of a basic service, provided by a PISN, but not directly to a PISN user.
4.2.2
ANF-CINT user An entity, within a PISN, that requests ANF-CINT.
4.2.3
Bu s y A property of a user for whom either a Network Determined User Busy or a User Determined User Busy condition exists.
4.2.4
C a ll, b a s ic c a ll An instance of the use of a basic service.
4.2.5
C a lle d u s e r The user to which a call is directed prior to invocation of ANF-CINT.
4.2.6
Intercepted-to user The user to which the intercepted call is directed.
4.2.7
Interception cause A condition that can lead to call interception.
- 3 -
4.2.8
Interception delayed The redirection of a call to an alternative destination as a result of remaining too long in an alerting or waiting on busy state.
4.2.9
Interception immediate The redirection of a call to an alternative destination as a result of detecting a condition that prevents the call reaching an alerting or waiting on busy state.
4.2.10
W a it in g o n b u s y A call state in which a call is awaiting answer at a user that is busy on another call. NOTE This can arise, for example, as a result of the use of supplementary service Call Offer (SS-CO) during call establishment. A call that is waiting on busy can be transferred.
5
List of acronyms
6
ANF
Additional Network Feature
ANF-CINT
Additional Network Feature Call Interception
CC
Call Control (functional entity)
CCA
Call Control Agent (functional entity)
CD
Call Deflection
CFB
Supplementary Service Call Forwarding Busy
CFNR
Supplementary Service Call Forwarding No Reply
CFU
Supplementary Service Call Forwarding Unconditional
CLIR
Calling/Connected Line Identification Restriction
CNIP
Calling Name Identification Presentation
CNIR
Calling/Connected Name Identification Restriction
FE
Functional Entity
ISDN
Integrated Services Digital Network
PINX
Private Integrated services Network eXchange
PISN
Private Integrated Services Network
SDL
Specification and Description Language
SS
Supplementary Service
TE
Terminal Equipment
ANF-CINT stage 1 specification
6.1 6.1.1
Description General description ANF-CINT is invoked by an ANF-CINT user for an unanswered or unsuccessful call, allowing the call to be routed to a special destination in the PISN. The special destination may be dependent on the interception cause. The conditions leading to invocation of ANF-CINT are considered as implementation options. Examples of factors that can be taken in account are: − the source of the call (e.g., the geographic location of the calling user, the network from which the call has entered the PISN);
- 4 -
− the particular interception cause; − the type of connection (e.g. the originating user is an attendant); − the call destination; − time of the day. 6.1.2
6.2
Qualifications on applicability to telecommunication services Call Interception is applicable to all basic services defined in ECMA-142.
Procedures
6.2.1
P r o v is io n /wit h d r a wa l ANF-CINT shall be PISN instigated. The conditions under which interception is invoked shall be an implementation matter. Also, parameters and values offered by a PISN shall be an implementation matter. A PISN may offer more or less parameters than the one specified below. Parameters may apply separately to each different condition for which interception is to be invoked. Parameter
Value
Intercepted-to number (NOTE)
- PISN number
NOTE This parameter is not needed for conditions where the intercepted-to number is determined on a call by call basis e.g. the number of the user that transferred the call. 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 /r e g is t r a t io n /in t e r r o g a t io n The feature shall be permanently activated. Registration and interrogation shall not apply. 6.2.2.2
I n v o c a t io n a n d o p e r a t io n ANF-CINT shall be invoked for a call if a certain condition, determined by the PISN implementation, is met. Also the parameters with the invocation request shall be determined by the PISN implementation. Examples of interception causes include: − − − − − − − − − − − − − − − − − −
timeout in waiting on busy condition busy user closed user group rejection do not disturb activated incoming barred destination invalid number no compatible user at destination network congestion no reply (i.e. timeout during alerting) called user access out of service route restriction (i.e. calling user not authorized for the route) timeout in waiting on busy condition after transfer no reply after transfer (i.e. timeout during alerting after transfer) upper limit of number of diversions reached upper limit of transit counter reached mobile user location not known mobile user no longer registered mobile terminal not responding
- 5 -
− invalid call diversion destination − timeout after call hold. On acceptance of invocation of ANF-CINT, the PISN shall perform redirection towards the intercepted-to user. If interception is invoked because of detecting a condition that prevents the call reaching an alerting or waiting on busy state (interception immediate) the PISN shall complete the release of the call towards the called user immediately. If interception is invoked as a result of remaining too long in an alerting or waiting on busy state (interception delayed) the PISN shall not release the call towards the called user until the call to the intercepted-to user enters an alerting or waiting on busy state. The called user can accept the call during this period. As an implementation option for interception delayed, the PISN may retain the call towards the called user until the intercepted-to user answers the call. Further procedures in this case are outside the scope of this Standard. 6.2.2.2.1
Intercepted-to user notification The intercepted-to user shall be given a notification that the call has been intercepted. This notification shall include: • the interception cause, • the called user number/name if available.
6.2.2.2.2
Calling user notifications The calling user shall be given the notification that the call has been intercepted with the appropriate interception cause. In case of multiple call interceptions, the calling user shall be notified of the first interception and of any subsequent interceptions from intercepted-to users at which an alerting or waiting on busy state has been reached. For single interception, the intercepted-to user's number and, if available, the intercepted-to user's name shall be sent to the calling user if CLIR/CNIR is not invoked by the intercepted-to user. For multiple interception, the number and, if available, name of the final intercepted-to user shall be sent to the calling user if CLIR and CNIR respectively has not been invoked by the final intercepted-to user. In addition, if an alerting or waiting on busy state is reached at an intermediate intercepted-to user the number and, if available, name of that intercepted-to user may be sent to the calling user if there is no possibility of CLIR and CNIR respectively being invoked by that intercepted-to 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 /r e g is t r a t io n /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 number of the intercepted-to user is unavailable (e.g. due to number presentation restriction or interworking), the user who would have been given the number shall receive an indication of the reason why no number is given. In the case of interception delayed, if the intercepted call cannot be completed to the intercepted-to user, then the PISN shall clear the intercepted-to leg of the call and continue to alert or wait on busy at the called user. In this case the calling user shall not be given any notification. In the case of interception immediate, if the intercepted call cannot be completed to the intercepted-to user, then the PISN shall clear the call, unless it is able to redirect the call to a new intercepted-to user. If the call is cleared, the calling user shall be sent an indication that the call has been intercepted.
6.3
Interactions with other supplementary services and ANFs 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 -
6.3.1
Calling Line Identification Presentation (CLIP) No interaction.
6.3.2
C o n n e c t e d L i n e I d e n t i f ic a t i o n P r e s e n t a t i o n ( C O L P ) 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 ( C L I R ) An intercepted-to user which has invoked CLIR shall not have its number presented to the calling user, as part of a notification of interception, unless the calling user has an override service profile. An intercepted-to user which is provided with CLIR 'temporary mode' shall not have its identity revealed to the calling user as part of a notification of interception until the intercepted-to user has responded and it is known that restriction is not to be invoked, unless the calling user has an override service profile.
6.3.4
Calling Name Identification Presentation (CNIP) No interaction.
6.3.5
Connected Name Identification Presentation (CONP) No interaction.
6.3.6
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 ( C N I R ) An intercepted-to user which has invoked CNIR shall not have its name presented to the calling user, as part of a notification of interception, unless the calling user has an override service profile. An intercepted-to user which is provided with CNIR 'temporary mode' shall not have its name revealed to the calling user as part of a notification of interception until the intercepted-to user has responded and it is known that restriction is not to be invoked, unless the calling user has an override service profile.
6.3.7
Call Diversion (CFU, CFB, CFNR, CD) If the call has been diverted before invocation of interception, the diversion indication and the number and name of the original called user, if available and not restricted, shall also be presented to the intercepted-to user. If the call is diverted after it has been intercepted, the intercepted-to user notification shall be presented to the diverted-to user.
6.3.8
Do Not Disturb (DND) No interaction.
6.3.9
Do Not Disturb Override (DNDO) No interaction.
6.3.10
Call Completion to Busy Subscriber (CCBS) If a call is intercepted and the final intercepted-to user is busy, then a SS-CCBS request made by the calling user shall be applied to the intercepted-to user. Interception immediate shall not apply to a call resulting from the use of SS-CCBS.
6.3.11
Call Completion on No Reply (CCNR) If a call is intercepted, and the final intercepted-to user does not answer, then a SS-CCNR request from the calling user shall be applied to the intercepted-to user. Interception immediate shall not apply to a call resulting from the use of SS-CCNR.
6.3.12
C a ll O f f e r ( C O ) CO against the called user: If the PISN invokes SS-CO automatically because of the service profile of the calling user or the calling user invokes SS-CO as part of initial call set up, then call interception on busy user shall not apply. In all other cases call interception on a busy user can apply, in which case SSCO shall not apply. CO against the intercepted-to user: If a call is intercepted and the intercepted-to user is busy, then if a SS-CO request is received it shall apply to the intercepted-to user. Interception with cause "waiting on busy not answered" can occur after successful invocation of SS-CO.
- 7 -
6.3.13
C a ll I n t r u s io n ( C I ) CI against the called user: If the calling user invokes SS-CI as part of initial call set up, then call interception on busy user shall not apply. In all other cases call interception on a busy user can apply, in which case call intrusion SS-CI shall not apply. CI against the intercepted-to user: If a call is intercepted and the intercepted-to user is busy then, if an SS-CI request is received, it shall be applied to the intercepted-to user.
6.3.14
C a ll Tr a n s f e r ( C T) A call resulting from transfer can be subject to interception if it continues to alert or wait on busy at the called user without reply.
6.3.15
Path Replacement (PR) No interaction.
6.3.16
A d v ic e O f C h a r g e ( A O C /S /D /E) If a call is subject to interception, then the intercepted call can be a charged call. The invocation of SS-AOC-S/D/E at the time of call establishment by or on behalf of the calling user shall apply to the intercepted call.
6.3.17
R e c a ll ( R E) A call redirected as a result of SS-RE may be subject to interception. NOTE ANF-CINT can be used instead of SS-RE, e.g. in case of transfer by rerouteing.
6.4
Interworking considerations When interworking with another network which supports an equivalent feature, it may be possible to cooperate with the other network in order to provide ANF-CINT.
6.5
Overall SDL Figure 1 contains the dynamic description of ANF-CINT 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 ANF-CINT. The relationship of this process to the basic call process is indicated in the annotations. Output signals to the left represent primitives to the calling user. Output signals to the right represent primitives to the intercepted-to user. Input signals from the left represent internal stimuli and primitives from the ANF-CINT user.
- 8 -
F ig u r e 1 - A N F - C I N T, o v e r a ll S D L ( p a r t 1 )
- 9 -
F ig u r e 1 - A N F - C I N T, o v e r a ll S D L ( p a r t 2 )
- 10 -
F ig u r e 1 - A N F - C I N T, o v e r a ll S D L ( p a r t 3 )
- 11 -
F ig u r e 1 - A N F - C I N T, o v e r a ll S D L ( p a r t 4 )
- 12 -
7
ANF-CINT stage 2 specification
7.1
Functional model
7.1.1
Functional model description The functional model shall comprise the following functional entities (FEs): FE1: FE2: FE3: FE4: FE5: FE6:
Calling user agent Calling user control entity Call Interception control entity Call Interception detection entity Intercepted-to user control entity Intercepted-to user agent
The following functional relationships shall exist between these FEs: ra rb rc rd re
between FE1 and FE2 between FE2 and FE3 between FE3 and FE4 between FE3 and FE5 between FE5 and FE6
FE1
ra
FE2
rb
FE3
rc
FE4
rd FE5
re
FE6
F ig u r e 2 - F u n c t io n a l m o d e l f o r A N F - C I N T 7.1.2 D e s c r ip t io n o f f u n c t io n a l e n t it ie s 7.1.2.1 Calling user agent functional entity, FE1 This FE delivers the call interception notification to the calling user. 7.1.2.2
Calling user control functional entity, FE2 This FE provides the appropriate call interception notification to FE1 according to the information received from FE3.
7.1.2.3
Call interception control functional entity, FE3 This FE receives the ANF-CINT invocation from the ANF-CINT user and executes call interception by initiating a new call establishment to the intercepted-to user and requesting release of the leg to the original called user. The leg to the original called user is released immediately on starting the new call establishment (interception immediate) or on receipt of the REPORT request/indication or SETUP response/confirmation information flow (interception delayed). This FE generates and relays to FE2 and generates to FE5 the call interception information flows providing notification information. On receiving information from FE4, FE3 provides the ANF-CINT user with information permitting the ANF-CINT user to decide whether interception is required.
7.1.2.4
Call interception detection functional entity, FE4 This FE detects a condition that can lead to call interception and informs FE3. FE4 also informs FE3 of calls that are not to be subject to interception delayed (e.g. the call is directed to an attendant).
- 13 -
7.1.2.5
Intercepted-to user control functional entity, FE5 This FE provides appropriate call interception notifications to FE6 and provides the intercepted-to user's name, name presentation indicator and number presentation indicator to FE3.
7.1.2.6
I n t e r c e p t e d - t o u s e r a g en t f u n c t i o n a l e n t i t y , F E 6 This FE delivers call interception notifications to the intercepted-to user.
7.1.3
R e la t io n s h ip o f f u n c t io n a l m o d e l t o b a s ic c a ll f u n c t io n a l m o d e l Functional entity FE1 shall be collocated with the calling user's CCA. Functional entity FE2 shall be collocated with the calling user's CC or with the Incoming Gateway CC. Functional entity FE3 shall be collocated with the calling user's CC or with the Incoming Gateway CC or any Transit CC or the Terminating CC or the Outgoing Gateway CC (of the call to the called user). Functional entity FE4 shall be collocated with the Terminating CC or the Outgoing Gateway CC or any Transit CC (of the call to the called user). Functional entity FE5 shall be collocated with the intercepted-to user's CC or with the Outgoing Gateway CC. Functional entity FE6 shall be collocated with the intercepted-to user's CCA. An example of a relationship between the FEs for ANF-CINT and FEs for the basic call is shown in figure 3.
Figure 3 - Example relationship between model for ANF-CINT and basic call
7.2 7.2.1
Information flows 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.
- 14 -
7.2.1.1
rb_INFORM1 rb_INFORM1 is an unconfirmed information flow across rb from FE3 to FE2 which indicates to FE2 that call interception has been initiated. Table 1 lists the elements within the rb_INFORM1 information flow. Table 1- Content of rb_INFORM1 Element
Request
Interception cause
M (NOTE 1)
Intercepted-to number
M
NOTE 1 This element indicates the cause of interception, for example: timeout in waiting on busy condition busy user closed user group rejection do not disturb activated incoming barred destination invalid number no compatible user at destination network congestion no reply (i.e. timeout during alerting) called user access out of service route restriction (i.e. calling user not authorized for the route) timeout in waiting on busy condition after transfer no reply after transfer (i.e. timeout during alerting after transfer) upper limit of number of diversions reached upper limit of transit counter reached mobile user location not known mobile user no longer registered mobile terminal not responding invalid call diversion destination timeout after call hold.
- 15 -
7.2.1.2
ra_INFORM2 ra_INFORM2 is an unconfirmed information flow across ra from FE2 to FE1 which indicates to FE1 that call interception has been initiated. Ta b le 2 - C o n t e n t o f r a _ I N F O R M 2 Element Interception Cause
Request M (NOTE 1)
NOTE 1 This element indicates the cause of interception, for example: timeout in waiting on busy condition busy user closed user group rejection do not disturb activated incoming barred destination invalid number no compatible user at destination network congestion no reply (i.e. timeout during alerting) called user access out of service route restriction (i.e. calling user not authorized for the route) timeout in waiting on busy condition after transfer no reply after transfer (i.e. timeout during alerting after transfer) upper limit of number of diversions reached upper limit of transit counter reached mobile user location not known mobile user no longer registered mobile terminal not responding invalid call diversion destination timeout after call hold.
- 16 -
7.2.1.3
rd_INFORM4 rd_INFORM4 is an unconfirmed information flow across rd from FE3 to FE5 which indicates to FE5 that call interception is taking place and why the call was intercepted. Table 3 lists the elements within the rd_INFORM4 information flow. Table 3 - Content of rd_INFORM4 Element (NOTE 4)
Request
Interception cause
M (NOTE 5)
Called number
O (NOTE 3)
Called user's name incl. restriction indicator
O (NOTE 1)
Original Called Number incl. restriction indicator
O (NOTE 2)
Original Called Name, including restriction indicator
O (NOTE 6)
NOTE 1 This element may be omitted in case of name not available or in case of presentation restricted. NOTE 2 This element shall be included if the call had been diverted before it was intercepted. NOTE 3 This element may be omitted if not available. NOTE 4 The Originating Number, Originating Subaddress, Connection Type and Call History are carried in the basic call SETUP request/indication and are not part of INFORM4. The basic call elements are defined in ECMA-142. NOTE 5 This element indicates the cause of interception, for example: timeout in waiting on busy condition busy user closed user group rejection do not disturb activated incoming barred destination invalid number no compatible user at destination network congestion no reply (i.e. timeout during alerting) called user access out of service route restriction (i.e. calling user not authorized for the route) timeout in waiting on busy condition after transfer no reply after transfer (i.e. timeout during alerting after transfer) upper limit of number of diversions reached upper limit of transit counter reached mobile user location not known mobile user no longer registered mobile terminal not responding invalid call diversion destination timeout after call hold.
- 17 -
NOTE 6 This element may be included if the call has been diverted before it was intercepted. 7.2.1.4
re_INFORM5 re_INFORM5 is an unconfirmed information flow across re from FE5 to FE6 which indicates to FE6 that call interception is taking place and why the call was intercepted. Table 4 lists the elements within the re_INFORM5 information flow. Table 4 - Content of re_INFORM5 Element (NOTE 4)
Request
Interception cause
M (NOTE 5)
Called number
O (NOTE 1)
Called name
O (NOTE 2)
Original Called Number
O (NOTE 3)
Original Called Name
O (NOTE 6)
NOTE 1 This element may be omitted if not available. NOTE 2 This element may be omitted if not available or restricted. NOTE 3 This element shall be included if the call has been diverted before the interception and if no restriction exists. NOTE 4 The Destination Number, Connection Type and Call History are carried in the basic call SETUP request/indication and are not part of INFORM5. The basic call elements are defined in ECMA-142. NOTE 5 This element indicates the cause of interception, for example: timeout in waiting on busy condition busy user closed user group rejection do not disturb activated incoming barred destination invalid number no compatible user at destination network congestion no reply (i.e. timeout during alerting) called user access out of service route restriction (i.e. calling user not authorized for the route) timeout in waiting on busy condition after transfer no reply after transfer (i.e. timeout during alerting after transfer) upper limit of number of diversions reached upper limit of transit counter reached mobile user location not known mobile user no longer registered mobile terminal not responding invalid call diversion destination timeout after call hold.
- 18 -
NOTE 6 This element may be included if the call has been diverted before the interception. 7.2.1.5
rd_INFORM6, rb_INFORM6 rd_INFORM6 is an unconfirmed information flow across rd from FE5 to FE3 which indicates to FE3 the intercepted-to user's name and whether presentation of the intercepted-to user’s number and name is allowed. rb_INFORM6 is an unconfirmed information flow across rb from FE3 to FE2 which indicates to FE2 the intercepted-to user's name and whether presentation of the intercepted-to user’s number and name is allowed. Table 5 lists the elements within the rd_INFORM6, rb_INFORM6 information flow. Table 5 - Content of rd_INFORM6, rb_INFORM6 Element
Request
Presentation indicator
M (NOTE 1)
Intercepted-to name including restriction indicator
O (NOTE 2)
NOTE 1 This element shall apply only to the intercepted-to number. NOTE 2 This element may be omitted in case of name not available or in case of presentation restricted. 7.2.1.6
ra_INFORM7 ra_INFORM7 is an unconfirmed information flow across ra from FE2 to FE1 which informs FE1 of the intercepted-to user's number and name if appropriate. It shall only be sent if the intercepted-to user's number is not presentation restricted. Table 6 lists the elements within the ra_INFORM7 information flow. Ta b le 6 - C o n t e n t o f r a _ I N F O R M 7 Element
Request
Intercepted-to number
M
Intercepted-to name
O (NOTE 1)
NOTE 1 This element shall only be included if no restriction exists. It may be omitted in case of name not available.
- 19 -
7.2.1.7
r c _ I N TER C EP T_ C O N D I TI O N rc_INTERCEPT_CONDITION is an unconfirmed information flow across rc from FE4 to FE3 which conveys a condition for possible interception and other related information which allow the ANFCINT user to decide if interception immediate is required. Table 7 lists the elements within the rc_INTERCEPT_CONDITION information flow. Table 7 - Content of rc_INTERCEPT_CONDITION Element
Request
Interception cause
M (NOTE 3)
Called name including restriction indicator
O (NOTE 1)
Original Called Number incl. restriction indicator
O (NOTE 2)
Original Called Name, including restriction indicator
O (NOTES 1, 2)
NOTE 1 This element may be omitted in case of name not available or in case of presentation restricted or if not known whether presentation is restricted. NOTE 2 This element may be included if the call has been diverted before interception. NOTE 3 This element indicates the condition for possible interception, for example: busy user closed user group rejection do not disturb activated incoming barred destination invalid number no compatible user at destination network congestion called user access out of service route restriction (i.e. calling user not authorized for the route) upper limit of number of diversions reached upper limit of transit counter reached mobile user location not known mobile user no longer registered mobile terminal not responding invalid call diversion destination. 7.2.1.8
rc_INTERCEPT_DISABLE rc_INTERCEPT_DISABLE is an unconfirmed information flow across rc from FE4 to FE3 which informs the ANF-CINT user that call interception delayed is disabled. The information flow contains no elements.
7.2.1.9
r c _ I N T E R C E P T _ EN A B L E rc_INTERCEPT_ENABLE is an unconfirmed information flow across rc from FE4 to FE3 that reenables call interception delayed subsequent to sending an rc_INTERCEPT_DISABLE request/indication. The information flow contains no elements.
- 20 -
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 b a s ic c a ll in f o r m a t io n f lo ws The rb_INFORM1 request/indication information flow shall be sent: − independently of any basic call information flow or − with r2-REPORT request/indication or − with r2-SETUP response/confirmation if not already sent. The ra_INFORM2 request/indication information flow shall be sent: − independently of any basic call information flow or − with r1-REPORT request/indication or − with r1-SETUP response/confirmation. The rd_INFORM4 request/indication information flow shall be sent in conjunction with r2_SETUP request/indication. The re_INFORM5 request/indication information flow shall be sent in conjunction with r3_SETUP request/indication. The rd_INFORM6 request/indication and rb_INFORM6 request/indication information flows shall be sent: − independently of any basic call information flow or − with r2-REPORT request/indication or − with r2-SETUP response/confirmation if not already sent. The ra_INFORM7 request/indication information flow shall be sent: − independently of any basic call information flow or − with r1-REPORT request/indication or − with r1-SETUP response/confirmation. The rc_INTERCEPT_CONDITION request/indication information flow shall be sent: − with r2_REPORT request/indication (indicating call failure) − with r2-RELEASE request/indication. The rc_INTERCEPT_DISABLE request/indication information flow shall be sent: − independently of any basic call information flow or − with r2-REPORT request/indication. The rc_INTERCEPT_ENABLE request/indication information flow shall be sent: − independently of any basic call information flow or − with r2-REPORT request/indication.
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 ANF-CINT 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 and ANFs, different topologies, etc.. In the figures, ANF-CINT information flows are represented by solid arrows and basic call information flows are represented by broken arrows. An ellipse embracing two information flows indicates that the two information flows occur simultaneously. Within a column representing an ANF-CINT functional entity, the numbers refer to functional entity actions listed in 7.3.
- 21 -
7.2.3.1 N o r m a l o p e r a t io n o f A N F - C I N T 7.2.3.1.1 Successful invocation of interception immediate Figure 4 shows the information flow sequence for successful invocation of interception immediate. The decision whether to send or not the information flow rc_INTERCEPT_CONDITION depends on the condition encountered. It need not be sent if the condition can be indicated by basic call information.
rd FE1
ra
CCA r1 SETUP req/ind
FE2
rb
FE3
CC
r2
CC
rc r2
FE4
FE5
CC
CC
re r3
FE6 CCA
r2
SETUP
SETUP req/ind 401 rc_INTERCEPT_CONDITION 306 req/ind 301 RELEASE req/ind rd_INFORM4 req/ind SETUP rb_INFORM1 req/ind ra_INFORM2 201 req/ind 101 req/ind REPORT REPORT req/ind req/ind req/ind
303 ra_INFORM7 rb_INFORM6 202 req/ind 308 SETUP 102 req/ind SETUP resp/conf resp/conf
REPORT req/ind
rd_INFORM6 req/ind SETUP resp/conf
re_INFORM5 501 req/ind 601 SETUP req/ind REPORT req/ind
SETUP resp/conf 502
F i g u r e 4 - I n f o r m a t i o n f l o w s e q u e n c e - s u c c es s f u l i n v o c a t i o n o f i n t e r c e p t i o n i m m e d i a t e
- 22 -
7.2.3.1.2
Successful invocation of interception delayed Figure 5 shows the information flow sequence for successful invocation of interception delayed.
rd FE1
ra
CCA r1
FE2 CC
rb r2
FE3 CC
SETUP req/ind
SETUP req/ind
REPORT req/ind
REPORT req/ind 301
rc r2
FE4
r2
FE5
CC
CC
REPORT req/ind
302 rb_INFORM1 req/ind
303 rb_INFORM6 308 202 req/ind ra_INFORM7 SETUP 102 req/ind resp/conf SETUP resp/conf
r3
FE6 CCA
SETUP req/ind REPORT req/ind
rd_INFORM4 req/ind SETUP req/ind
201 ra_INFORM2 101 req/ind
re
re_INFORM5 501 req/ind 601 SETUP req/ind REPORT req/ind
RELEASE req/ind
rd_INFORM6 req/ind SETUP resp/conf
502
SETUP resp/conf
F i g u r e 5 - I n f o r m a t i o n f l o w s e q u e n c e - s u c c es s f u l i n v o c a t i o n o f i n t e r c e p t i o n d e l a y e d
- 23 -
7.2.3.2 U n s u c c e s s f u l in v o c a t io n o f A N F - C I N T 7.2.3.2.1 Failure of interception immediate Figure 6 shows the information flow sequence for failure of interception immediate. The decision whether to send the information flow rc_INTERCEPT_CONDITION depends on the condition encountered. It need not be sent if the condition can be indicated by basic call information.
Figure 6 - Information flow sequence - failure of interception immediate
- 24 -
7.2.3.2.2
Failure of interception delayed Figure 7 shows the information flow sequence for failure of interception delayed. rd FE1
ra
CCA r1
FE2
rb
FE3
rc
FE4
FE5
CC
r2
CC
r2
CC
CC
r2
SETUP req/ind
SETUP req/ind
REPORT req/ind
REPORT req/ind 301
SETUP req/ind REPORT req/ind
rd_INFORM4 req/ind SETUP req/ind
501
RELEASE req/ind 309
F i g u r e 7 - I n f o r m a t i o n f l o w s e q u e nc e - f a i l u r e o f i n t e r c e p t i o n d e l a y e d
- 25 -
7.2.3.3
Calling user clearing during interception delayed Figure 8 shows the information flow sequence for calling user clearing during interception delayed.
rd FE1
ra
CCA r1
FE2
rb
FE3
rc
FE4
FE5
CC
r2
CC
r2
CC
CC
SETUP req/ind REPORT req/ind
SETUP req/ind REPORT req/ind 301
r2
re
FE6
r3
CCA
SETUP req/ind REPORT req/ind rd_INFORM4 req/ind SETUP req/ind
re_INFORM5 501 req/ind 601 SETUP req/ind
DISCONNECT RELEASE req/ind req/ind 304 RELEASE req/ind RELEASE req/ind
DISCONNECT req/ind
F i g u r e 8 - I n f o r m a t i o n f l o w s e q u e n c e - c a l l i ng u s e r c l e a r i n g d u r i n g i n t e r c e p t i o n d e l a y e d
- 26 -
7.2.3.4
Called user answers during interception delayed Figure 9 shows the information flow sequence for the called user answering before alerting the intercepted-to user.
rd FE1
ra
CCA r1
FE2
rb
FE3
rc
FE4
FE5
CC
r2
CC
r2 r2
CC
CC
SETUP req/ind REPORT req/ind
SETUP resp/conf
SETUP req/ind REPORT req/ind 301
re r3
FE6 CCA
SETUP req/ind REPORT req/ind
rd_INFORM4 req/ind SETUP req/ind SETUP resp/conf SETUP 305 resp/conf RELEASE req/ind
re_INFORM5 501 req/ind 601 SETUP req/ind
DISCONNECT req/ind
F i g u r e 9 - I n f o r m a t i o n f l o w s e q u e n c e - c a l l ed u s e r a n s w e r s d u r i n g i n t e r c e p t i o n d e l a y e d
- 27 -
7.2.3.5
Call interception is disabled by FE4 Figure 10 shows the information flow sequence when FE4 disables call interception.
FE1
ra
CCA r1
FE2
rb
FE3
rc
CC
r2
CC
r2
SETUP req/ind
SETUP req/ind
CC
SETUP req/ind
307 REPORT req/ind
FE4
REPORT req/ind
402 rc_INTERCEPT_DISABLE req/ind REPORT req/ind
F i g u r e 1 0 - I n f o r m a t i o n f l o w s e q u e nc e - F E 4 d i s a b l e s c a l l i n t e r c e p t i o n
7.3
Functional entity actions The following FE actions shall occur at the points indicated in the figures of 7.2.3.
7.3.1
F u n c t io n a l e n t it y a c t io n s o f F E1 101 Deliver call interception notification to the user as received from FE2 in ra_INFORM2 request/indication. 102
7.3.2
F u n c t io n a l e n t it y a c t io n s o f F E2 201 Receive rb_INFORM1 request/indication from FE3 and send a call interception notification (without number and name notification) in ra_INFORM2 request/indication to FE1. 202
7.3.3
Deliver number and name notification to the user as received from FE2 in ra_INFORM7 request/indication.
Receive rb_INFORM6 request/indication from FE3, and, if allowed, send the appropriate number and name, if available, information in ra_INFORM7 request/indication to FE1.
F u n c t io n a l e n t it y a c t io n s o f F E3 301 On receipt of a request from the ANF-CINT user, FE3 performs the following actions: • stimulate the basic call establishment to FE5 and send the rd_INFORM4 request/indication to FE5; • in the case of interception immediate, send rb_INFORM1 request/indication to FE2. 302
On receipt of REPORT request/indication or SETUP response/confirmation from the interceptedto user, in the case of interception delayed, stimulate the release procedure towards the called user and send rb_INFORM1 request/indication to FE2.
303
Relay information received in rd_INFORM6 request/indication from FE5 to FE2.
304
If the calling user releases the call, stimulate the release procedure towards the called and intercepted-to user.
305
If the called user answers, stimulate the release procedure towards the intercepted-to user.
- 28 -
7.3.4
306
On receipt of rc_INTERCEPT_CONDITION request/indication relay the information to the ANFCINT user.
307
On receipt of rc_INTERCEPT_DISABLE request/indication relay the information to the ANFCINT user.
308
On receipt of SETUP response/confirmation indicate successful completion of call interception to the ANF-CINT user if not already indicated.
309
If the call cannot be completed indicate call interception unsuccessful to the ANF-CINT user.
F u n c t io n a l e n t it y a c t io n s o f F E4 401 Detect conditions that can lead to interception immediate and send rc_INTERCEPT_CONDITION request/indication to FE3. 402
7.3.5
F u n c t io n a l e n t it y a c t io n s o f F E5 501 Determine if presentation of the number and the name information received from FE3 in rd_INFORM4 request/indication is applicable and send re_INFORM5 request/indication to FE6. 502
7.3.6
7.4
Recognise a specific condition where interception delayed has to be disabled (e.g. the call is directed to an attendant) and send rc_INTERCEPT_DISABLE request/indication to FE3.
Send the intercepted-to user’s name, name presentation indicator and number presentation indicator in rd_INFORM6 request/indication to FE3 on receipt of r3_REPORT request/indication, if possible, or at the latest on answer.
F u n c t io n a l e n t it y a c t io n s o f F E6 601 Deliver notifications to the intercepted-to user as received from FE5.
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 ITU-T Rec. Z.100 (1999).
- 29 -
7.4.1
Be h a v io u r o f F E1 Figure 11 shows the normal behaviour of FE1. Output signals to the left represent primitives to the user. Input signals from the right represent information flows from FE2.
Figure 11 - ANF-CINT, SDL for functional entity FE1
- 30 -
7.4.2
Be h a v io u r o f F E2 Figure 12 shows the normal behaviour of FE2. Output signals to the left represent information flows to other functional entities. Input signals from the right represent information flows from other functional entities, and input signals from the left represent primitives from local CC.
Figure 12 - ANF-CINT, SDL for functional entity FE2
- 31 -
7.4.3
Be h a v io u r o f F E3 Figure 13 shows the normal behaviour of FE3. Output signals to the right and to the left represent information flows to other functional entities. Input signals from the right represent information flows from other functional entities, and input signals from the left represent primitives from the local CC or from the ANF-CINT user. The relationship to the basic call process is indicated in task symbols.
Figure 13 - ANF-CINT, SDL for functional entity FE3 (part 1)
- 32 -
Figure 13 - ANF-CINT, SDL for functional entity FE3 (part 2) NOTE 1 Any further interception will be treated as interception delayed, because the original call is already in an alerting or waiting on busy state.
- 33 -
7.4.4
Be h a v io u r o f F E4 Figure 14 shows the normal behaviour of FE4. Output signals to the left represent information flows to other functional entities. Input signals from the right represent internal stimuli.
Figure 14 - ANF-CINT, SDL for functional entity FE4
- 34 -
7.4.5
Be h a v io u r o f F E5 Figure 15 shows the normal behaviour of FE5. Output signals to the right and to the left represent information flows to other functional entities. Input signals from the left represent information flows from other functional entities. Input signals from the right represent primitives from the local CC.
- 35 -
Figure 15 - ANF-CINT, SDL for functional entity FE5
- 36 -
7.4.6
Be h a v io u r o f F E6 Figure 16 shows the normal behaviour of FE6. Output signals to the right represent primitives to the user. Input signals from the left represent information flows from FE5.
Figure 16 - ANF-CINT, SDL for functional entity FE6
- 37 -
7.5
Allocation of functional entities to physical equipment The allocations of FEs to physical equipment shown in table 8 shall apply. In the table, 'TE' represents a TE attached to a PISN. Where a terminal involved is stimulus with respect to ANF-CINT, any FE shown as residing in the TE shall reside instead in that TE's local PINX. Table 8 - Scenarios for the allocation of FEs to physical equipment FE1
FE2
FE3
FE4
FE5
FE6
Scenario 1
TE at the Originating PINX
Originating PINX
Originating PINX
Terminating PINX
Interceptedto PINX
TE at the Interceptedto PINX
Scenario 2
TE at the Originating PINX
Originating PINX
Transit PINX
Terminating PINX
Interceptedto PINX
TE at the Interceptedto PINX
Scenario 3
TE at the Originating PINX
Originating PINX
Originating PINX
Transit PINX
Interceptedto PINX
TE at the Interceptedto PINX
Scenario 4
TE at the Originating PINX
Originating PINX
Transit PINX
Transit PINX
Interceptedto PINX
TE at the Interceptedto PINX
Scenario 5
TE at the Originating PINX
Originating PINX
Originating PINX
Outgoing Gateway PINX
Interceptedto PINX
TE at the Interceptedto PINX
Scenario 6
TE at the Originating PINX
Originating PINX
Transit PINX
Outgoing Gateway PINX
Interceptedto PINX
TE at the Interceptedto PINX
Scenario 7
TE at the Originating PINX
Originating PINX
Terminating PINX
Terminating PINX
Interceptedto PINX
TE at the Interceptedto PINX
Scenario 8
TE at the Originating PINX
Originating PINX
Originating PINX
Originating PINX
Interceptedto PINX
TE at the Interceptedto PINX
Scenario 9
TE at the Originating PINX
Originating PINX
Outgoing
Outgoing
Gateway PINX
Gateway PINX
Interceptedto PINX
TE at the Interceptedto PINX
(NOTE)
(NOTE)
(NOTE)
NOTE Scenarios where FE3 is located at a Transit PINX may be subject to restriction specified in stage 3 specifications.
- 38 -
7.6
Interworking considerations When interworking with another network that supports an equivalent feature, any of the following FEs can be located in the other network (the remaining FEs being located in the PISN in accordance with 7.5): • • • • • •
FE1 and FE2; FE5 and FE6; FE4; FE3, FE4, FE5, and FE6; FE1, FE2, FE3 and FE4; FE1, FE2, FE3, FE5 and FE6.
In addition, FE1 can be located in the other network with FE2 located at the Incoming Gateway PINX, and FE6 can be located in the other network with FE5 located at the Outgoing Gateway PINX. When interworking with another network that does not support an equivalent feature, FE2 can be located at the Incoming Gateway PINX with FE1 having null functionality, and FE5 can be located at the Outgoing Gateway PINX with FE6 having null functionality. If FE2 is located in another network or at the Incoming Gateway PINX, FE3 can be located in the Incoming Gateway PINX. If FE3 is located at the Incoming Gateway PINX, FE4 can be located in the Incoming Gateway PINX.
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.