Conceptio › Archive › ECMA International

ECMA Internationalopen access

ECMA-173 — Private Integrated Services Network (PISN) - Specification, functional model and information flows - Call diversion supplementary services (CFSD) (December 2001)

ECMA International · ECMA International

ECMA International · Standards · License: Open Access

ecma ecmainternational flows information integrated model network pisn

ecma, standard, ecma international, specification, ecma-173, ecma 173, 173, private, integrated, services, network, pisn, functional, model, and, information, flows, call, diversion, supplementary, cfsd

S tandard ECMA-173

3rd Edition - December 2001

Standardizing Information

and

Communication

Systems

Private Integrated Services Network (PISN) Specification, Functional Model and Information Flows Call Diversion Supplementary Services

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

S tandard ECMA-173

3rd Edition - December 2001

Standardizing

Information

and

Communication

Systems

Private Integrated Services Network (PISN) Specification, Functional Model and Information Flows Call Diversion Supplementary Services (CFSD)

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

Ecma-173.doc

14-01-02 09,27

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 Diversion supplementary services: • Call Forwarding Unconditional (SS-CFU) • Call Forwarding Busy (SS-CFB) • Call Forwarding No Reply (SS-CFNR) • Call Deflection (SS-CD) 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-173 (published by ECMA in June 1992), the 2nd Edition was extended to include the Call Deflection supplementary service (SS-CD) and changes were incorporated in order to achieve alignment with International Standard ISO/IEC 13872:1995(E) published by ISO/IEC in December 1995. Compared to the 2nd Edition of Standard ECMA-173 (published by ECMA in June 1997), this 3rd Edition incorporates editorial errata and removes all differences with International Standard ISO/IEC 13872:1995.

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

- i -

Table of contents 1

Scope

Conformance

References (normative)

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 Bu sy 4.2.3 Call, basic call 4.2.4 Co n n e c te d n u mb e r 4.2.5 Call Deflection 4.2.6 Call Deflection from Alert 4.2.7 C a l l D e f l e c t i o n I mme d i a t e 4.2.8 D iv e r s io n 4.2.9 D iv e r s io n f r o m A le r t 4.2.10 D iv e r s io n I mme d ia te 4.2.11 D iv e r te d - to n u mb e r 4.2.12 D iv e r te d - to s u b a d d r e s s 4.2.13 D iv e r te d - to u s e r 4.2.14 D iv e r tin g c a u s e 4.2.15 D iv e r tin g n u mb e r 4.2.16 F o r w a r d in g 4.2.17 F o r w a r d s w itc h in g 4.2.18 L a s t d iv e r tin g u s e r 4.2.19 O r i g i n a l c a l l e d n u mb e r 4.2.20 Original called user 4.2.21 P a r tia l r e r o u te in g 4.2.22 P r e s e n ta tio n in d ic a to r 4.2.23 P I S N n u mb e r 4.2.24 Private 4.2.25 Public 4.2.26 Public ISDN 4.2.27 Re r o u te in g 4.2.28 Served user 4.2.29 T e r mi n a l , t e r mi n a l e q u ip me n t 4.2.30 User A 4.2.31 User B 4.2.32 User B1, user B2, user B3, etc. 4.2.33 User C

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

- ii -

Acronyms

S S - C F U 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 atio n P r e s e n ta tio n ( 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 ( 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 atio n P r e s e n ta tio n ( CO 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 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 ( C C B S ) 6.3.8 Co mp le tio n o f Ca lls o n N o Re p ly ( CCN R) 6.3.9 Call Transfer (CT) 6.3.10 Ca ll F o r w a r d in g Bu s y ( CF B) 6.3.11 Ca ll F o r w a r d in g N o Re p ly ( CF N R) 6.3.12 Call Deflection (CD) 6.3.13 P a t h R e p l a c e me n t ( P R ) 6 . 4 I n te r w o r k in g c o n s id e r a tio n s

6 6 6 6 6 6 6 10 11 11 11 11 11 12 12 12 12 12 12 12 12 12 12

S S - C F B s t a g e 1 s p e c if ic a t io n 7 . 1 D e s c r ip tio n 7.1.1 G e n e r a l d e s c r ip tio n 7.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 7.2 Procedures 7.2.1 P r o v is io n /w ith d r a w a l 7.2.2 N o r ma l p r o c e d u r e s 7.2.3 E x c e p tio n a l p r o c e d u r e s 7 . 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 7.3.1 Calling Line Identification Presentation (CLIP) 7.3.2 C o n n e c t e d L i n e I d e n t i f i c atio n P r e s e n ta tio n ( CO L P ) 7.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) 7.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 ) 7.3.5 C o n n e c t e d N a me I d e n t i f i c atio n P r e s e n ta tio n ( CO N P ) 7.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) 7.3.7 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 ( C C B S ) 7.3.8 Co mp le tio n o f Ca lls o n N o Re p ly ( CCN R) 7.3.9 Call Transfer (CT) 7.3.10 Ca ll F o r w a r d in g U n c o n d itio n a l ( CF U ) 7.3.11 Ca ll F o r w a r d in g N o Re p ly ( CF N R)

13 13 13 13 13 13 13 13 13 13 13 13 14 14 14 14 14 14 14 14

- iii -

7.3.12 Call Deflection 7.3.13 P a t h R e p l a c e me n t ( P R ) 7 . 4 I n te r w o r k in g Co n s id e r a tio n s

14 14 14

S S - C F N R s t a g e 1 s p e c if ic a t io n 8 . 1 D e s c r ip tio n 8.1.1 G e n e r a l d e s c r ip tio n 8.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 8.2 Procedures 8.2.1 P r o v is io n /w ith d r a w a l 8.2.2 N o r ma l p r o c e d u r e s 8.2.3 E x c e p tio n a l P r o c e d u r e s 8 . 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 8.3.1 Calling Line Identification Presentation (CLIP) 8.3.2 C o n n e c t e d L i n e I d e n t i f i c atio n P r e s e n ta tio n ( CO L P ) 8.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) 8.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 ) 8.3.5 C o n n e c t e d N a me I d e n t i f i c atio n P r e s e n ta tio n ( CO N P ) 8.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) 8.3.7 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 ( C C B S ) 8.3.8 Co mp le tio n o f Ca lls o n N o Re p ly ( CCN R) 8.3.9 Call Transfer (CT) 8.3.10 Ca ll F o r w a r d in g U n c o n d itio n a l ( CF U ) 8.3.11 Ca ll F o r w a r d in g Bu s y ( CF B) 8.3.12 Call Deflection (CD) 8.3.13 P a t h R e p l a c e me n t ( P R ) 8 . 4 I n te r w o r k in g Co n s id e r a tio n s

15 15 15 15 15 15 15 15 16 16 16 16 16 16 16 16 16 17 17 17 17 17 17

S S - C D s t a g e 1 s p e c if ic a t io n 9 . 1 D e s c r ip tio n 9.1.1 G e n e r a l d e s c r ip tio n 9.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 9.2 Procedures 9.2.1 P r o v is io n /w ith d r a w a l 9.2.2 N o r ma l p r o c e d u r e s 9.2.3 E x c e p tio n a l P r o c e d u r e s 9 . 3 I n te r a c tio n 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 9.3.1 Calling Line Identification Presentation (CLIP) 9.3.2 C o n n e c t e d L i n e I d e n t i f i c atio n P r e s e n ta tio n ( CO L P ) 9.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) 9.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 ) 9.3.5 C o n n e c t e d N a me I d e n t i f i c atio n P r e s e n ta tio n ( CO N P ) 9.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) 9.3.7 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 ( C C B S ) 9.3.8 Co mp le tio n o f Ca lls o n N o Re p ly ( CCN R) 9.3.9 Call Transfer (CT)

18 18 18 18 18 18 18 19 19 19 19 19 19 19 19 19 20 20

- iv -

9.3.10 Ca ll F o r w a r d in g U n c o n d itio n a l ( CF U ) 9.3.11 Ca ll F o r w a r d in g o n Bu s y ( CF B) 9.3.12 Ca ll F o r w a r d in g o n N o Re p ly ( CF N R) 9.3.13 P a t h R e p l a c e me n t ( P R ) 9 . 4 I n te r w o r k in g c o n s id e r a tio n s 9.5 Overall SDL

20 20 20 20 20 20

10 S S - D I V s t a g e 2 s p e c if ic a t io n 10.1 F u n c tio n a l mo d e l 10.1.1 F u n c tio n a l mo d e l d e s c r ip tio n 10.1.2 Description of the functional entities 10.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 10.2 I n f o r ma t i o n f l o w s 10.2.1 D e f in itio n o f in f o r ma tio n f lo w s 10.2.2 E x a mp le s o f in f o r ma tio n f lo w s e q u e n c e s 10.3 Functional entity actions 10.3.1 Functional entity actions of FE1 10.3.2 Functional entity actions of FE2 10.3.3 Functional entity actions of FE3 10.3.4 Functional entity actions of FE4 10.3.5 Functional entity actions of FE5 10.3.6 Functional entity actions of FE6 10.3.7 Functional entity actions of FE7 10.3.8 Functional entity actions of FE8 10.3.9 Functional entity actions of FE9 10.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 10.4.1 Be h a v io u r o f F E 1 10.4.2 Be h a v io u r o f F E 2 10.4.3 Be h a v io u r o f F E 3 10.4.4 Be h a v io u r o f F E 4 10.4.5 Be h a v io u r o f F E 5 10.4.6 Be h a v io u r o f F E 6 10.4.7 Be h a v io u r o f F E 7 10.4.8 Be h a v io u r o f F E 8 10.4.9 Be h a v io u r o f F E 9 10.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 10.6 I n te r w o r k in g c o n s id e r a tio n s

24 24 24 25 26 28 28 37 55 55 55 55 56 56 57 57 57 57 57 57 58 60 62 66 67 69 70 71 72 73

Annex A - Bibliography

Scope This Standard specifies the supplementary services Call Forwarding Unconditional (CFU), Call Forwarding Busy (CFB), Call Forwarding No Reply (CFNR) and Call Deflection (CD), which are applicable to various basic services supported by Private Integrated Services Networks (PISN). Basic services are specified in ECMA-142. SS-CFU, SS-CFB and SS-CFNR are supplementary services which apply during call establishment providing a diversion of an incoming call to an other destination. SS-CD is a supplementary service which allows a served user to respond to an incoming call by requesting redirection of that call to another number specified in the response. Supplementary 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 the Call Diversion supplementary services. The stage 1 specifications (clauses 6, 7, 8 and 9) specify the supplementary services as seen by users of PISNs. The stage 2 specification (clause 10) identifies the functional entities involved in the supplementary services and the information flows between them.

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 services 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 clauses 6, 7, 8 and 9 (stage 1) and clause 10 (stage 2) which are relevant to the interface or equipment to which the stage 3 standard applies. A stage 3 standard for SS-CFU shall support clauses 6 and 10 respectively. A stage 3 standard for SS-CFB shall support clauses 7 and 10 respectively. A stage 3 standard for SS-CFNR shall support clauses 8 and 10 respectively. A stage 3 standard for SS-CD shall support clauses 9 and 10 respectively.

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-148

Private Integrated Services Network (PISN) - Specification, Functional Model and Information Flows - Identification Supplementary Services (International Standard ISO/IEC 14136)

ECMA-155

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

ECMA-163

Private Integrated Services Network (PISN) - Specification, Functional Model and Information Flows - Name Identification Supplementary Services (International Standard ISO/IEC 13864)

ETS 300 387

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

- 2 -

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)

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)

– Integrated Services Digital Network

(ITU-T Rec. I.112)

– Service

(ITU-T Rec. I.112)

– Signalling

(ITU-T Rec. I.112)

– Supplementary Service

(ITU-T Rec. I.210)

– Private Integrated services Network eXchange (PINX)

(ECMA-133)

– Private Integrated Services Network (PISN)

(ECMA-133)

– 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 – REPORT request/indication – RELEASE request/indication – SETUP request/indication – SETUP response/confirmation – SETUP REJECT 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 An Additional network feature (ANF) is a capability, over and above that of a basic service, provided by a PISN, but not directly to a PISN user.

4.2.2

Bu s y An ISDN destination is considered to be busy if either a "network determined user busy" or a "user determined user busy" condition exists.

- 3 -

4.2.3

C a ll, b a s ic c a ll A call or basic call is an instance of the use of a basic service.

4.2.4

Connected number The number of the user that answers (User C).

4.2.5

C a ll D e f le c t io n Call deflection is the type of diversion invoked by a served user's request.

4.2.6

C a ll D e f le c t io n f r o m A le r t Call Deflection from Alert (CDA) is the type of diversion invoked by a served user's request during the alerting phase of an incoming call.

4.2.7

Call Deflection Immediate Call Deflection Immediate (CDI) is the type of diversion invoked by a served user's request immediately after the receipt of an incoming call.

4.2.8

D iv e r s io n Diversion is the redirection of a call, on behalf of a called user and prior to answer, to a number different from the number of that called user.

4.2.9

D iv e r s io n f r o m A le r t Diversion from Alert is the type of diversion invoked from an alerting state. NOTE Diversion from Alert can occur as a result of the supplementary services CFNR and CD as specified in this Standard.

4.2.10

Diversion Immediate Diversion Immediate is the type of diversion invoked prior to reaching the alerting state. NOTE Diversion Immediate can occur as a result of the supplementary services CFB, CFU and CD as specified in this Standard.

4.2.11

D iv e r t e d - t o n u m b e r The diverted-to number is the number to which a call is diverted.

4.2.12

D iv e r t e d - t o s u b a d d r e s s The diverted-to subaddress is the subaddress to which a call is diverted.

4.2.13

D iv e r t e d - t o u s e r The diverted-to user is the user to which a call is diverted.

4.2.14

D iv e r t in g c a u s e The diverting cause is a parameter which contains the reason for the diversion: CD, CFU, CFB, CFNR.

4.2.15

D iv e r t in g n u m b e r The diverting number is the number of the served user.

4.2.16

F o r wa r d in g Forwarding is the type of diversion invoked automatically by the network in accordance with information previously registered in the network against the called number.

4.2.17

F o r wa r d s wit c h in g A network routeing algorithm which performs the diversion by joining together the first connection from User A's node to User B's node and a second, new connection from User B's node to User C's node.

4.2.18

La s t d iv e r t in g u s e r The last diverting user is the served user from the point of view of the diverted-to user for a particular stage of call diversion. In the case of a call subject to a single stage of call diversion, User B is the last diverting user from the point of view of User C. In the case of a call subject to multiple stages of call

- 4 -

diversion, user B1 is the last diverting user from the point of view of user B2, user B2 is the last diverting user from the point of view of user B3, etc. The served user for the final stage of call diversion is the last diverting user from the point of view of User C. 4.2.19

O r ig in a l c a lle d n u m b e r The original called number is the number of User B (in case of multiple call diversion user B1).

4.2.20

O r ig in a l c a lle d u s e r The original called user is the first served user of a call which is subject to one or more stages of call diversion, i.e. User B or B1.

4.2.21

Partial rerouteing A network routeing algorithm which performs the call diversion by replacing a particular part of the connection from User A's node (located in the public ISDN) to User B's node (located in a PISN) by another connection from User A's node to User C's node (located in the public ISDN). The new connection is established completely within the public ISDN by joining together the original connection from User A's node to the public ISDN gateway node and a second, new connection from the public ISDN gateway node to User C's node.

4.2.22

P r e s e n t a t io n in d ic a t o r The presentation indicator is the indicator showing whether the diverted-to number should be presented to the calling user, as derived from User C's COLR supplementary service.

4.2.23

PISN number A PISN number is a number belonging to a PISN numbering plan (E.164 ISDN/Private/Implicit numbering plan) specified in ECMA-155.

4.2.24

P r iv a t e An attribute indicating that the application of the so qualified item, e.g. a network, a unit of equipment, a service, is offered to or is in the interest of a determined set of users.

4.2.25

P u b lic An attribute indicating that the application of the so qualified item, e.g. a network, a unit of equipment, a service, is offered to the general public.

4.2.26

P u b lic I S D N A public telecommunication network which supports ISDN services between any two T-reference points.

4.2.27

R e r o u t e in g A network routeing algorithm which performs the call diversion by replacing the connection from User A's node to User B's node by another connection from User A's node to User C's node.

4.2.28

Served user The served user is the user of a particular PISN number who is requesting that calls to his number be diverted. This user may also be referred to as the diverting user or the called user.

4.2.29

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

4.2.30

User A User A is the calling user of a call which is subject to call diversion.

4.2.31

User B User B is the served (diverting) user of a call which is subject to call diversion.

4.2.32

User B1, user B2, user B3, etc. These are the served (diverting) users of a call which are subject to multiple stages of diversion. B1 is the first served user, B2 is the second served user, B3 is the third served user, etc.

- 5 -

NOTE B2 is also the diverted-to user with respect to the first stage of call diversion, B3 is also the diverted-to user with respect to the second stage of call diversion, etc. 4.2.33

User C User C is the diverted-to user with respect to the final stage of call diversion.

Acronyms ANF

Additional Network Feature

Call Control (functional entity)

CCA

Call Control Agent (functional entity)

CDA

Call Deflection from Alert

CDI

Call Deflection Immediate

CLIP

Calling Line Identification Presentation

CLIR

Calling/Connected Line Identification Restriction

CNIP

Calling Name Identification Presentation

CNIR

Calling/Connected Name Identification Restriction

COLP

Connected Line Identification Presentation

CONP

Connected Name Identification Presentation

DIVA

Diversion from Alert

DIVI

Diversion Immediate

DTN

Diverted-to number

Functional Entity

ISDN

Integrated Services Digital Network

MSN

Multiple Subscriber Number

NDUB

Network Determined User Busy

NSO

Notification Subscription Option

PINX

Private Integrated services Network eXchange

PISN

Private Integrated Services Network

SDL

Specification and Description Language

SS-CD, CD

Call Deflection supplementary service

SS-CF, CF

Call Forwarding supplementary services

SS-CFB, CFB

Call Forwarding Busy supplementary service

SS-CFNR, CFNR

Call Forwarding No Reply supplementary service

SS-CFU, CFU

Call Forwarding Unconditional supplementary service

SS-DIV, DIV

Call Diversion supplementary services

Terminal Equipment

UDUB

User Determined User Busy

- 6 -

SS-CFU stage 1 specification

6.1

Description

6.1.1

General description SS-CFU enables a served user to have the PISN redirect to another user calls which are addressed to the served user's PISN number. SS-CFU may operate on all calls or just those associated with specified basic services. The served user's ability to originate calls is unaffected by SS-CFU. After CFU has been activated calls are forwarded independently of the status of the served user. CFU is provided on a per PISN number basis. The maximum number of diversions to a single call is an implementation option. When counting the number of diversions, all types of diversions shall be included.

6.1.2

6.2

Qualifications on applicability to telecommunication services This supplementary service 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 Provision and withdrawal of CFU shall be by pre-arrangement with the service provider. CFU subscription shall be on a per PISN number basis. For each PISN number, the supplementary service may be subscribed to collectively for all basic services subscribed to at that PISN number or for only some of the basic services subscribed to at that PISN number. The subscription parameters and values offered by a PISN are an implementation matter. A stage 3 standard shall support the parameters and values specified in table 1. A PISN may offer more or less parameters and values than those specified in table 1. Parameters apply separately to each basic service subscribed to on each PISN number. For each subscription parameter only one value is selectable. Table 1 - Subscription options Subscription Parameter

Value

Served user receives notification that call has been diverted

- No - Yes

Calling user receives notification that call has been diverted

- No - Yes without diverted-to number/name - Yes with diverted-to number/name

Served user releases his/her number/name to diverted to user

- No - Yes

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 CFU may be either permanently activated or activated/deactivated under user control. If activation/deactivation is under user control, the PISN may optionally provide for activation/deactivation by the served user (local activation/deactivation), by another user (remote activation/ deactivation) or both. The PISN may provide interrogation, which can be local, remote or both. Registration of information is performed on activation of CFU. There are no separate registration procedures. 6.2.2.1.1

Lo c a l a c t iv a t io n /d e a c t iv a t io n The served user shall be able to activate CFU separately for each basic service for which CFU is subscribed to and thereby request a different diverted-to number and/or subaddress for each basic

- 7 -

service for which CFU is subscribed to, and/or shall be able to activate CFU for all basic services for which CFU is subscribed to. To activate CFU, the served user shall supply: 1. the diverted-to number, which may be accompanied by a diverted-to subaddress; 2. information as to whether CFU is to apply to all basic services for which CFU is subscribed to or to a specified basic service out of the basic services for which CFU is subscribed to; 3. where there is more than one PISN number assigned to the access (i.e. in the context of an MSN arrangement), the PISN number for which CFU shall apply. Verification that the diverted-to number exists and that the specified basic service is subscribed to at that number may be carried out before accepting the CFU activation request. The service provider shall return notification of acceptance of the request. Notification of acceptance shall include the number of the diverted-to user to whom the CFU is active. If a single number is used by more than one terminal, activation/deactivation of CFU shall be possible from any terminal which uses this number. When the served user has more than one compatible terminal for the basic service(s) specified at activation time, notification of successful activation/deactivation shall be sent to all the compatible terminals. In the absence of any of the parameters in the activation procedure (e.g. the diverted-to number), default parameters already known to the PISN may be used. It shall be possible to deactivate CFU by means of an explicit request for deactivation. An explicit request for deactivation shall be treated as follows: – if deactivation of CFU for an individual basic service is requested, it shall be accepted only if CFU is already activated for that basic service and shall result in the discarding of the divertedto number and diverted-to subaddress; – if deactivation of CFU collectively for all basic services is requested, it shall result in the discarding of any diverted-to numbers and diverted-to subaddresses for individual basic services and any diverted-to number and diverted-to subaddress collectively for all basic services. It shall be possible to deactivate CFU by activating CFU to a different diverted-to number and/or diverted-to subaddress. A request for activation of CFU when CFU is already activated shall be treated as follows: – if activation of CFU for an individual basic service is requested, it shall be accepted only if CFU is not already activated collectively for all basic services and, if CFU is already activated for that individual basic service, shall result in the overwriting of the existing diverted-to number and diverted-to subaddress; – if activation of CFU collectively for all basic services is requested, it shall result in the discarding of any existing diverted-to numbers and diverted-to subaddresses for individual basic services and the overwriting of any existing diverted-to number and diverted-to subaddress collectively for all basic services. 6.2.2.1.2

R e m o t e a c t iv a t io n /d e a c t iv a t io n Remote activation/deactivation of CFU shall use one or more of the following procedures: 1. A special authorized user may activate and/or deactivate CFU at the served user. Authorization shall be implementation dependent (e.g. attendants may be authorized). 2. A user may activate CFU at the served user such that the activating user becomes the diverted-to user, subject to the served user having remote activation enabled in advance. The intended diverted-to user shall be able to activate CFU regardless of whether CFU is already active. The served user may disable a remote activation at any time. If the disable procedure is performed whilst CFU is activated, the CFU shall not be automatically deactivated. The enable and disable procedure may be performed either by the served user or by an implementation specific entity.

- 8 -

3. The diverted-to user may deactivate CFU at the served user. This shall not be dependent on whether the served user has enabled remote activation. The diverted-to user shall lose this capability as soon as CFU is deactivated in this way, and shall not regain the capability if CFU is activated again to a different diverted-to user. 4. The diverted-to user, at the same time as deactivating CFU in accordance with item 3. above, may be able to activate CFU from the served user to another diverted-to user (i.e. change the destination of CFU). The diverted-to user shall lose this capability as soon as CFU is reactivated in this way. The new diverted-to user shall gain the capability. When a remote activation/deactivation procedure is performed successfully, the served user and the activating/ deactivating user shall be notified. The notification to the served user shall include the number of the diverted-to user and the basic service. It shall be possible, that the served user activates CFU and the remote user deactivates CFU and vice versa. NOTE The use of a password facility for remote activation as an implementation option is not excluded. 6.2.2.1.3

Lo c a l in t e r r o g a t io n If local interrogation is provided, a PISN shall support interrogation on a per number basis for all basic services and/or for a user specified basic service. Where there is more than one PISN number assigned to the access (i.e. in the context of an MSN arrangement), the user shall apply the PISN number for which interrogation of CFU is required. The PISN response to an interrogation request shall provide the following information to the user: • activated or deactivated state of the supplementary service, • if activated: – diverted-to number and, if applicable, diverted-to subaddress – whether activated for all basic services or an individual basic service and the identity of the individual basic service. As additional information, the interrogation may provide information to the served user, whether remote activation has been enabled (allowed). Where interrogation is for all basic services for which CFU is subscribed to and CFU has been activated separately for more than one basic service, the above information shall be repeated for each activation.

6.2.2.1.4

R e m o t e in t e r r o g a t io n If remote interrogation is provided, it shall be possible from one or both of the following remote users: 1. A special authorized user may interrogate CFU conditions on the served user. Authorization shall be implementation dependent (e.g. attendants may be authorized). 2. The diverted-to user may interrogate CFU at the served user. The remote interrogation request and response shall include the information as specified for local interrogation and additionally the PISN number of the served user.

6.2.2.2

I n v o c a t io n a n d o p e r a t io n All incoming calls indicating a basic service for which CFU is active shall be diverted without being presented to the served user.

- 9 -

6.2.2.2.1

S e r v e d u s e r n o t if ic a t io n The served user, as a subscription option, may receive notification of the diversion (but will not be able to answer the incoming call). This notification shall be given as soon as the PISN originates the call to the diverted-to user and shall include the following information (on the call that has been diverted): 1. Indication that a call has been forwarded and the reason (CFU); 2. Bearer Capability information and, if available, High Layer Compatibility information and Low Layer Compatibility information; 3. User B's number (applicable in the context of an MSN arrangement); If a previous diversion has occurred, the notification shall include in addition: 4. last diverting user's number, if presentation is permitted by the last diverting user; 5. cause for last diversion. If more than one previous diversion has occurred, the notification shall also include: 6. original called user's number, if presentation is permitted by the original called user; 7. cause for original diversion

6.2.2.2.2

D iv e r t e d - t o u s e r n o t if ic a t io n The diverted-to user shall receive an indication that the call has been diverted with the appropriate diversion cause. According to the served user's subscription option, the diverted-to user may receive the served user's number. If multiple diversion has occurred, the diverted-to user may receive the original called user's number and the last diverting user's number, according to subscription options at those two users. When multiple diversion occurs, the diverted-to user may receive the reason for the original diversion as well as for the last diversion. The notification to the diverted-to user may, provided the subscription options allow, additionally include the identification of the served user's name (in case of multiple diversion the name of the original called user and of the last diverting user).

6.2.2.2.3

Calling user notification As a subscription option of the served user, the calling user may receive a notification that the call has been diverted and as an additional option that notification may include the diverted-to user's number. For single diversion, notifications shall be sent to the calling user depending on the subscription option of the served user as follows: • If "No", no notification shall be sent to User A. • If "Yes, without diverted-to number/name", a notification without number/name shall be sent to User A. • If "Yes, with diverted-to number/name", a notification with User C's number and optionally the User C's name shall be sent to User A if CLIR/CNIR is not invoked by User C. For multiple diversions, notifications shall be sent to the calling user depending on the subscription options of the served users as follows: • If user B1 has "No", no notification shall be sent to User A. • If user B1 does not have "No", a notification shall be sent to User A as a result of the diversion at user B1. Diversions at successive served users B2, B3, etc. each shall also result in a notification to User A, but only if both – the alerting state has been reached at the served user, and – none of the served users has the "No" option.

- 10 -

The number and optionally the name of User C shall be sent to User A, but only if both • all served users have "Yes, with diverted-to number/name", and • CLIR/CNIR is not invoked by User C. In addition, the number and optionally the name of a user Bn may be sent to User A, if the alerting state has been reached at user Bn, if all users B1 to Bn-1 have "Yes, with diverted-to number/name", and if there is no possibility of CLIR/CNIR being invoked at user Bn. 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 If the PISN cannot accept an activation request, the activating user shall receive a notification that CFU activation was unsuccessful. Possible causes for rejection are e.g.: – service or option not subscribed to, – insufficient information, – diverted-to number is a special service code (e.g. police), – diverted-to number is the served user's number, – diverted-to number is an invalid PISN number, – basic service to which relevance is requested is not subscribed to, – incorrect served user's number. If the PISN cannot accept a deactivation request, the deactivating user shall receive a notification that CFU deactivation was unsuccessful. Possible causes for rejection are e.g.: – service or option not subscribed to, – insufficient information, – service not activated, – incorrect served user's number. In case of remote activation/deactivation the notification of an unsuccessful activation/deactivation request shall be sent to the activating/deactivating user only. 6.2.3.2

I n t e r r o g a t io n If the PISN cannot accept an interrogation request, the interrogating user shall receive a notification that CFU interrogation was unsuccessful. Possible causes for rejection are e.g.: – service or option not subscribed to, – insufficient information, – basic service to which relevance is requested is not subscribed to.

6.2.3.3

I n v o c a t io n a n d o p e r a t io n CFU shall not be invoked on a call to the served user if the call uses a basic service for which CFU has not been activated. In cases where a calling user normally receives, as part of notification, the number of the diverted-to user, the last diverting user or the original called user and this number 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 cases where a calling user normally receives, as part of notification, the name of the diverted-to user, the last diverting user or the original called user and this name is unavailable (e.g. due to name presentation restriction, or interworking), the user who would have been given the name shall receive an indication of the reason why no number is given. Within a PISN the total number of all diversions for each call shall be limited. The maximum number of such diversions for each call shall be an implementation option. When counting the number of

- 11 -

diversions, all types of diversions shall be included. If the limit is reached and an attempt is made to divert the call an additional time, either the calling user shall receive call clearing with an appropriate cause or further diversions shall be overridden by offering the call to the served user. If the diverted call cannot be completed to the diverted-to destination, then the PISN shall clear the call. Specifically, if CFU has been invoked and CFNR has not occurred previously during the call setup, then the call shall be cleared back towards the calling user and to the calling user shall be sent an indication that the call cannot be completed. This indication shall not reveal that the call has been diverted. If CFNR has previously occurred, then the procedures for the failure of CFNR shall apply. The diversion may be overridden for specific calls, e.g. calls from the diverted-to user to the diverting user. The conditions for this shall be implementation specific.

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.3.1

Calling Line Identification Presentation (CLIP) Served user: If subscribed to, the served user shall receive, as part of the served user notification of diversion, the Calling Line Identification of the diverted call, unless CLIR applies and the served user has no override capability. Diverted-to users, who have subscribed to CLIP shall receive the calling user's number unless CLIR applies and the diverted-to user has no override capability.

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 ) If the served user, or any served user in the case of multiple diversions, subscribes to the option that the calling user is not notified of diversion, then the calling user shall not be provided with COLP, unless the calling user has override capability. If the served user, or any served user in the case of multiple diversions, subscribes to the option that the calling user is notified, but without the diverted-to user number, then the calling user shall not be provided with COLP, unless the calling user has an overide capability.

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 ) When diversion occurs, the number of a calling PISN user which has invoked CLIR, shall not be presented to the diverting user or the diverted-to user, unless the diverting user or diverted-to user has the service profile to override this restriction. A diverted-to user which has invoked CLIR shall not have its number presented to the calling user, either as CONP or as part of a notification of diversion, unless the calling user has an override service profile. A diverted-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 call diversion until the diverted-to user has responded and it is known that restriction is not to be invoked, unless the calling user has an override service profile. NOTE The diverted-to user's number can still be released on answer, after confirmation, or using the default. In each of the above situations, a calling user that subscribes to COLP and who has override capability shall not be able to receive the diverted-to user's number as part of the diverting notification information, but can invoke COLP with override in order to receive the connected line identity when the call is answered.

6.3.4

Calling Name Identification Presentation (CNIP) Diverted-to users who have subscribed to CNIP shall receive the calling user's name unless CNIR has been invoked and the diverted-to user has no override capability. In addition, unless restriction applies and the served user has no override capability, the served user (or users if the call is diverted more than once) shall receive the name of the calling user as part of any notification to the served user that a call has been diverted.

- 12 -

6.3.5

Connected Name Identification Presentation (CONP) If the served user, or any served user in the case of multiple diversions, subscribes to the option that the calling user is not notified of diversion, then the calling user shall not be provided with CONP, unless the calling user has override capability. If the served user, or any served user in the case of multiple diversions, subscribes to the option that the calling user is notified, but without the diverted-to user number/name, then the calling user shall not be provided with CONP, unless the calling user has an overide capability. In all other cases, the provision of the diverted-to user's name shall be in accordance with CONP.

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 ) When diversion occurs, the name of a calling PISN user which has invoked CNIR shall not be presented to the diverting user or the diverted-to user, unless the diverting user or diverted-to user has the service profile to override this restriction. A diverted-to user which has invoked CNIR shall not have its name presented to the calling user, either as CONP or as part of a notification of diversion, unless the calling user has an override service profile. A diverted-to user which is provided with CNIR temporary mode shall not have its identity revealed to the calling user as part of a notification of call diversion until the diverted-to user has responded and it is known that restriction is not to be invoked, unless the calling user has an override service profile. NOTE The invocation of CNIR at the diverting user has no impact on Call Diversion.

6.3.7

Completion of Calls to Busy Subscriber (CCBS) If the call to User B is diverted to User C by CFU and User C is busy, then a CCBS request from User A shall be applied to the diverted-to User C. If User B activates CFU after User A has requested CCBS and whilst the CCBS recall has not yet been accepted by User A, then the CCBS request shall either continue to be applied to User B or be cancelled. If a user invokes CCBS whilst CFU is activated, or a user invokes CCBS and subsequently activates CFU, CCBS Recall shall still be given to that user.

6.3.8

Completion of Calls on No Reply (CCNR) If the call to User B is diverted to User C by CFU and User C does not answer, then a CCNR request from User A shall be applied to the diverted-to User C. If User B activates CFU after User A has requested CCNR and whilst the CCNR recall has not yet been accepted by User A, then the CCNR request shall either continue to be applied to User B or be cancelled. If a user invokes CCNR whilst CFU is activated, or a user invokes CCNR and subsequently activates CFU, CCNR Recall shall still be given to that user.

6.3.9

C a ll Tr a n s f e r ( C T) No interaction.

6.3.10

C a ll F o r wa r d in g Bu s y ( C F B) The invocation of CFU shall take precedence over CFB.

6.3.11

C a ll F o r wa r d in g N o R e p ly ( C F N R ) The invocation of CFU shall take precedence over CFNR.

6.3.12

C a ll D e f le c t io n ( C D ) No interaction.

6.3.13

Path Replacement (PR) No interaction.

6.4

Interworking considerations Interworking with other networks is optional. When interworking with another network, the implementation specific limit of the total number of known diversions for each call shall still apply.

- 13 -

Where a remote user is on a different network, notifications to the remote user, if applicable, shall be sent to the remote user's network for delivery to the remote user. Numbers included in this information shall be provided as required for the other network. If the private network detects diversion back to a destination in the public network, the private network may request that diversion is performed by the public network. The PISN may activate, deactivate and interrogate CFU in the public ISDN on behalf of a PISN user.

SS-CFB stage 1 specification

7.1

Description

7.1.1

General description SS-CFB enables a served user to have the PISN redirect to another user calls which are addressed to the served user's PISN number and meet busy. SS-CFB may operate on all calls or just those associated with specified basic services. The served user's ability to originate calls is unaffected by SS-CFB. CFB is provided on a per PISN number basis. The maximum number of diversions to a single call is an implementation option. When counting the number of diversions, all types of diversions shall be included.

7.1.2

7.2

Qualifications on applicability to telecommunication services This supplementary service is applicable to all basic services defined in ECMA-142.

Procedures

7.2.1

P r o v is io n /wit h d r a wa l 6.2.1 shall apply with "CFU" replaced by "CFB".

7.2.2 Normal procedures 7.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 6.2.2.1 shall apply with "CFU" replaced by "CFB". 7.2.2.2

I n v o c a t io n a n d o p e r a t io n All incoming calls indicating a basic service for which CFB is active shall be diverted if the served user is busy.

7.2.2.2.1

S e r v e d u s e r n o t if ic a t io n 6.2.2.2.1 shall apply with "CFU" replaced by "CFB".

7.2.2.2.2

D iv e r t e d - t o u s e r n o t if ic a t io n 6.2.2.2.2 shall apply.

7.2.2.2.3

Calling user notification 6.2.2.2.3 shall apply.

7.2.3

7.3

Ex c e p t io n a l p r o c e d u r e s 6.2.3 shall apply with "CFU" replaced by "CFB".

7.3.1

Calling Line Identification Presentation (CLIP) 6.3.1 shall apply.

7.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 ) 6.3.2 shall apply.

7.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 ) 6.3.3 shall apply.

- 14 -

7.3.4

Calling Name Identification Presentation (CNIP) 6.3.4 shall apply.

7.3.5

Connected Name Identification Presentation (CONP) 6.3.5 shall apply. In addition, as an implementation option, if User C is also busy, the original user's name may be presented to the calling user instead of the user's C name.

7.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 ) 6.3.6 shall apply.

7.3.7

Completion of Calls to Busy Subscriber (CCBS) If the call to User B is diverted to User C by CFB and User C is busy, then a CCBS request from User A shall be applied either to the diverted-to User C or to the originally called User B. If User B activates CFB after User A has requested CCBS and whilst the CCBS recall has not yet been accepted by User A, then the CCBS request shall continue to be applied to User B. If a user invokes CCBS whilst CFB is activated, or a user invokes CCBS and subsequently activates CFB, this shall not affect the provision of the CCBS recall to that user.

7.3.8

Completion of Calls on No Reply (CCNR) If the call to User B is diverted to User C by CFB and User C does not answer, then a CCNR request from User A shall be applied to the diverted-to User C. If User B activates CFB after User A has requested CCNR and whilst the CCNR recall has not yet been accepted by User A, then the CCNR request shall continue to be applied to User B. If a user invokes CCNR whilst CFB is activated, or a user invokes CCNR and subsequently activates CFB, this shall not affect the provision of the CCNR recall to that user .

7.3.9

C a ll Tr a n s f e r ( C T) No interaction.

7.3.10

C a ll F o r wa r d in g U n c o n d it io n a l ( C F U ) The invocation of CFU shall take precedence over CFB.

7.3.11

C a ll F o r wa r d in g N o R e p ly ( C F N R ) No interaction.

7.3.12

C a ll D e f le c t io n No interaction. NOTE In case of NDUB (Network Determined User Busy) the call is not presented to the user, and thus CFB takes precedence over CD. If an NDUB condition is not met, the incoming call is presented to the called user and invocation of either CFB or CD depends on the user's response.

7.3.13

7.4

Path Replacement (PR) No interaction.

Interworking Considerations 6.4 shall apply with "CFU" replaced by "CFB".

- 15 -

SS-CFNR stage 1 specification

8.1

Description

8.1.1

General description SS-CFNR enables a served user to have the PISN redirect to another user calls which are addressed to the served user's PISN number and for which the connection is not established within a predefined period of time. SS-CFNR may operate on all calls or just those associated with specified basic services. The served user's ability to originate calls is unaffected by SS-CFNR. CFNR is provided on a per PISN number basis. The maximum number of diversions to a single call is an implementation option. When counting the number of diversions, all types of diversions shall be included.

8.1.2

8.2

Qualifications on applicability to telecommunication services This supplementary service is applicable to all basic services defined in ECMA-142.

Procedures

8.2.1

P r o v is io n /wit h d r a wa l 6.2.1 shall apply with "CFU" replaced by "CFNR".

8.2.2 Normal procedures 8.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 6.2.2.1 shall apply with "CFU" replaced by "CFNR". 8.2.2.2

I n v o c a t io n a n d o p e r a t io n All incoming calls indicating a basic service for which CFNR is active shall be diverted if the served user does not reply within a specified time interval. The original call shall continue to alert the served user, who shall still be able to accept the call until the call to the diverted-to user has reached an alerting state.

8.2.2.2.1

S e r v e d u s e r n o t if ic a t io n 6.2.2.2.1 shall apply with "CFU" replaced by "CFNR".

8.2.2.2.2

D iv e r t e d - t o u s e r n o t if ic a t io n 6.2.2.2.2 shall apply.

8.2.2.2.3

Calling user notification 6.2.2.2.3 shall apply.

8.2.3 Ex c e p t io n a l P r o c e d u r e s 8.2.3.1 A c t iv a t io n /D e a c t iv a t io n 6.2.3.1 shall apply with "CFU" replaced by "CFNR". 8.2.3.2

I n t e r r o g a t io n 6.2.3.3 shall apply.

8.2.3.3

I n v o c a t io n a n d o p e r a t io n CFNR shall not be invoked on a call to the served user if the call uses a basic service for which CFNR has not been activated. In cases where a user normally receives, as part of notification, the number of the diverted-to user, the last diverting user or the original called user and this number 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 can be given. Within a PISN the total number of all diversions for each call shall be limited. The maximum number of such diversions for each call shall be an implementation option. When counting the number of diversions, all types of diversions shall be included. If the limit is reached and an attempt is made to divert the call an additional time, the diversion shall not take place.

- 16 -

If the diverted call cannot be completed to the diverted-to destination, then the PISN shall clear the diverted leg of the call and continue to alert the diverting user. If the diverting user has already been notified of CFNR, then that user shall be notified of failure of CFNR. The call diversion may be overridden for specific calls, e.g. calls from the diverted-to user to the diverting user. The conditions for this shall be implementation specific.

8.3

8.3.1

Calling Line Identification Presentation (CLIP) Diverted-to users, who have subscribed to CLIP shall receive the calling user's number unless CLIR applies and the diverted-to user has no override capability. NOTE If subscribed to, the served (diverting) user receives the Calling Line Identification of all calls, unless CLIR applies and the served user has no override capability.

8.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 ) 6.3.2 shall apply.

8.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 ) 6.3.3 shall apply.

8.3.4

Calling Name Identification Presentation (CNIP) Diverted-to users, who have subscribed to CNIP shall receive the calling user's name unless CNIR has been invoked and the diverted-to user has no override capability. NOTE If subscribed to, the served (diverting) user receives the Calling Name Identification of all calls, unless CNIR applies and the served user has no override capability.

8.3.5

Connected Name Identification Presentation (CONP) If the served user subscribes to the option that the calling user is not notified of call diversion, then the calling user shall not be provided with CONP, unless the calling user has override capability. If the served user subscribes to the option that the calling user is notified, but without the diverted-to user number/name, then the calling user shall not be provided with CONP, unless the calling user has an override capability. In all other cases, the provision of the diverted-to user's name on answer shall be in accordance with CONP. The diverted-to user's name shall not be provided on commencement of alerting.

8.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 ) 6.3.6 shall apply.

8.3.7

C o m p le t io n o f C a lls t o Bu s y S u b s c r ib e r ( C C BS ) If User B activates CFNR after User A has requested CCBS and whilst the CCBS recall has not yet been accepted by User A, then the CCBS request shall continue to be applied to User B. NOTE In such a case, the call resulting from successful completion of CCBS can be subject to CFNR if not answered. If a user invokes CCBS whilst CFNR is activated, or a user invokes CCBS and subsequently activates CFNR, this shall not affect the provision of the CCBS recall to that user.

8.3.8

Completion of Calls on No Reply (CCNR) If the call to User B is diverted to User C by CFNR and User C does not answer, then a CCNR request from User A shall be applied to either User B or User C.

- 17 -

If User B activates CFNR after User A has requested CCNR and whilst the CCNR recall has not yet been accepted by User A, then the CCNR request shall continue to be applied to User B. If a user invokes CCNR whilst CFNR is activated, or a user invokes CCNR and subsequently activates CFNR, this shall not affect the provision of the CCNR recall to that user. 8.3.9

C a ll Tr a n s f e r ( C T) If User C who has subscribed to CFNR, does not answer the transferred call, then upon expiration of the CFNR timer, the CFNR shall be attempted.

8.3.10

C a ll F o r wa r d in g U n c o n d it io n a l ( C F U ) The invocation of CFU shall take precedence over CFNR.

8.3.11

C a ll F o r wa r d in g Bu s y ( C F B) No interaction.

8.3.12

C a ll D e f le c t io n ( C D ) If at one alerting served user there are several diversion requests (CFNR, CDA), the PISN shall only accept the first valid request. After acceptance of a diversion request, new diversion requests (either CFNR or CDA) from the same served user shall not be accepted unless the diverted call of the previously accepted request cannot be completed to the diverted-to destination.

8.3.13

Path Replacement (PR) No interaction.

8.4

Interworking Considerations 6.4 shall apply with "CFU" replaced by "CFNR".

- 18 -

SS-CD stage 1 specification

9.1

Description

9.1.1

General description Call Deflection permits a served user to respond to an incoming call offered by the PISN by requesting diversion of that call to another number specified in the response. This request is only allowed before the called user has answered the call. The served user's originating service is unaffected. CD is invoked on a call by call basis. The maximum number of diversions to a single call is an implementation option. When counting the number of diversions, all types of diversions shall be included.

9.1.2

9.2

Qualifications on applicability to telecommunication services This supplementary service is applicable to all basic services defined in ECMA-142.

Procedures

9.2.1

P r o v is io n /wit h d r a wa l 6.2.1 shall apply with "CFU" replaced by "CD" and table 1 replaced by table 2. Table 2 - Subscription options Subscription Parameter

Value

Calling user receives notification that call has been diverted

- No - Yes, without diverted-to number/name - Yes, with diverted-to number/name

Served user releases his/her number/name to diverted-to user

- No - Yes

9.2.2 Normal procedures 9.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 Activation, deactivation and interrogation procedures are not applicable. 9.2.2.2

I n v o c a t io n a n d o p e r a t io n The served user can respond to an incoming call offered by normal basic call procedure by requesting the Call Deflection service. The request shall contain the diverted-to number. The diverted-to number may be accompanied by a diverted-to subaddress. The served user can request CD either from an alerting state (CDA) or immediately in response to a call request from the PISN (CDI). On acceptance of the CD request, the PISN shall perform the diversion towards the indicated divertedto number. For clearing the call to User B two cases are to be distinguished: 1. CDA: On acceptance of the CD request the original call at the served user shall remain in the alerting state and the served user shall still be able to accept the call until the diverted-to user enters an alerting state. When the diverted-to user enters the alerting state the call to the served user is cleared. 2. CDI: The call to the served user is cleared immediately on acceptance of the CD request.

9.2.2.2.1

S e r v e d u s e r n o t if ic a t io n On acceptance of the CD request the PISN shall send a notification with a positive acknowledgement to the CD request.

9.2.2.2.2

D iv e r t e d - t o u s e r n o t if ic a t io n 6.2.2.2.2 shall apply.

9.2.2.2.3

Calling user notification 6.2.2.2.3 shall apply.

- 19 -

9.2.3 Ex c e p t io n a l P r o c e d u r e s 9.2.3.1 A c t iv a t io n /D e a c t iv a t io n Not applicable. 9.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 PISN cannot accept a CD request, the invoking user shall receive a notification with appropriate cause that the request was unsuccessful. Possible causes for rejection are e.g.: – service or option not subscribed to, – diverted-to number is an invalid PISN number, – diverted-to number is the served user's number, – insufficient information, – incoming call has already been answered, – the number of diversions has reached the upper limit. If the CD request is rejected by the PISN, the PISN shall continue the call at the diverting user. If alerting at the diverting user had begun, the alerting is not interrupted. If the diverted call cannot be completed to the diverted-to destination, then the PISN shall clear the diverted leg of the call. If the served user is still in an alerting state, alerting will continue and the invoking (served) user shall be notified of failure of CD. NOTE After rejection of the CD request or after unsuccessful completion of the diverted call at the divertedto user the served user may again invoke SS-CD.

9.2.3.3

9.3

I n t e r r o g a t io n Not applicable.

Interaction 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.

9.3.1

Calling Line Identification Presentation (CLIP) 8.3.1 shall apply.

9.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 ) 6.3.2 shall apply.

9.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 ) 6.3.3 apply.

9.3.4

Calling Name Identification Presentation (CNIP) 8.3.4 shall apply.

9.3.5

Connected Name Identification Presentation (CONP) 6.3.5 shall apply.

9.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 ) 6.3.6 shall apply.

9.3.7

Completion of Calls to Busy Subscriber (CCBS) If User B deflects an incoming call to User C using CDI and User C is busy, then a CCBS request if made by User A shall be applied to User C. NOTE In case of using CDA, if User C is busy, the call continues alerting User B (see § 9.2.3.2). If CCBS was invoked by User A on User B, then User B shall be able to deflect the CCBS call.

- 20 -

A user shall not be able to deflect a CCBS recall. 9.3.8

Completion of Calls on No Reply (CCNR) If User B deflects an incoming call to User C and User C does not answer, then a CCNR request if made by User A shall be applied to User C. If CCNR was invoked by User A on User B, then User B shall be able to deflect the CCNR call. A user shall not be able to deflect a CCNR recall.

9.3.9

C a ll Tr a n s f e r ( C T) If a user has transferred a call to a user still in the alerting state, then the alerted user may invoke CD in order to divert the transferred call to another user

9.3.10

C a ll F o r wa r d in g U n c o n d it io n a l ( C F U ) No interaction.

9.3.11

C a ll F o r wa r d in g o n Bu s y ( C F B) 7.3.12 shall apply.

9.3.12

C a ll F o r wa r d in g o n N o R e p ly ( C F N R ) 8.3.9 shall apply.

9.3.13

Path Replacement (PR) No interaction.

9.4

Interworking considerations 6.4 shall apply with "CFU" replaced by "CD".

9.5

Overall SDL Figure 1 contains the dynamic description of SS-DIV using the Specification and Description Language (SDL) defined in ITU-T Rec. Z.100. The SDL process represents the behaviour of the PISN in providing SS-DIV. Output signals to the left represent primitives to the calling user. Output signals to the right represent primitives to the served user or to the diverted-to user. Input signals from the right represent internal stimuli.

- 21 -

Idle

valid conditions for call diversion

Initialise diversion counter

1A Increment Diversion counter

Served user to be notified

Notify served user

Initiate call establishment to diverted-to user Indicate to diverted-to user that call has been diverted

DIVA ?

Y Await call establishment

Valid condition for call diversion

Diverted call alerting or answered

Failure to establish diverted call

Cease presentation of call to served user

Notify served user that call is not diverted

call cleared

Served user answered

clear leg to diverted-to user

Idle

F ig u r e 1 - S S - D I V , O v e r a ll S D L ( p a r t 1 )

- 22 -

Served user notification option = No ?

Any served user notification option = No ?

Notify calling calling party of diversion (Note)

First Diversion

First Diversion ?

Idle

Y Notify calling calling party of diversion (Note)

Await possible further diversions

Valid conditions for call diversion

Diversion count limit reached ?

No more diversions required

Call cleared

user C's number/name already sent ?

N Idle

Clear call

Idle

Override diversion

Await possible further diversions

NOTE May be accompanied by a notification of number/name according to the provision in clause 6.2.2.2.3. F ig u r e 1 - S S - D I V , O v e r a ll S D L ( p a r t 2 )

- 23 -

Diversion count limit reached ?

other

N Increment diversion counter

Served user to be notified ?

Clear call

Notify served user

presentation of C's number allowed ?

Override diversion

Notify calling party of diverted-to number

Y Idle

notification option for all served users ? Yes, with number/ name

Await call establishment

N Initiate call establishment to diverted-to user

C's name available and presentation allowed ?

Indicate to diverted-to user that call has been diverted

Notify calling party of diverted-to name

Await call establishment

Idle

F ig u r e 1 - S S - D I V , O v e r a ll S D L ( p a r t 3 )

- 24 -

SS-DIV stage 2 specification This clause defines the stage 2 of the Call Diversion supplementary services (CFU, CFB, CNFR and CD) using the "forward switching" network routeing algorithm and the "rerouteing" network routeing algorithm.

10.1

Functional model

10.1.1

F u n c t io n a l m o d e l d e s c r ip t io n The functional model shall comprise the following functional entities (FEs): FE1: Calling user's service agent FE2: Calling user's service control entity FE3: Call diversion execution entity FE4: Call diversion detection and control entity FE5: Served user's service agent FE6: Diverted-to user's service control entity FE7: Diverted-to user's service agent FE8: User's activation, deactivation and interrogation control entity FE9: User's activation, deactivation and interrogation agent The following functional relationships shall exist between these FEs: ra between FE1 and FE2, rb between FE2 and FE3, rc between FE3 and FE4, rd between FE4 and FE5, re between FE3 and FE6, rf between FE6 and FE7, rg between FE4 and FE8, ri between FE4 and FE6 and rh between FE8 and FE9. Different types of call diversion (e.g. CFU, CFB, CFNR and CD) may be concatenated during multiple call diversion as well as different network routeing algorithms (call diversion by "forward switching" and call diversion by "rerouteing"). Figure 2 shows the FEs and relationships for a single stage of call diversion.

FE1

FE2

FE3

FE4

FE5

rg ri

FE7

FE6

FE8

F ig u r e 2 - F u n c t io n a l M o d e l f o r a s in g le s t a g e o f c a ll f o r wa r d in g

FE9

- 25 -

Figure 3 shows the FEs and relationships for two stages of call diversion.

FE1

FE2

FE3

FE4

FE5

FE3

rg re

FE8

FE6 FE4

rf rd

FE9

FE7 FE5

re ri

FE8

FE6

FE9

FE7

F ig u r e 3 - F u n c t io n a l En t it y M o d e l f o r t wo s t a g e s o f c a ll d iv e r s io n 10.1.2 D e s c r ip t io n o f t h e f u n c t io n a l e n t it ie s 10.1.2.1 Calling user's service agent, FE1 This FE delivers the call diversion notifications to the calling user. 10.1.2.2

Calling user's service control entity, FE2 This FE provides the appropriate call diversion notifications to FE1 according to the information received from FE3 and FE6.

10.1.2.3

C a ll d iv e r s io n e x e c u t io n e n t it y , F E3 This FE executes call diversion by initiating a new call establishment, and requesting release of the leg to the original called user. FE3 also relays call diversion information to FE2 and FE6.

10.1.2.4

C a ll d iv e r s io n d e t e c t i o n a n d c o n t r o l e n t i t y , F E 4 a) Call Forwarding (CFU, CFB, CFNR) This FE detects a call diversion request and supervises this request. FE4 provides a notification to FE5 and provides call diversion information to FE3. FE 4 also receives activation, deactivation and interrogation requests from FE8 and provides responses to FE8. FE4 is responsible for modifying data related to activation, deactivation and remote activation enabling and disabling. b) Call Deflection This FE receives from FE5 a call diversion request and supervises this request. FE4 provides also a notification to FE5 and provides call diversion information to FE3.

10.1.2.5

Served user's service agent, FE5 This FE delivers call forwarding notifications to the served user. In addition, in case of CD, it detects a call diversion request by the served user and passes that request to FE4.

- 26 -

10.1.2.6

Diverted-to user's service control entity, FE6 This FE provides appropriate call diversion notifications to FE7 and provides also number presentation restriction information to FE2 via FE3.

10.1.2.7

D iv e r t e d - t o u s e r 's s e r v ic e a g e n t , F E7 This FE delivers call diversion notification to the diverted-to user.

10.1.2.8

U s e r 's 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 c o n t r o l, F E8 This FE relays activation, deactivation and interrogation requests and responses between FE9 and FE4. FE8 is empty in case of SS-CD.

10.1.2.9

U s e r 's 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 a g e n t , F E9 This FE provides activation, deactivation and interrogation requests to FE8 and delivers corresponding responses to the requesting user. FE9 is empty in case of SS-CD.

10.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 user A's CCA. • Functional entity FE2 shall be collocated with user A's CC or with any Incoming Gateway CC. • Functional entity FE3 shall be collocated with user A's CC or with any Incoming Gateway CC or any Transit CC in the case of call diversion by rerouteing. Functional entity FE3 shall be collocated with user B's CC (users B1 ... Bn in case of multiple call diversion) in the case of call diversion by forward switching. • Functional entity FE4 shall be collocated with user B's CC (users B1 ... Bn in case of multiple call diversion). • Functional entity FE5 shall be collocated with user B's CCA. • Functional entity FE6 shall be collocated with user C's CC, and also with the CCs for users B2 ... Bn in case of multiple call diversion. • Functional entity FE7 shall be collocated with user C's CCA. • Functional entity FE8 shall be collocated with either the user B's CC or any remote user's CC. • Functional entity FE9 shall be collocated with either the user B's CCA or any remote user's CCA. An example of the relationship with a basic service is shown in figure 4. This example is used as the basis for the information flow sequence diagrams in 10.2.2.

- 27 -

FE8

FE1 CCA

ra r1

FE2 CC

FE3 r2

FE7 CCA

rf r3

FE4 CC

FE6 CC

FE9

Activating, Deactivating and Interrogating User

Calling User A re

Called User C (Diverted-to User)

Figure 4 - Functional Entity Model Relationship

rd r3

FE5 CCA

Called User B (Diverting User)

- 28 -

10.2 10.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 below, the column headed "Request" indicates which of the service elements are mandatory (M) and which are optional (O) in an request/indication information flow. The column headed "Confirm" indicates which of the service elements are mandatory (M) and which are optional (O) in a response/confirmation information flow.

10.2.1.1

INFORM 1 This unconfirmed information flow indicates to FE2 that call diversion has been initiated and informs of calling user notification restrictions (subscription options of user B). It shall be sent over relationship rb and it shall contain the service elements listed in table 3. Ta b le 3 - C o n t e n t o f I N F O R M 1

Service elements

Allowed value

Request

Notificat. Subscription Option

No Yes,without number/name Yes, with number/name CFU/CDI,CFB,CFNR/CDA

Diverting Cause Diverted-to Number 10.2.1.2

Confirm

M M

INFORM 2 This unconfirmed information flow indicates to FE1 that call diversion has been initiated. It shall only be sent if required by the subscription options of user B. It shall be sent over relationship ra. There is no service element in this information flow.

- 29 -

10.2.1.3

INFORM 3 This unconfirmed information flow indicates to FE5 that call forwarding has been initiated. It shall only be sent if required by the subscription options of user B and it shall not be sent in case of a failure of the call forwarding invocation request. It shall be sent over relationship rd and it shall contain the service elements listed in table 4. Ta b le 4 - C o n t e n t o f I N F O R M 3

Service elements

Allowed value

Request

Diverting Cause

CFU,CFB,CFNR

Served User's MSN Number

O (Notes 3 & 6)

Original Diverting Cause

CFU/CDI,CFB,CFNR/CDA

O (Notes 3 & 7)

Last Diverting Cause

CFU/CDI,CFB,CFNR/CDA

O (Notes 3 & 7)

Connection Type

Originating Number including restriction indicator

O (Notes 1 & 3)

OriginatingSubaddress

O (Notes 3 & 8)

Calling Party Name including restriction indicator

O (Notes 2 & 3)

Last Diverting Number including restriction indicator

O (Notes 3, 5, 7)

Original Called Number including restriction indicator

O (Notes 3, 4, 7)

NOTES 1.

If CLIP applies, this service element shall be included as defined for the Identification supplementary services in ECMA-148.

This shall comprise the service elements of information flow INFORM 2 in ECMA-163.

This service element shall not be included in case of CFNR.

This service element is defined in ECMA-142.

This service element shall only be included if allowed by the previous served user(s).

This service element shall only be included if MSN applies for user B.

This service element shall only be included in case of multiple diversion.

If CLIP applies, this service element may be included as defined for the Identification supplementary services in ECMA-148.

- 30 -

10.2.1.4

INFORM 4 This unconfirmed information flow indicates to FE6 that call diversion is taking place. It shall be sent over relationship re and it shall contain the service elements listed in table 5. NOTE The Diverted-to Number (= Destination Number), Originating Number, Originating Subaddress, Connection Type and Call History are carried in the basic call to user C and are not shown in INFORM 4. The basic call service elements are defined in ECMA-142. Ta b le 5 - C o n t e n t o f I N F O R M 4

Service elements

Allowed value

Request

Last Diverting Cause Original Diverting Cause Diversion Counter Diverting Number, including restriction indicator Original Called Number including restriction indicator Calling Party Name Original Called Name including restriction indicator Diverting Party Name including restriction indicator

CFU/CDI,CFB,CFNR/CDA CFU/CDI,CFB,CFNR/CDA

M O M M O (Note 3) O (Note 1) O (Notes 2 & 3) O (Note 2)

NOTES 1.

This shall comprise service elements of information flow INFORM 1 in ECMA-163.

This service element may be omitted in case of name not available or in case of presentation restricted or if not implemented.

This service element shall only be included in case of multiple diversion.

- 31 -

10.2.1.5

INFORM 5 This unconfirmed information flow indicates to FE7 that call diversion is taking place. It shall be sent over relationship rf and it shall contain the service elements listed in table 6. NOTE The Diverted-to Number (= Destination Number), Connection Type and Call History are carried in the basic call to user C and are not shown in INFORM 5. The basic call service elements are defined in ECMA-142. Ta b le 6 - C o n t e n t o f I N F O R M 5

Service elements

Allowed value

Request

Original Diverting Cause

CFU/CDI,CFB,CFNR/CDA

O (Note 3)

Last Diverting Cause

CFU/CDI,CFB,CFNR/CDA

Diverting Number

O (Note 4)

Original Called Number

O (Notes 3 & 4)

Originating Number

O (Note 1)

Originating Subaddress

O (Note 1)

Calling Party Name

O (Note 2)

Original Called Name

O (Notes 3, 4, 5)

Diverting Party Name

O (Note 4 & 5)

NOTES 1.

This shall comprise service elements of information flow INFORM 2 in ECMA-148.

This service element shall be included as defined for the Name Identification supplementary services in ECMA-163.

This service element shall only be included in case of multiple diversion.

This service element shall only be included if no restriction exists.

This service element may be omitted in case of name not available or if not implemented.

10.2.1.6

INFORM 6 This unconfirmed information flow indicates whether presentation of user C's number and name is allowed. It shall be sent over relationship re between FE6 and FE3 and over relationship rb between FE3 and FE2 and it shall contain the service elements listed in table 7. Ta b le 7 - C o n t e n t o f I N F O R M 6

Service elements

Allowed value

Request

Presentation Indicator

present. allowed present. not allowed

M (Note 1)

Diverted-to Party Name including restriction indicator

Confirm

O (Note 2)

NOTES 1.

The Presentation Indicator shall apply only to the indication of user C's number.

This service element may be omitted in case of name not available or in case of presentation restricted or if not implemented.

- 32 -

10.2.1.7

INFORM 7 This unconfirmed information flow informs FE1 of the user C's number and name if appropriate. It shall only be sent if required by the subscription options of user B and if user C's number is not presentation restricted. It shall be sent over relationship ra and it shall contain the service elements listed in table 8. Ta b le 8 - C o n t e n t s o f I N F O R M 7

Service elements

Allowed value

Request

Diverted-to Number

PISNnumber number not available name name not available

Diverted-to Party Name

Confirm

O (Note)

NOTE This service element shall only be included if no restriction exists. It may be omitted in case of name not available or if not implemented.

10.2.1.8

INFORM 8 This unconfirmed information flow indicates to FE5 that CFU/CFB/CFNR has been activated. It shall be sent over relationship rd and it shall contain the service elements listed in table 9. Ta b le 9 - C o n t e n t s o f I N F O R M 8

Service elements Diverted-to Number BasicService Served User`s MSN Number Diversion procedure

Allowed value

all or a specific one CFU,CFB,CFNR

Request

Confirm

M M O (Note) M

NOTE This service element shall only be included if MSN applies for user B.

10.2.1.9

INFORM 9 This unconfirmed information flow indicates to FE5 that CFU/CFB/CFNR has been deactivated. It shall be sent over relationship rd and it shall contain the service elements listed in table 10. Ta b le 1 0 - C o n t e n t s o f I N F O R M 9

Service elements

Allowed value

Request

Basic Service Served user's MSN number Diversion procedure

all or a specific one

M O (Note) M

CFU,CFB,CFNR

Confirm

NOTE This service element shall only be included if MSN applies for user B. 10.2.1.10 INFORM 10 This unconfirmed information flow indicates to FE4 and FE5 that DIVA has not been completed. It shall be sent over relationship rc and rd and it shall contain the service element listed in table 11.

- 33 -

Ta b le 1 1 - C o n t e n t s o f I N F O R M 1 0 Service elements

Allowed value

Request

Call State Notification

Diversion leg cleared

Confirm

1 0 . 2 . 1 . 1 1 D I V ER T This confirmed information flow invokes call diversion operation. It shall be sent over relationship rc and it shall contain the service elements listed in table 12. Table 12 - Contents of DIVERT Service elements

Allowed value

Request

Diverting Cause Diverted-to Number including restriction indicator Diverted-to Subaddress Diversion Counter Connection Type Originating Number Originating Subaddress Calling Party Name Notific. Subscript. Option:

CFU/CDI,CFB,CFNR/CDA

M M

No Yes,with number/name Yes,without number/name

Confirm

O M M (Note 1) M (Note 1) O (Note 2) O (Note 5) M

Call History

O (Note 2)

Diverting Number including restriction indicator Original Called Number including restriction indicator Original Called Name including restriction indicator Diverting Party Name including restriction indicator Diverting Invocation Result

M O (Note 3) O (Notes 3 & 4) O (Note 4 accepted/rejected

NOTES 1.

This service element is obtained from the basic call SETUP request/indication information flow.

This service element shall be included if available in the basic call SETUP request/indication information flow.

This service element shall only be included in case of multiple diversion.

This service element may be omitted in case of name not available or in case of presentation restricted or if not implemented.

This shall comprise the service elements of information flow INFORM 1 in ECMA-148.

- 34 -

1 0 . 2 . 1 . 1 2 D EF LEC T This confirmed information flow indicates to FE4 that CD has been invoked. It shall be sent over relationship rd and it shall contain the service elements listed in table 13. Table 13 - Contents of DEFLECT Service elements

Allowed value

Diverted-to Number Diverted-to Subaddress CD invocation result

Request

Confirm

M O accepted/rejected

1 0 . 2 . 1 . 1 3 I N TER R O G A TE This confirmed information flow conveys call forwarding interrogation. It may be sent over relationship rg and relationship rh and it shall contain the service elements listed in table 14. Table 14 - Contents of INTERROGATE Service elements

Allowed value

Request

Diversion Procedure BasicService Served User's Number Interrogating User's Number Interrogating User's MSN Number Interrogation Request Result

CFU,CFB,CFNR all or a specific one

M M O (Note 1) O (Note 5) O (Note 2)

Basic Service Diverted-to Number for Basic Service Diverted-to Subaddress for Basic Service Remote Activation

activated not activated or rejected

Confirm

M O (Note 3) O (Note 3) O (Note 3)

enabled or disabled

O (Note 4)

NOTES 1.

This service element shall only be included in the case of remote interrogation.

This service element shall be included over relationship rh if MSN applies at the interrogating user. Otherwise this service element shall not be included.

This service element shall only be included if call diversion is activated. It may be repeated, if the INTERROGATE request/indication indicates " all basic services".

This service element may be repeated, if the INTERROGATE request/indication indicates "all basic services".

The service element shall be included over relationship rg and shall not be included over relationship rh.

- 35 -

1 0 . 2 . 1 . 1 4 A C TI V A TE This confirmed information flow activates call forwarding. It may be sent over relationship rg and relationship rh and it shall contain the service elements listed in table 15. Table 15 - Contents of ACTIVATE Service elements

Allowed value

Request

Diversion Procedure Diverted-to Number Diverted-to Subaddress Basic Service Served User's Number Activating User's Number Activating User's MSN Number Activation Request Result Cause for rejection

CFU,CFB,CFNR

M M O M O (Note 1) O (Note 4) O (Note 2)

all or a specific one

accepted/rejected * service not subscribed * insufficient information * no valid diverted-to number * basic service not subscribed

Confirm

M O (Note 3)

NOTES 1.

This service element shall only be included in the case of remote activation.

This service element shall be included over relationship rh if MSN applies at the activating user. Otherwise this service element shall not be included .

This service element shall only be included in case of rejection.

The service element shall be included over relationship rg and shall not be included over relationship rh.

- 36 -

1 0 . 2 . 1 . 1 5 D EA C TI V A TE This confirmed information flow deactivates call forwarding. It may be sent over relationship rg and relationship rh and it shall contain the service elements listed in table 16. Table 16 - Contents of DEACTIVATE Service elements

Allowed value

Request

Diversion Procedure Basic Service Served User's Number Deactivating User's Number Deactivating User's MSN Number Deactivation Request Result Cause for rejection

CFU,CFB,CFNR all or a specific one

M M O (Note 1) O (Note 4) O (Note 2)

accepted/rejected * service not subscribed * insufficient information * basic service not subscribed

Confirm

M O (Note 3)

NOTES 1.

This service element shall only be included in case of remote deactivation.

This service element shall be included over relationship rh if MSN applies at the deactivating user. Otherwise this service element shall not be included.

This service element shall only be included in case of rejection.

The service element shall be included over relationship rg and shall not be included over relationship rh.

10.2.1.16 ENABLE This confirmed information flow enables remote call forwarding activation. It may be sent over relationship rd and it shall contain the service elements listed in table 17. Table 17 - Contents of ENABLE Service elements

Allowed value

Request

Diversion Procedure Basic Service Served User's MSN Number Enable Request Result Cause for rejection

CFU,CFB,CFNR all or a specific one

M M O (Note 1)

accepted/rejected * service not subscribed * insufficient information * basic service not subscribed

NOTES 1.

This service element shall only be included if MSN applies for user B.

This service element shall only be included in case of rejection.

Confirm

M O (Note 2)

- 37 -

10.2.1.17 DISABLE This confirmed information flow disables remote call forwarding activation. It may be sent over relationship rd and it shall contain the service elements listed in table 18. Table 18 - Contents of DISABLE Service elements

Allowed value

Request

Diversion Procedure Basic Service Served User's MSN Number Disable Request Result Cause for rejection

CFU,CFB,CFNR all or a specific one

M M O (Note 1)

accepted/rejected * service not subscribed * insufficient information * basic service not subscribed

Confirm

M O (Note 2)

NOTES 1.

This service element shall only be included if MSN applies for user B.

This service element shall only be included in case of rejection.

1 0 . 2 . 1 . 1 8 C H EC K This confirmed information flow is used to check if the diverted-to number and basic service(s) exist. It may be sent over relationship ri and it shall contain the service elements listed in table 19. Ta b le 1 9 - C o n t e n t s o f C H EC K Service elements Diverted-to Number Basic Service Served User's Number Check Request Result Cause for rejection

Allowed value

Request

all or a specific one

M M M

accepted/rejected * insufficient information * no valid diverted-to number * basic service not subscribed

Confirm

M O (Note)

NOTE This service element shall only be included in case of rejection. 10.2.2

Ex a m p le s o f in f o r m a t io n f lo w s e q u e n c e s Signalling procedures shall be provided 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. In the figures, SS-DIV 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 together. Within a column representing an SS-DIV functional entity, the numbers refer to functional entity actions listed in 11.3. Basic call information flows are represented only as far as necessary for the understanding of the SSDIV procedures.

- 38 -

10.2.2.1

FE1

I n f o r m a t io n f lo w s e q u e n c e s f o r C F U /C F B o p e r a t io n The information flow sequence for successful CFU/CFB operation is shown in figure 5. ra

CCA

FE2

FE3

FE4

FE5

FE6

CCA

FE7 CCA

re SETUP req/ind

SETUP req/ind

(Note) SETUP_REJ DIVERT

301

req/ind

401

req/ind

(Note)

DIVERT resp/conf (accepted)

302

402 INFORM 3 req/ind

501

RELEASE req/ind INFORM 4 req/ind

601

req/ind

SETUP

INFORM 1 303

101

INFORM 2 201

req/ind

SETUP req/ind

req/ind

REPORT req/ind

REPORT REPORT REPORT

INFORM 6 304 INFORM 7 202

INFORM 6 req/ind

req/ind

603 SETUP

SETUP SETUP

SETUP

req/ind

102

INFORM 5

resp/conf

NOTE This information flow is only applicable in case of CFB-UDUB. F ig u r e 5 - I n f o r m a t io n F lo w S e q u e n c e f o r s u c c e s s f u l C F U / C F B o p e r a t i o n

701

- 39 -

The information flow sequences for unsuccessful CFU/CFB operation are shown in figures 6 and 7.

FE1

CCA

FE2

FE3

FE4

FE5

FE6

CCA

re SETUP req/ind

SETUP SETUP

req/ind

SETUP

req/ind

(Note) SETUP_REJ DIVERT

301

req/ind

401

req/ind

(Note)

DIVERT resp/conf (accepted)

302

402 INFORM 3 req/ind

501

RELEASE req/ind INFORM 4 req/ind SETUP

INFORM 1 303

101

INFORM 2 201

req/ind

req/ind RELEASE RELEASE DISCONN.

req/ind

NOTE This information flow is only applicable in case of CFB-UDUB. Figure 6 - Information Flow Sequence for unsuccessful CFU/CFB operation: Failure of diverted call

FE7 CCA

- 40 -

FE1

CCA

FE2

FE3

FE4 CC

FE5 CCA

SETUP req/ind

SETUP

SETUP req/ind

req/ind

SETUP req/ind

(Note) SETUP_REJ DIVERT

301

401

req/ind

(Note)

DIVERT resp/conf (rejected)

403

NOTE This information flow is only applicable in case of CFB-UDUB. Figure 7 - Information Flow Sequences for unsuccessful CFU/CFB operation: Rejection of Call Diversion

- 41 -

10.2.2.2

FE1

I n f o r m a t io n f lo w s e q u e n c e s f o r C F N R o p e r a t io n The information flow sequence for successful CFNR operation is shown in figure 8. ra

CCA

FE2

FE3

FE4

FE5

FE6

CCA

FE7 CCA

re SETUP SETUP req/ind

req/ind

SETUP req/ind

REPORT req/ind

REPORT

REPORT req/ind

REPORT

req/ind

DIVERT

req/ind

401

301 DIVERT resp/conf (accepted)

302

402 INFORM 3 req/ind

501

INFORM 4 req/ind

601

INFORM 5 req/ind

SETUP

req/ind

req/ind REPORT

REPORT req/ind

INFORM 1 303

101

INFORM 2 201

req/ind

RELEASE req/ind

DISCONN req/ind

INFORM 6 304 INFORM 7

102

202

INFORM 6 req/ind

req/ind SETUP

req/ind

SETUP SETUP SETUP

603

resp/conf

F ig u r e 8 - I n f o r m a t io n F lo w S e q u en c e f o r s u c c e s s f u l C F N R o p e r a t i o n

701

- 42 -

The information flow sequence for clearing by user A during CFNR operation is shown in figure 9.

FE1

CCA

FE2

FE3

FE4

FE5

FE6

CCA

FE7 CCA

re SETUP req/ind

SETUP req/ind

REPORT req/ind

REPORT

req/ind

DIVERT

req/ind

401

301 DIVERT resp/conf (accepted)

302

402 INFORM 3 req/ind

501

INFORM 4 req/ind

601

INFORM 5 req/ind

701

SETUP

req/ind

req/ind DISCONN req/ind

RELEASE req/ind

307 RELEASE req/ind

DISCONN req/ind

RELEASE req/ind

DISCONN req/ind

Figure 9 - Information Flow Sequence for clearing by user A during CFNR operation

- 43 -

The information flow sequences for unsuccessful CFNR operation are shown in figures 10 and 11.

FE1

CCA

FE2

FE3

FE4

FE5

FE6

CCA

SETUP req/ind

REPORT req/ind

SETUP req/ind

SETUP req/ind REPORT req/ind

REPORT req/ind

DIVERT req/ind

401

301 DIVERT

302

resp/conf 402 INFORM 3 (accepted) req/ind

501

INFORM 4 req/ind SETUP req/ind

RELEASE req/ind

306 INFORM 10 req/ind

410 INFORM 10 req/ind

507

F ig u r e 1 0 - I n f o r m a t io n F lo w S e q u e n c e s f o r u n s u c c e s s f u l C F N R o p e r a t i o n : CFNR not completed, original call remains

FE7 CCA

- 44 -

FE1

CCA

FE2

FE3

FE4

FE5 CCA

SETUP req/ind

SETUP

req/ind

req/ind REPORT

REPORT REPORT REPORT req/ind

req/ind

req/ind DIVERT

301

401

req/ind DIVERT resp/conf (rejected)

403

F ig u r e 1 1 - I n f o r m a t io n F lo w S e q u e n c e s f o r u n s u c c e s s f u l C F N R o p e r a t i o n : CFNR rejected, original call remains

- 45 -

The information flow sequence if user B answers before receipt of REPORT (alerting) from user C is shown in figure 12.

FE1

FE2

CCA

FE3

FE4

FE5

FE6

CCA

FE7 CCA

SETUP

SETUP req/ind

req/ind

REPORT req/ind

SETUP req/ind

SETUP req/ind REPORT req/ind

REPORT req/ind

DIVERT req/ind

401

301 DIVERT

302

resp/conf 402 INFORM 3 (accepted) req/ind

INFORM 4 req/ind

501 601

SETUP req/ind

INFORM 5 req/ind SETUP req/ind

SETUP

resp/conf

305

RELEASE req/ind

DISCONN req/ind

F ig u r e 1 2 - I n f o r m a t io n F lo w S e q u e n c e f o r C F N R o p e r a t i o n : User B answers before alerting of user C

701

- 46 -

10.2.2.3

FE1

I n f o r m a t io n f lo w s e q u e n c e s f o r C D o p e r a t io n The information flow sequences for successful CD operation is shown in figures 13 and 14.

CCA

FE2

FE3

FE4

FE5

FE6

CCA

FE7 CCA

re SETUP SETUP

req/ind

SETUP

req/ind

SETUP

req/ind

req/ind REPORT REPORT REPORT REPORT

req/ind

DEFLECT

req/ind DIVERT req/ind

req/ind

401

req/ind

505

301 DIVERT resp/conf (accepted)

302

INFORM 4 req/ind

402 DEFLECT resp/conf (accepted)

506 601

INFORM 5 req/ind

701

SETUP req/ind

SETUP req/ind REPORT REPORT

INFORM 1 303

101

INFORM 2 201

req/ind

RELEASE req/ind

req/ind

DISCONN req/ind INFORM 6

INFORM 6 304 INFORM 7

202

req/ind

req/ind SETUP

102

SETUP SETUP

603

resp/conf

F ig u r e 1 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 s u c c e s s f u l C a l l D e f l e c t i o n F r o m A l e r t

- 47 -

FE1

CCA

FE2

FE3

FE4

FE5

FE6

CCA

FE7 CCA

SETUP req/ind

401 DIVERT 301

SETUP req/ind

DEFLECT 505 req/ind

req/ind DIVERT

302

resp/conf 402 DEFLECT (accepted) resp/conf (accepted) RELEASE DISCONN req/ind req/ind

506

INFORM 4 req/ind

601

req/ind

SETUP INFORM 1 303

101

INFORM 2 201

req/ind

REPORT req/ind

REPORT

102

req/ind

INFORM 6 304

INFORM 7 202

req/ind

INFORM 6 req/ind

603 SETUP

SETUP

701

SETUP

req/ind

REPORT

INFORM 5

resp/conf

F i g u r e 1 4 - I n f o r m a t i o n F l o w S e q u e n c e f or s u c c e s s f u l C a l l D e f l e c t i o n I m m e d i a t e

- 48 -

The information flow sequence for clearing by user A during CDA is shown in figure 15.

FE1

CCA

FE2

FE3

FE4

FE5

FE6

CCA

FE7 CCA

re SETUP req/ind

REPORT req/ind

SETUP req/ind

REPORT req/ind

DIVERT req/ind

401

DEFLECT 505 req/ind

301 DIVERT resp/conf (accepted)

302

402

DEFLECT resp/conf (accepted)

INFORM 4 req/ind

506

601

SETUP req/ind

INFORM 5 req/ind

701

SETUP req/ind

DISCONN req/ind

RELEASE req/ind

307 RELEASE req/ind

DISCONN req/ind

RELEASE req/ind

DISCONN req/ind

F i g u r e 1 5 - I n f o r m a t i o n F l o w S e q u e n c e f o r c l e a r in g b y u s e r A d u r i n g C a l l D e f l e c t i o n F r o m A l e r t

- 49 -

The information flow sequences for unsuccessful CD operation are shown in figures 16, 17 and 18.

FE1

CCA

FE2

FE3

FE4

FE5

FE6

CCA

FE7 CCA

re SETUP req/ind

SETUP req/ind

REPORT REPORT

REPORT

req/ind

REPORT req/ind

req/ind

DIVERT req/ind

req/ind

DEFLECT 505

401

req/ind

402

DEFLECT

301 DIVERT resp/conf (accepted)

302

resp/conf (accepted)

506

INFORM 4 req/ind

SETUP req/ind RELEASE req/ind

306 INFORM 10 req/ind

410 INFORM 10 req/ind

507

Figure 16 - Information Flow Sequence for unsuccessful Call Deflection from Alert: CD not completed, original call remains

- 50 -

FE1

FE2

CCA

FE3

FE4

FE5

FE6

CCA

FE7 CCA

SETUP req/ind

SETUP

req/ind

SETUP req/ind REPORT

REPORT

REPORT req/ind

req/ind

(Note)

req/ind

(Note)

401 DIVERT

(Note) 301

req/ind

(Note) DEFLECT 505 req/ind

req/ind DIVERT

302

resp/conf 402 DEFLECT (accepted) resp/conf (accepted) RELEASE DISCONN req/ind

506

req/ind INFORM 4 req/ind SETUP INFORM 1 303

101

INFORM 2 201

req/ind

req/ind RELEASE

RELEASE

DISCONN.

req/ind

F i g u r e 1 7 - I n f o r m a t i o n F l o w S e q u e n c e f or u n s u c c e s s f u l C a l l D e f l e c t i o n I m m e d i a t e : CD not completed, original call cleared

- 51 -

FE1

CCA

FE2

FE3

FE4 CC

FE5 CCA

SETUP req/ind

SETUP req/ind REPORT

REPORT

req/ind

REPORT

req/ind

REPORT

req/ind

(Note)

req/ind

(Note)

a) Rejection by FE4 DEFLECT 505

401

req/ind

DEFLECT resp/conf (rejected)

506

DEFLECT

505

b) Rejection by FE3

DIVERT 401

req/ind

301 DIVERT resp/conf (rejected)

403 DEFLECT resp/conf (rejected)

506

NOTE This information flow is sent only in case of SS-CD From Alerting. F ig u r e 1 8 - I n f o r m a t io n F lo w S e q u e n c e f o r u n s u c c e s s f u l C a l l D e f l e c t i o n o p e r a t i o n : CD request rejected, original call remains

- 52 -

The information flow sequence if user B answers before receipt of REPORT (alerting) from user C is shown in figure 19.

FE1

CCA

FE2

FE3

FE4

FE5

FE6

CCA

FE7 CCA

re SETUP req/ind

REPORT req/ind

SETUP req/ind

REPORT req/ind

DEFLECT 505

DIVERT req/ind

401

req/ind

301 DIVERT

302

resp/conf 402 DEFLECT (accepted) resp/conf (accepted) INFORM 4 req/ind

506

601

SETUP req/ind

INFORM 5 req/ind SETUP req/ind

SETUP SETUP

resp/conf

305

RELEASE req/ind

DISCONN req/ind

F ig u r e 1 9 - I n f o r m a t io n F lo w S e q u e n c e f o r C a l l D e f l e c t i o n f r o m A l e r t i n g : User B answers before alerting of user C

701

- 53 -

10.2.2.4

I n f o r m a t io n f lo w s e q u e n c e s f o r S S - C F a c t iv a t io n The information flow sequences for activation of SS-CF are shown in figures 20 and 21.

FE6 CC

FE4 CC

FE5

FE8

CCA

FE9 CCA

rg ACTIVATE ACTIVATE CHECK

req/ind

801

901

req/ind

404

req/ind

602

CHECK resp/conf

405 ACTIVATE resp/conf (accepted)

802 ACTIVATE resp/conf 902 (accepted)

INFORM 8 req/ind

502

F i g u r e 2 0 - I n f o r m a t i o n F l o w S e q u e n c e f o r a c t i v a t i o n wit h C H E C K i n f o r m a t i o n f l o w

FE4

FE5

FE8

CCA

FE9 CCA

rg ACTIVATE ACTIVATE

801

req/ind

901

req/ind

406 ACTIVATE

802 ACTIVATE

resp/conf (accepted)

INFORM 8 req/ind

902

502

F i g u r e 2 1 - I n f o r m a t i o n F l o w S e q u e n c e f o r a ct i v a t i o n wit h o u t C H E C K i n f o r m a t i o n f l o w

- 54 -

10.2.2.5

I n f o r m a t io n f lo w s e q u e n c e f o r S S - C F d e a c t iv a t io n The information flow sequences for deactivation of SS-CF is shown in figure 22.

FE4

FE5

FE8

CCA

FE9 CCA

rg DEACTIVATE DEACTIVATE

803

req/ind

901

req/ind

407 DEACTIVATE

804 DEACTIVATE

resp/conf (accepted)

INFORM 9 req/ind

902

502

F ig u r e 2 2 - I n f o r m a t io n F lo w S e q u e n c e f o r d e a c t iv a t io n 10.2.2.6

Information flow sequence for enabling/disabling of remote SS-CF activation The information flow sequences for enabling/disabling of remote SS-CF activation is shown in figure 23.

FE4

FE5 CCA

ENABLE/ DISABLE

503

req/ind

408 ENABLE/ DISABLE resp/conf

504

Figure 23 - Information Flow Sequence for enabling/disabling of remote activation

- 55 -

10.2.2.7

I n f o r m a t io n f lo w s e q u e n c e f o r S S - C F in t e r r o g a t io n The information flow sequences for interrogation of SS-CF is shown in figure 24.

FE4

FE8

CCA

INTERROGATE INTERROGATE

805

FE9

req/ind

901

req/ind

409 INTERROGATE resp/conf (accepted)

806 INTERROGATE resp/conf (accepted)

902

F ig u r e 2 4 - I n f o r m a t io n F lo w S e q u e n c e s f o r in t e r r o g a t io n

10.3

Functional entity actions The following FE actions shall occur at the points indicated in the figures of 11.2.2:

10.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 diversion notifications to the user as received from FE2 in INFORM 2 request/indication. 102

10.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 (multiple) INFORM 1 request/indication from FE3 and send each time a call diversion notification (without number information) in INFORM 2 request/indication to FE1 if allowed. Store the notification subscription options and the diverted-to number. 202

10.3.3

Deliver number and name notifications to the user as received in INFORM 7 request/indication from FE2.

Receive INFORM 6 request/indication from FE3, get the stored notification subscription options, determine if presentation of information is allowed and send the appropriate number and name information in INFORM 7 request/indication to FE1 if allowed.

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 Receive DIVERT request/indication, check whether the request is allowed and valid and respond to FE4 with DIVERT response/confirmation accordingly. 302

Stimulate the basic call establishment to FE6 if the diversion request is valid. Stimulate the release procedure at leg rc (original call) in case of CFU/CDI, CFB. Send INFORM 4 request/indication to FE6.

303

Send INFORM 1 request/indication to FE2. In case of CFNR/CDA, stimulate the release procedure at leg rc on receipt of REPORT request/indication or SETUP response/confirmation from user C.

304

Relay the presentation indicator and the name received in INFORM 6 request/indication from FE6 to FE2.

305

In case of CFNR/CDA, stimulate the release procedure at the diverted-to leg (re), when user B answers before alerting of user C.

- 56 -

10.3.4

306

Send INFORM 10 request/indication to FE4 when CFNR/CDA is not completed.

307

For CFNR/CDA, stimulate release of the legs rc and re if the calling user releases the call.

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 Immediate in the case of CFU, on detection of busy in the case of CFB, after a specified time interval in case of CFNR or after CD invocation by user B: • Recognize call diversion activated and invoked from Basic Service. • Increment the diversion counter. • If the incremented diversion counter has exceeded the upper limit or if FE4 cannot accept a CD request, reject the diversion request and do the following: – for CFU/CFB either release the call or override call diversion (implementation options), – for CFNR maintain the original call, – for CD maintain the original call and send a DEFLECT response/ confirmation (rejected) to FE5. • If the incremented diversion counter is not above the upper limit and, in cases of CD, if FE4 accepts the CD request, then send a DIVERT request/ indication to FE3. 402

Receive the positive DIVERT response/confirmation from FE3 and send – INFORM 3 request/indication to FE5 in case of CFU, CFB and CFNR, – DEFLECT response/confirm (accepted) in case of CD. For Diversions from Alert new diversion requests shall not be accepted unless an INFORM 10 request/ indication is received.

403

Receive the negative DIVERT response/confirmation from FE3. For CFU/CFB: stimulate release of the call to the calling user or perform an implementation specific procedure, e.g. send DIVERT request/indication to an FE3 at a different location. For CFNR: maintain the original call to the served user or perform an implementation specific procedure, e.g. send DIVERT request/indication to an FE3 at a different location. In case of CD send a DEFLECT response/confirmation (rejected) to FE5 and maintain the original call to the served user.

10.3.5

404

Validate received ACTIVATE request/indication and send a CHECK request/indication to FE6 in order to check if the diverted-to number and basic service(s) exist.

405

On receipt of a CHECK response/confirmation, further validate received ACTIVATE request/indication and respond to FE8 with ACTIVATE response/confirmation. Inform FE5 of a successful activation (INFORM 8 request/indication).

406

Validate received ACTIVATE request/indication and respond to FE8 with ACTIVATE response/ confirmation. Inform FE5 of a successful activation (INFORM 8 request/indication).

407

Validate received DEACTIVATE request/indication and respond to FE8 with DEACTIVATE response/ confirmation. Inform FE5 of a successful deactivation (INFORM 9 request/indication).

408

Validate received ENABLE/DISABLE request/indication ENABLE/DISABLE response/confirmation.

409

Validate received INTERROGATE request/indication and respond to FE8 with INTERROGATE response/ confirmation.

410

Relay optionally INFORM 10 request/indication from FE3 to FE5 if received, if an INFORM 3 request/ indication or a DEFLECT response/confirmation has previously been sent. New diversions shall now be allowed.

and

respond

FE5

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 Deliver notifications to the user as received from FE4 in INFORM 3 request/indication.

with

- 57 -

10.3.6

502

Deliver notifications on activation and deactivation to the user as received from FE4.

503

Send enable/disable requests to FE4 as received from the user.

504

Deliver enable/disable responses to the user as received from FE4.

505

Send CD request to FE4 as received from the user B in DEFLECT request/indication.

506

Deliver notifications to user B as received from FE4 in DEFLECT response/confirmation.

507

Inform the user that CFNR/CDA has failed.

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 Determine if presentation of the number and the name information received from FE3 in INFORM 4 request/indication is allowed and send INFORM 5 request/indication to FE7. Store the last diversion number and original called number and associated presentation restriction indicators for further multiple call diversions. 602

Receive CHECK request/indication from FE4, check optionally if the diverted-to number and basic service(s) exist, and respond to FE4 with CHECK response/confirmation.

603

Send the presentation indicator of the diverted-to user's number and the name of the diverted-to user either on receipt of REPORT request/indication (alerting) if possible or at latest on answer of the basic call to FE3 in INFORM 6 request/indication.

10.3.7

F u n c t io n a l e n t it y a c t io n s o f F E7 701 Deliver notifications to the diverted-to user as received from FE6.

10.3.8

F u n c t io n a l e n t it y a c t io n s o f F E8 801 Receive ACTIVATE request/indication from FE9. Perform address checking and either relay the ACTIVATE request/indication to FE4 or send a negative ACTIVATE response/confirmation to FE9.

10.3.9

802

Receive ACTIVATE response/confirmation from FE4 and relay it to FE9.

803

Receive DEACTIVATE request/indication from FE9. Perform address checking and either relay the DEACTIVATE req/ind to FE4 or send a negative DEACTIVATE response/confirmation to FE9.

804

Receive DEACTIVATE response/confirmation from FE4 and relay it to FE9.

805

Receive INTERROGATE request/indication from FE9. Perform address checking and either relay the INTERROGATE request/indication to FE4 or send a negative INTERROGATE response/confirmation to FE9.

806

Receive INTERROGATE response/confirmation from FE4 and relay it to FE9.

F u n c t io n a l e n t it y a c t io n s o f F E9 901 Send activation/deactivation/interrogation requests to FE8 as received from the user. 902

10.4

Deliver activation/deactivation/interrogation responses to the user as received from FE8.

Functional entity behaviour The figures in this clause 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.

10.4.1

Be h a v io u r o f F E1 Figure 25 contains the SDL diagram for the functional entity FE1. • Input signals from the right represent information flows from FE2. • Output signals to the left represent primitives to the user.

- 58 -

Idle

INFORM 7 req/ind (from FE2)

number/name (to user)

INFORM 2 req/ind (from FE2)

notification (to user)

Idle

F ig u r e 2 5 - S D L f o r F u n c t io n a l En t it y F E1 10.4.2

Be h a v io u r o f F E2 Figure 26 contains the SDL diagram for the functional entity FE2. • Input signals from the left represent primitives from local CC. • Input signals from the right represent information flows from FE3. • Output signals to the left represent information flows to FE1.

- 59 -

Idle

INFORM 1

req/ind (from FE3) save NSO and diverted-to number

NSO = notify ?

INFORM 2

req/ind (to FE1)

Diverting

INFORM 1

req/ind (from FE3)

save more restrictive NSO and new DTN

INFORM 6

basic call answered

req/ind (from FE3)

NSO = allowed ?

basic call released

Y Y

NSO = notify ?

cause = CFNR or CD From Alerting ?

presentation of number/ name

Y INFORM 7

INFORM 2 req/ind (to FE1)

req/ind (to FE1)

Diverting

F ig u r e 2 6 - S D L f o r F u n c t io n a l En t it y F E2

Idle

- 60 -

10.4.3

Be h a v io u r o f F E3 Figure 27 contains the SDL diagram for the functional entity FE3. • Input signals from the left represent primitives from local CC. • Input signals from the right represent information flows from other functional entities. • Output signals to the right and to the left represent information flows to other function al entities. The relationship to the basic call process is also indicated in task symbols or in the annotations.

- 61 -

Idle

DIVERT

INFORM 6

req/ind (from FE4)

req/ind (from FE6)

INFORM 6

DIV request valid ?

req/ind (to FE2)

Y DIVERT

DIVERT

resp/conf (to FE4) rejected

resp/conf (to FE4) accepted

Idle

INFORM 4

at the same time

req/ind (to FE6)

as SETUP req/ind

stimulate call establishment to new destination

Idle

CFNR or CDA ?

CFU, CFB, CDI

INFORM 1 req/ind (to FE2)

stimulate release to served user

Idle

basic call to new destination released

INFORM 10 req/ind (to FE4)

Diverting

new destination alerting or answered

basic call released by user A or B

served user

stimulate release of both remaining legs

stimulate release of leg to new destination

answered

INFORM 1 req/ind (to FE2)

continue alerting

stimulate release

of served user

to served user

Idle

F ig u r e 2 7 - S D L f o r F u n c t io n a l En t it y F E3

- 62 -

10.4.4

Be h a v io u r o f F E4 Figures 28, 29 and 30 contain the SDL diagram for the functional entity FE4. • Input signals from the left represent information flows from other functional entities or primitives from local CC. • Input signals from the right represent information flows from other functional entities or internal stimuli. • Output signals to the right and to the left represent information flows to other functional entities. The relationship to the basic call process is also indicated in task symbols or in the annotations. NOTE The interaction between multiple invocations of CFNR and/or CDA is not taken into account.

- 63 -

Idle

DEFLECT

DIV detected during incoming basic call : for CFB after NDUP or UDUP for CFU immediately for CFNR after timer expiry

DIV request detected

req/ind (from FE5)

increment diversion counter

DIV request valid ?

CFNR ?

CD ?

DEFLECT

resp/conf (to FE5) (rejected)

DIVERT

req/ind (to FE3)

maintain original call

override call diversion

stimulate release of basic call

maintain original call

Idle

Wait_1

F ig u r e 2 8 - S D L f o r F u n c t io n a l En t it y F E4 ( p a r t 1 )

- 64 -

Wait_1

DIVERT

resp/conf (from FE3)

DIV invocation positiv ?

basic call

served user

released

answers

Idle

CD ?

Y notify served user ?

Y DEFLECT

CDA ? Y

Wait_3

basic call released

DEFLECT

INFORM 3

resp/conf (to FE5) (accepted)

resp/conf (to FE5) (rejected)

req/ind (to FE5)

CFNR ?

implementation specific procedure

stimulate release of basic call

maintain original call for CFNR or CDA

INFORM 10 req/ind (from FE3)

INFORM 10 req/ind (to FE5)

Idle

F ig u r e 2 9 - S D L f o r F u n c t io n a l En t it y F E4 ( p a r t 2 )

- 65 -

ACTIVATE

DEACTIVATE

req/ind (from FE8)

Deactivate

req/ind (from FE8)

CHECK

indication (internal)

validate and

req/ind (to FE6)

modify data

Deaktivate request valid ?

Wait_2

Y DEACTIVATE

CHECK

resp/conf) (from FE6f)

resp/conf (to FE8)

INFORM 9 req/ind (to FE5)

INFORM 9

validate and

req/ind (to FE5)

modify data

Activate request valid ?

DEACTIVATE

Idle

ENABLE

req/ind (from FE5)

ACTIVATE resp/conf (to FE8)

INFORM 8 req/ind (to FE5)

Idle

ACTIVATE resp/conf (to FE8)

DISABLE

req/ind (from FE5)

INTERROG. req/ind (from FE8)

validate and

get

modify data

information

ENABLE

DISABLE

INTERROG.

resp/conf (to FE5)

Idle

F ig u r e 3 0 - S D L f o r F u n c t io n a l En t it y F E4 ( p a r t 3 )

resp/conf (to FE8)

- 66 -

10.4.5

Be h a v io u r o f F E5 Figure 31 contains the SDL diagram for the functional entity FE5. • Input signals from the left represent information flows from FE4. • Input signals from the right represent primitives from the user. • Output signals to the left represent information flows to FE4. • Output signals to the right represent primitives to the user.

Idle

Enable

request (from user)

Disable

request (from user)

Deflect

request (from user)

ENABLE

DISABLE

DEFLECT

Wait_1

Wait_2

Wait_3

ENABLE

DISABLE

DEFLECT

req/ind (to FE4)

resp/conf (from FE4)

Enable

indication (to user)

req/ind (to FE4)

resp/conf (from FE4)

Disable

indication (to user)

INFORM 3,8 req/ind (from FE4)

INFORM 9,10 req/ind (from FE4)

req/ind (to FE4)

resp/conf (from FE4)

Deflect

indication (to user)

Notification

(to user)

Idle

F ig u r e 3 1 - S D L f o r F u n c t io n a l En t it y F E5

- 67 -

10.4.6

Be h a v io u r o f F E6 Figure 32 contains the SDL diagram for the functional entity FE6. • Input signals from the left represent information flows from FE3 or FE4. • Input signals from the right represent primitives from local CC. • Output signals to the right and to the left represent information flows to other functional entities. The relationship to the basic call process is also indicated in task symbols or in the annotations.

- 68 -

Idle

INFORM 4

CHECK

req/ind (from FE3)

INFORM 5 req/ind (to FE7)

req/ind (from FE4)

check diverted-to number and basic service

at the same time as SETUP req/ind

CHECK

resp/conf (to FE4)

Wait

Idle

new destination

basic call

alerting

answered

cleared

CLIR or CNIR subscribed ?

INFORM 6 req/ind already sent ?

N CLIR or CNIR temporary mode ?

Y get presentation indicators for diverted-to number and name

get presentation indicators for diverted-to number and name

INFORM 6

req/ind (to FE3)

Idle

req/ind (to FE3)

Wait

Idle

F ig u r e 3 2 - S D L f o r F u n c t io n a l En t it y F E6

- 69 -

10.4.7

Be h a v io u r o f F E7 Figure 33 contains the SDL diagram for the functional entity FE7. • Input signals from the left represent information flows from FE6. • Output signals to the right represent primitives to the user.

Idle

INFORM 5

req/ind (from FE6)

Notification (to user)

Idle

F ig u r e 3 3 - S D L f o r F u n c t io n a l En t it y F E7

- 70 -

10.4.8

Be h a v io u r o f F E8 Figure 34 contains the SDL diagram for the functional entity FE8. • Input signals from the left represent information flows from FE4. • Input signals from the right represent information flows from FE9. • Output signals to the right represent information flows to FE9. • Output signals to the left represent information flows to FE4.

Idle

ACTIVATE

DEACTIVATE

req/ind (from FE9)

request valid ?

DEACTIVATE

resp/conf (from FE4)

request valid ?

INTERROG. resp/conf (from FE4)

Y DEACTIVATE

INTERROG.

resp/conf (to FE9)

request valid ?

Y ACTIVATE

req/ind (to FE4)

req/ind (from FE9)

ACTIVATE

INTERROG.

DEACTIVATE req/ind (to FE4)

resp/conf (to FE9)

INTERROG. req/ind (to FE4)

Idle

F ig u r e 3 4 - S D L f o r F u n c t io n a l En t it y F E8

- 71 -

10.4.9

Be h a v io u r o f F E9 Figure 35 contains the SDL diagram for the functional entity FE8. • Input signals from the left represent information flows from FE8. • Input signals from the right represent primitives from the user. • Output signals to the left represent information flows to FE8. • Output signals to the right represent primitives to the user.

Idle

Activate request (from user)

Deactivate

Interrogate

request (from user)

ACTIVATE

DEACTIVATE

Wait_1

Wait_2

Wait_3

ACTIVATE

DEACTIVATE

INTERROG.

req/ind (to FE8)

resp/conf (from FE8)

Activate indication (to user)

req/ind (to FE8)

resp/conf (from FE8)

Deactivate indication (to user)

INTERROG. req/ind (to FE8)

resp/conf (from FE8)

Interrogate indication (to user)

Idle

F ig u r e 3 5 - S D L f o r F u n c t io n a l En t it y F E9

- 72 -

10.5

Allocation of functional entities to physical equipment The allocation of FEs to physical locations as shown in tables 20, 21 and 22 shall apply. In these tables, "TE" indicates a TE attached to a PISN. Where a terminal involved is stimulus with respect to call diversion, any FE shown as residing in the corresponding user's TE, shall reside instead in that user's PINX. T a b l e 2 0 - A l l o c a t i o n f o r c a l l d i v e r s i o n o pe r a t i o n b y " f o r w a r d s w i t c h i n g " a n d "partial rerouteing" User A FE1

User A FE2

User B FE4

User B FE5

User C FE6

User C FE7

Scenario 1

PINX

User B PINX

PINX

Scenario 2

other network

Scenario 3

other network

User B PINX

PINX

other network

Scenario 4

other network

PINX

Scenario 5

other network

PINX

Scenario 6

PINX

User B PINX

PINX

other network

Scenario 7

other network

User B PINX

PINX

Scenario 8

other network

Scenario 9

other network

PINX

Scenario 10

other network

Scenario 11

other network

PINX

Scenario 12

other network

PINX

other network

Scenario 13

other network

PINX

other network

Scenario 14

other network

PINX

Scenario 15

other network

PINX

FE3

- 73 -

Table 21 - Allocation for call diversion operation by "rerouteing" User A FE1

User A FE2

User B FE4

User B FE5

User C FE6

User C FE7

Scenario 16

PINX

Originat. PINX

PINX

Scenario 17

PINX

Originat. PINX

PINX

other network

Scenario 18

other network

Gateway PINX

PINX

Scenario 19

other network

Gateway PINX

PINX

other network

FE3

Ta b le 2 2 - A llo c a t io n f o r c a ll f o r wa r d in g 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 Served User B

10.6

De/activating User Interrogating User FE8 FE9

FE4

FE5

Scenario 20

PINX

User B PINX

Scenario 21

PINX

any PINX

Scenario 22

other network

Interworking considerations In cases where FE2, FE3 or FE6 is in another network, information pertaining to relationship rb, rc or re shall be passed as appropriate to the other network by the Gateway PINX, except any restricted number or name information. In cases where FE4 is in another network, information pertaining to relationship rh shall be passed to the other network by the Gateway PINX, if the other network supports the equivalent information flow. In cases where information is received from a FE located in another network by a Gateway PINX, the information required for SS-CFU, SS-CFB, SS-CFNR and SS-CD shall be used by that PINX.

- 74 -

- 75 -

Annex A ( in f o r ma tiv e )

Bibliography

ITU-T Rec. I.252.2

Integrated Services Digital Network (ISDN), Call Forwarding Busy (CFB) supplementary service, service description (1992)

ITU-T Rec. I.252.3

Integrated Services Digital Network (ISDN), Call Forwarding No Reply (CFNR) supplementary service, service description (1992)

ITU-T Rec. I.252.4

Integrated Services Digital Network (ISDN), Call Forwarding Unconditional (CFU) supplementary service, service description (1992)

ITU-T Rec. I.252.5

Integrated Services Digital Network (ISDN), Call Deflection (CD) supplementary service, service description (1992)

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

+41 22 849.60.01 [email protected]

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

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

ECMA-173 — Private Integrated Services Network (PISN) - Specification, functional model and information flows - Call diversion supplementary services (CFSD) (December 2001)

Related documents