Conceptio › Archive › ECMA International

ECMA Internationalopen access

ECMA-299 — Private Integrated Services Network (PISN) - Specification, functional model and information flows - Single step call transfer supplementary service (SSCT-SD) (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-299, ecma 299, 299, private, integrated, services, network, pisn, functional, model, and, information, flows, single, step, call, transfer, supplementary, service, ssct-sd

S tandard ECMA-299

2nd Edition - December 2001

Standardizing Information

and

Communication

Systems

Private Integrated Services Network (PISN) Specification, Functional Model and Information Flows Single Step Call Transfer Supplementary Service

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

S tandard ECMA-299

2nd Edition - December 2001

Standardizing

Information

and

Communication

Systems

Private Integrated Services Network (PISN) Specification, Functional Model and Information Flows Single Step Call Transfer Supplementary Service (SSCT-SD)

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

Ecma-299.doc

14-01-02 10,35

Brief History

This Standard is one of a series of ECMA Standards defining services and signalling procedures applicable to Private Integrated Services Networks (PISNs). The series uses the 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 Standard specifies the Single Step Call Transfer (SSCT) supplementary service. This Standard is based upon the practical experience of ECMA member companies and the results of their active and continuous participation in the work of ISO/IEC JTC1, ITU-T, ETSI and other international and national standardization bodies. It represents a pragmatic and widely based consensus. There is currently no equivalent service specified by ITU-T or ETSI for public ISDN. This ECMA Standard is technically aligned with International Standard ISO/IEC 19459 published by ISO/IEC in May 2001.

Adopted as 2nd Edition of Standard ECMA-299 by the General Assembly in December 2001.

- i -

Table of contents 1

Scope

Conformance

References (normative)

Definitions E x te r n a l d e f in itio n s A d d itio n a l n e tw o r k f e a tu r e ( A N F ) Original Call, Original Connection New Call, New Connection User A, Transferring User User B, Transferred User User C, Transferred-To User

2 2 2 2 2 3 3 3

List of acronyms

4 4.1 4.2 4.3 4.4 4.5 4.6 4.7 5 6

S S - S S C T s t a g e 1 s p e c if ic a t io n 6 . 1 D e s c r ip tio n 6.1.1 G e n e r a l d e s c r ip tio n 6.1.2 Q u a l i f i c a t i o n s o n a p p l i c a b i l i t y t o t e l e c o mmu n ic a t i o n s e r v i c e s 6.2 Procedure 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 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 (SS-CLIP) 6.3.2 C o n n e c t e d L i n e I d e n t i f i c a t io n P r e s e n ta tio n ( S S - CO L P ) 6.3.3 Ca llin g /Co n n e c te d L in e I d e n tif ic a tio n Re s tr ic tio n ( S S - CL I R) 6.3.4 C a l l i n g N a me I d e n t i f i c a t i o n P r e s e n t a t i o n ( S S - C N I P ) 6.3.5 C a l l i n g N a me I d e n t i f i c a t i o n R e s t r i c t i o n ( S S - C N I R ) 6.3.6 C o n n e c t e d N a me I d e n t i f i c a t io n P r e s e n ta tio n ( S S - CO N P ) 6.3.7 C o mp l e t i o n o f C a l l t o B u s y S u b s c r i b e r ( S S - C C B S ) 6.3.8 C o mp l e t i o n o f C a l l o n N o R e p ly ( S S - C C N R ) 6.3.9 Call Transfer (SS-CT) 6.3.10 Ca ll F o r w a r d in g U n c o n d itio n a l ( S S - CF U ) 6.3.11 C a l l F o r w a r d in g B u s y ( S S - C F B ) 6.3.12 Ca ll F o r w a r d in g N o Re p ly ( S S - CF N R) 6.3.13 Call Deflection (SS-CD) 6.3.14 P a t h R e p l a c e me n t ( A N F - P R ) 6.3.15 Call Offer (SS-CO) 6.3.16 Call Intrusion (SS-CI) 6.3.17 Do not Disturb (SS-DND)

3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5

- ii -

6.3.18 Do not Disturb Override (SS-DNDO) 6.3.19 A d v ic e o f Ch a r g e ( S S - A O C) 6.3.20 Recall (SS-RE) 6.3.21 Call Interception (ANF-CINT) 6.3.22 T r a n s it Co u n te r ( A N F - T C) 6.3.23 R o u te R e s t r i c t i o n C l a s s ( A N F - R R C ) 6.3.24 Me s s a g e W a itin g I n d ic a tio n ( S S - MW I ) 6.3.25 W ir e l e s s T e r mi n a l L o c a t i o n R e g i s t r a t i o n ( S S - W T L R ) 6.3.26 W ir e l e s s T e r mi n a l I n c o min g C a l l ( A N F - W T MI ) 6.3.27 W ir e l e s s T e r mi n a l O u t g o in g C a l l ( A N F - W T M O ) 6.3.28 W ir e l e s s T e r mi n a l A u t h e n t i c a t i o n o f a C T M U s e r ( S S - W T A T ) 6.3.29 W ir e l e s s T e r mi n a l A u t h e n t i c a t i o n o f t h e P I S N ( S S - W T A N ) 6.3.30 P r i v a t e U s e r M o b i l i t y I n c o min g C a l l ( A N F - P U M I ) 6.3.31 P r i v a t e U s e r M o b i l i t y O u t g o in g C a l l ( A N F - P U M O ) 6.3.32 P r i v a t e U s e r M o b i l i t y R e g is t r a t i o n ( S S - P U M R ) 6.3.33 C o mmo n I n f o r ma t i o n ( A N F - C MN ) 6.3.34 Call Priority Interruption (Protection) (SS-CPI(P)) 6 . 4 I n te r w o r k in g c o n s id e r a tio n s 6.4.1 U s e r B a n d /o r U s e r C in a n o th e r n e tw o r k 6.4.2 U s e r A in a n o th e r n e tw o r k 6.5 Overall SDL

5 5 6 6 6 6 6 6 6 6 6 6 6 6 6 7 7 7 7 7 8

S S - S S C T s t a g e 2 s p e c if ic a t io n 7 . 1 F u n c tio n a l mo d e l 7.1.1 F u n c tio n a l mo d e l d e s c r ip tio n 7.1.2 Description of functional entities 7.1.3 Re la tio n s h ip o f f u n c tio n a l mo d e l to Ba s ic Ca ll f u n c tio n a l mo d e l 7 . 2 I n f o r ma t i o n f l o w s 7.2.1 D e f in itio n o f in f o r ma tio n f lo w s 7.2.2 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 7.3 Functional Entity actions 7.3.1 Functional Entity actions of FE1 7.3.2 Functional Entity actions of FE2 7.3.3 Functional Entity actions of FE3 7.3.4 Functional Entity actions of FE4 7.3.5 Functional Entity actions of FE5 7.3.6 Functional Entity actions of FE6 7.3.7 Functional Entity actions of FE7 7 . 4 F u n c t i o n a l E n t i t y b e h a v io u r 7.4.1 Be h a v io u r o f F E 1 7.4.2 Be h a v io u r o f F E 2 7.4.3 Be h a v io u r o f F E 3 7.4.4 Be h a v io u r o f F E 4 7.4.5 Be h a v io u r o f F E 5 7.4.6 Be h a v io u r o f F E 6 7.4.7 Be h a v io u r o f F E 7

9 9 9 10 10 11 11 14 18 18 18 18 19 19 19 19 20 20 21 22 24 25 26 27

- iii -

7.5

A l l o c a t i o n o f f u n c t i o n a l e n t i t i e s t o p h ys i c a l l o c a t i o n s

A n n e x A - D i f f e r e n c e b e t w e e n S i n g l e S t e p C al l T r a n s f e r a n d C a l l T r a n s f e r b y R e r o u t i n g 2 9

- iv -

Scope This Standard specifies the Supplementary Service (SS) Single Step Call Transfer (SSCT), which is applicable to various basic services supported by Private Integrated Services Networks (PISN). Basic services are specified in ECMA-142. SS-SSCT is a supplementary service that enables an SSCT user, user A, to transform an existing call between user A and user B into a new call between user B and a user C whereby user A does not have a call established with user C prior to call transfer. 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 SS-SSCT. The stage 1 specification (clause 6) specifies the general feature principles and capabilities. The stage 2 specification (clause 7) identifies the Functional Entities involved in the supplementary service 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 service specified in this Standard. This means that, to claim conformance, a stage 3 standard is required to be adequate for the support of those aspects of clause 6 (stage 1) and clause 7 (stage 2) which are relevant to the interface or equipment to which the stage 3 standard applies.

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 64kbit/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 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)

ECMA-177

Private Integrated Services Network (PISN) - Specification, Functional Model and Information Flows - Call Transfer Supplementary Service (International Standard ISO/IEC 13865)

ECMA-178

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

ETS 300 387

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

ITU-T Rec. I.112

Vocabulary of terms for ISDN (1993)

Services

Networks

Addressing

(International

Standard

- 2 -

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)

–

Call (Basic call)

(ECMA-142)

–

PISN Number

(ECMA-155)

–

Private Integrated Services Network (PISN)

(ECMA-133)

–

Private Integrated services Network eXchange (PINX)

(ECMA-133)

–

Service

(ITU-T Rec. I.112)

–

Signalling

(ITU-T Rec. I.112)

–

Supplementary Service

(ITU-T Rec. I.210)

–

User

(ECMA-142)

This Standard refers to the following basic call Functional Entities (FE) 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: –

–

This Standard refers to the following basic call information flows defined in ECMA-142: –

SETUP request/indication

–

SETUP response/confirm

–

RELEASE request/indication

–

REPORT request/indication

–

INFORMATION request/indication

This Standard refers to the following service elements defined for basic call control in ECMA-142: –

4.2

Call History

Additional network feature (ANF) A capability provided by a PISN, not generally directly to a user, over and above that of the Basic call.

4.3

Original Call, Original Connection The call established between user A and user B.

4.4

New Call, New Connection The new call established between user B and user C.

- 3 -

4.5

User A, Transferring User The served user, i.e. the user requesting Single Step Call Transfer.

4.6

User B, Transferred User The other user in user A's original call.

4.7

User C, Transferred-To User The user to whom the call is transferred to.

List of acronyms

ANF

Additional Network Feature

Call Control (Functional Entity)

CCA

Call Control Agent (Functional Entity)

Functional Entity

FEA

Functional Entity Action

ISDN

Integrated Services Digital Network

PINX

Private Integrated services Network eXchange

PISN

Private Integrated Services Network

SDL

Specification and Description Language

Supplementary Service

SS-SSCT

Supplementary Service Single Step Call Transfer

Terminal Equipment

SS-SSCT stage 1 specification

6.1

Description

6.1.1

General description SS-SSCT is a service which enables a served user (user A) to transfer an active call (with user B) to a user (user C) which has no call established either to user A or to user B. The active call can either be an incoming call to user A or an outgoing call from user A. On successful completion of SS-SSCT user B and user C can communicate with each other and user A will no longer be involved in a call with user B or user C.

6.1.2

6.2

Qualifications on applicability to telecommunication services SS-SSCT is applicable to all basic services defined in ECMA-142.

Procedure

6.2.1

P r o v is io n /wit h d r a wa l SS-SSCT shall be generally available to all PISN users with the ability to invoke it.

6.2.2 Normal procedures 6.2.2.1 A c t iv a t io n , d e a c t iv a t io n a n d in t e r r o g a t io n Not applicable. 6.2.2.2

I n v o c a t io n a n d o p e r a t io n User A, having an active call with user B, may invoke SS-SSCT to transfer the active call to a user (user C) which has no call established either to user A or to user B. The Original call can either be an incoming call to user A or an outgoing call from user A. If, after invoking SS-SSCT, the number of the transferred-to user C supplied by user A is not complete, the transferred user B is requested to complete the number of the transferred-to user C.

- 4 -

It shall not be necessary to place the Original call on hold prior to invocation of SS-SSCT, although the call may be held. The result of successful SS-SSCT shall be a new call between the transferred user B and the transferred-to user C. Both users B and C may be informed of the transfer, and the name and the number of the other user if available and not subject to restriction. User A is no longer involved in the communication. User A may decide when the original connection shall be released: either upon the new connection starting ringing or upon being through connected. 6.2.3 Ex c e p t io n a l p r o c e d u r e s 6.2.3.1 A c t iv a t io n , d e a c t iv a t io n , a n d in t e r r o g a t io n Not applicable. 6.2.3.2

I n v o c a t io n a n d o p e r a t io n SS-SSCT shall be rejected if the interconnection of user B and user C is not permitted. If the new call fails or if SS-SSCT is rejected user A shall be informed and the Original call between user A and user B shall be unaffected. Failure of the new call also includes inter-digit timeout due to user B failing to complete the number of user C in a timely manner.

6.3

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.

6.3.1

Calling Line Identification Presentation (SS-CLIP) No interaction.

6.3.2

Connected Line Identification Presentation (SS-COLP) No interaction.

6.3.3

C a l l i n g /C o n n e c t e d L i n e I d e n t i f i c a t i o n R e s t r i c t i o n ( S S - C L I R ) User B's restriction requirements from the original call shall be used to restrict the presentation of user B's number to user C in a transferred call.

6.3.4

Calling Name Identification Presentation (SS-CNIP) No interaction.

6.3.5

Calling Name Identification Restriction (SS-CNIR) User B's restriction requirements from the original call shall be used to restrict the presentation of user B's name to user C in a transferred call.

6.3.6

Connected Name Identification Presentation (SS-CONP) No interaction.

6.3.7

Completion of Call to Busy Subscriber (SS-CCBS) No interaction.

6.3.8

Completion of Call on No Reply (SS-CCNR) No interaction.

6.3.9

C a ll Tr a n s f e r ( S S - C T) SS-SSCT shall not be initiated during SS-CT. SS-CT shall not be initiated during SS-SSCT.

6.3.10

C a ll F o r wa r d in g U n c o n d it io n a l ( S S - C F U ) The new call can be subject of call forwarding unconditional.

6.3.11

C a ll F o r wa r d in g Bu s y ( S S - C F B) The new call can be subject of call forwarding busy.

- 5 -

6.3.12

C a ll F o r wa r d in g N o R e p ly ( S S - C F N R ) The new call can be subject of call forwarding on no reply.

6.3.13

C a ll D e f le c t io n ( S S - C D ) The new call can be subject of call deflection.

6.3.14

Path Replacement (ANF-PR) No interaction. NOTE 1 Path Replacement may be invoked as a direct consequence of performing single step call transfer.

6.3.15

C a ll O f f e r ( S S - C O ) No interaction.

6.3.16

C a ll I n t r u s io n ( S S - C I ) User A shall not be able to invoke SS-SSCT during the impending intrusion state or the intrusion state.

6.3.17

Do not Disturb (SS-DND) No interaction.

6.3.18

Do not Disturb Override (SS-DNDO) No interaction.

6.3.19 A d v ic e o f C h a r g e ( S S - A O C ) 6 . 3 . 1 9 . 1 A d v ic e o f C h a r g e : c h a r g in g in f o r m a t io n a t c a ll s e t - u p t im e ( A O C - S ) If, prior to transfer, user A was receiving AOC-S information for the original call, at the time of single step call transfer, SS-AOC-S shall be stopped. If at the time of the single step call transfer it is decided that user A will not be charged for the call prior to transfer, then the specific rate "free of charge from the beginning" shall be given to user A prior to stopping SS-AOC-S. User A shall not be allowed to invoke SS-AOC-S on a call resulting from transfer. After transfer, SS-AOC-S may be invoked for user B either automatically or on request from the user. It shall not be possible to invoke SS-AOC-S until after user C has answered. AOC-S information in that case may contain charges incurred prior to transfer (as specific rate “flat rate”). 6.3.19.2

A d v ic e o f C h a r g e : c h a r g in g in f o r m a t io n d u r in g t h e c a ll ( A O C - D ) If, prior to transfer, user A was receiving AOC-D information for the original call, then at the time of transfer, the (sub)total charges shall be sent to user A and SS-AOC-D shall be stopped. If at the time of the transfer it is decided that user A will not be charged for the call prior to transfer, then the (sub)total charges sent to user A will have value "0" or "free of charge". NOTE 2 The charges will be total charges if user A is not charged for the call resulting from transfer and subtotal charges otherwise. User A shall not be allowed to invoke SS-AOC-D on a call resulting from transfer. After transfer SS-AOC-D may be invoked for user B (or C) either automatically or on request from the user. It shall not be possible to invoke SS-AOC-D until after user C has answered. If the user for which SS-AOC-D is invoked is to be charged for the call resulting from transfer, AOC-D information in that case may contain charges incurred prior to transfer.

6.3.19.3

A d v ic e o f C h a r g e : c h a r g in g in f o r m a t io n a t t h e e n d o f t h e c a ll ( A O C - E) If, prior to transfer, user A was due to receive AOC-E information for the original call, and if user A continues to be charged for the call resulting from transfer, then at the time of transfer, as an implementation option, SS-AOC-E for user A may remain in progress. If SS-AOC-E remains in progress when the call resulting from transfer is released, AOC-E information (i.e. the total charges incurred for the call prior to transfer and for the call resulting from transfer) shall be sent to user A and AOC-E shall be stopped. If SS-AOC-E does not remain in progress, then at the time of transfer, user A shall be advised that final charge information is not available.

- 6 -

With the invocation of Call Transfer, user A may provide an identifier. If user A is to receive AOC-E information then, together with the AOC-E information, this identifier shall be returned by the PISN to user A. If, prior to transfer, user A was due to receive AOC-E information for the original call, and if user A does not continue to be charged for the call resulting from transfer, then at the time of transfer, (i.e. when the call to user A is cleared) SS-AOC-E for user A shall be stopped and AOC-E information shall be sent to user A. NOTE 3 AOC-E information sent in this situation to user A can be either: the total charges incurred for the call prior to transfer (if user A is charged for that part of the call); total charges with value "0" or "free of charge" if at the time of the transfer the PISN decides that user B or user C is to be charged for the part of the call prior to transfer also. User A shall not be allowed to invoke AOC-E only for the call resulting from transfer. After transfer AOC-E may be invoked for user B (or C) either automatically or on request from the user. It shall not be possible to invoke SS-AOC-E until after user C has answered. If the user for which SS-AOC-E is invoked is to be charged for the call resulting from transfer, AOC-E information at the end of the call to user B (or C) may contain charges incurred prior to transfer. 6.3.20

R e c a ll ( S S - R E) No interaction.

6.3.21

Call Interception (ANF-CINT) A call resulting from transfer can be subject to interception if it continues to alert or wait on busy at the transferred-to user (user C) without reply.

6.3.22

Tr a n s it C o u n t e r ( A N F - TC ) ANF-TC may apply to the establishment of the new connection during single step call transfer.

6.3.23

Route Restriction Class (ANF-RRC) No interaction.

6.3.24

M e s s a g e W a it in g I n d ic a t io n ( S S - M W I ) No interaction.

6.3.25

W i r e l e s s T e r m i n a l L o c a t io n R e g i s t r a t i o n ( S S - W T L R ) No interaction.

6.3.26

Wireless Terminal Incoming Call (ANF-WTMI) No interaction.

6.3.27

Wireless Terminal Outgoing Call (ANF-WTMO) No interaction.

6.3.28

Wireless Terminal Authentication of a CTM User (SS-WTAT) No interaction

6.3.29

Wireless Terminal Authentication of the PISN (SS-WTAN) No interaction.

6.3.30

Private User Mobility Incoming Call (ANF-PUMI) No interaction.

6.3.31

P r i v a t e U s e r M o b i l i t y O u t g o in g C a l l ( A N F - P U M O ) No interaction.

6.3.32

P r i v a t e U s e r M o b i l i t y R e g is t r a t i o n ( S S - P U M R ) No interaction.

- 7 -

6.3.33

Common Information (ANF-CMN) No interaction. NOTE 4 ANF-CMN users involved in a call resulting from Single Step Call Transfer may exchange Common Information subsequent to transfer.

6.3.34

6.4

C a ll P r io r it y I n t e r r u p t io n ( P r o t e c t i o n ) ( S S - C P I ( P ) ) No interaction.

Interworking considerations The Single Step Call Transfer may take place when one or both of the calls involves interworking with a public ISDN or a public or private non-ISDN.

6.4.1

U s e r B a n d /o r U s e r C in a n o t h e r n e t wo r k Since the execution of the Single Step Call Transfer service need only involve the interconnection within the PISN of one end of each of the two connections (the original or/and the new call), the nature of the network (ISDN or non-ISDN) containing user B or user C makes no difference to the operation of the service as seen by user A. The PISN shall pass on any notifications associated with the Single Step Call Transfer to the other network if the other network is capable of receiving this information, the possibilities being the notifications that Single Step Call Transfer has taken place, the name and number (if appropriate) of the other user and the other user's subaddress and compatibility information. In the case where user B and user C are in the same network, the PISN may be able to co-operate with that network in order to effect Single Step Call Transfer in that network if that network supports a similar service (e.g. Call Transfer).

6.4.2

U s e r A in a n o t h e r n e t wo r k The PISN shall accept Single Step Call Transfer notifications from another network and pass them on to the PISN user. Single Step Call Transfer notifications include notifications that transfer has taken place, the name and number of the other user and the other user's subaddress and compatibility information. Where this information is not provided, a PISN user will have to rely on in-band information.

- 8 -

6.5

Overall SDL Figure 1 contains the dynamic description of SS-SSCT using the Specification and Description Language (SDL) defined in ITU-T Rec. Z.100 (1999). The SDL process represents the behaviour of the PISN in providing SS-SSCT. Input signals from the left and output signals to the left represent primitives from and to user A. Input signals from the right and output signals to the right represent primitives from and to user B and user C.

Idle

Active Call between User A and User B

SSCT request by User A

User C's number complete to route

User B is requested to post-dial number of User C

repeated until User C's number is complete

YES

initiate call establishment to User C

digits (User C's number) sent by User B

User B to be notified Attempt to connect User B to User C

Transfer successful?

User C to be notified NO

Get cause

YES

Transfer reject

Transfer successful

Idle

Figure 1 - SS-SSCT, Overall SDL

Clear original connection towards User A

Idle

YES

Notify User B

YES

Notify User C

- 9 -

SS-SSCT stage 2 specification A stage 3 standard for SS-SSCT shall be capable of supporting the functional breakdown of the service specified in this clause.

7.1 7.1.1

Functional model Functional model description The functional model shall comprise the following Functional Entities: FE1

Single Step Transfer Invoke

FE2

Single Step Transfer Co-ordinate

FE3

Single Step Transfer Execute

FE4

Single Step Transfer Detection

FE5

Single Step Transfer Complete Receive

FE6

Single Step Transfer Notification Receive and Provision of complete transferred-to number

FE7

Single Step Transfer Notification Receive

The following functional relationships shall exist between these FEs: rr

between FE1 and FE2

between FE2 and FE3

between FE3 and FE4

between FE3 and FE5

between FE5 and FE6

between FE4 and FE7

between FE6 and FE7

Figure 2 shows these FEs and relationships.

User A FE1 rr FE2 rs rt FE4

FE3 ru

rw rv User B

FE5 User C

rx FE7

FE6

Figure 2 - Functional model of SS-SSCT

- 10 -

7.1.2 D e s c r ip t io n o f f u n c t io n a l e n t it ie s 7.1.2.1 S in g le S t e p Tr a n s f e r I n v o k e F u n c t io n a l En t it y , F E1 This FE acts on behalf of user A. It is responsible for recognising user A's decision to effect Single Step Call Transfer. 7.1.2.2

S in g le S t e p Tr a n s f e r C o - o r d in a t e F u n c t io n a l En t it y , F E2 This FE checks that details known concerning the original and the new call do not preclude the interconnection of user B and user C, and requests FE3 to execute the single step transfer.

7.1.2.3

S in g le S t e p Tr a n s f e r Ex e c u t e F u n c t io n a l En t it y , F E3 This FE initiates the establishment of the new connection between user B and user C. On detection of an incomplete transferred-to number, it indicates this to FE5. On successful completion of the single step transfer it notifies FE5 of the fact that the single step transfer has occurred.

7.1.2.4

S in g le S t e p Tr a n s f e r D e t e c t io n F u n c t io n a l En t it y , F E4 On successful completion of the single step transfer FE4 notifies FE7 of the fact that the single step transfer has occurred.

7.1.2.5

Single Step Transfer Complete Receive Functional Entity, FE5 This FE notifies FE6 that a transfer has occurred, along with the details of the new call. On indication from FE3 that the transferred-to number is incomplete, it requests FE6 to complete this number.

7.1.2.6

Single Step Transfer Notification Receive and Provision of complete transferred-to number Functional Entity, FE6 This FE receives on behalf of user B the indication that a single step transfer has occurred, and the details of the new call. This FE also passes to FE7 details relevant to the single step transfer which are not provided by the networks. On request from FE5 to complete the transferred-to number, this FE provides the complete transferred-to number.

7.1.2.7

S i n g l e S t e p T r a n s f e r N o t i f i c a t i o n R e c e i v e F u n c t io n a l E n t i t y , F E 7 This FE receives on behalf of user C the indication that a single step transfer has occurred, and the details of the new call. This FE also passes to FE6 details relevant to the single step transfer which are not provided by the networks.

7.1.3

R e la t io n s h ip o f f u n c t io n a l m o d e l t o Ba 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, except where user A's terminal is stimulus with respect to single step transfer but functional with respect to the basic call, in which case FE1 shall be collocated with user A's CC. Functional Entity FE2 shall be collocated with user A's CC. Functional Entity FE3 shall be collocated with user A's CC, with any Transit CC, or with user B's CC. Functional Entity FE4 shall be collocated with user C's CC. Functional Entity FE5 shall be collocated with user B's CC. Functional Entity FE6 shall be collocated with user B's CCA, except where user B's terminal is stimulus with respect to single step transfer but functional with respect to the basic call, in which case FE6 shall be collocated with user B's CC. Functional Entity FE7 shall be collocated with user C's CCA, except where user C's terminal is stimulus with respect to single step transfer but functional with respect to the basic call, in which case FE7 shall be collocated with user B's CC. An example of a relationship between the FEs for SS-SSCT and FEs for the basic call is shown in figure 3.

- 11 -

User A FE1

CCA

FE2

r2 CC

FE3

rt FE4

CC ru

FE5

r3 rv

CCA

FE6

FE7

User B

CCA

User C

F ig u r e 3 - Ex a m p le R e la t io n s h ip b e t we e n M o d e l f o r S S - S S C T a n d B a s i c C a l l

7.2

Information flows

7.2.1

7.2.1.1

D e f in it io n o f in f o r m a t io n f lo ws In the tables listing the elements in information flows, the column headed "Request" indicates which of these elements are mandatory (M) and which are optional (O) in a request/indication information flow, and the column headed "Confirm" indicates which of these elements are mandatory (M) and which are optional (O) in a response/confirmation information flow. S in g le S t e p C a ll Tr a n s f e r I n v o k e This is a confirmed information flow across rr from FE1 to FE2 which initiates a single step call transfer. Table 1 lists the service elements within the Single Step Call Transfer Invoke information flow. Table 1 - Content of Single Step Call Transfer Invoke Service element

Request

Confirm

Transfer Invoke Result

Transferred-to Number

Service element Transferred-to Number shall contain a number which will enable the new connection to be routed to FE4. The Transferred-to Number can be incomplete (post-dialing is required). Service element Transfer Invoke Result contains the result of the single step call transfer invoke request and, if it indicates rejection, identifies the reason for rejection. An indication of rejection means that the original call has not been affected by the invocation request. An indication of acceptance means that the single step call transfer has been effected and that users B and C are now involved in the same call, without the involvement of user A.

- 12 -

7.2.1.2

S in g le S t e p C a ll Tr a n s f e r I n it ia t e This is a confirmed information flow across rs from FE2 to FE3 which determines the ability of FE3 to participate in the single step call transfer and, if so, to set up a call using the information which was provided by FE2. Table 2 lists the service elements within the Single Step Call Transfer Initiate information flow. Table 2 - Content of Single Step Call Transfer Initiate Service element

Request

Confirm

Transferred-to Number

Transferred Address

Transferring Address

Await Connect

Transferred Name

Transferring Name

Transfer Initiate Result

Service element Transferred-to Number shall contain a number which will enable the new connection to be routed to FE4. The Transferred-to Number can be incomplete (post-dialing is required). Service element Transferred Address shall contain the address of the transferred user which shall be routed to FE4. Service element Transferring Address if present shall contain the address of the transferring user which routes the new connection to FE4. Service element Await Connect if present shall contain the indication when the original call shall be released. Service elements Transferred Name and Transferring Name may be omitted in case of name not available or in case of presentation restricted or not implemented. Service element Transfer Initiate Result shall contain the result of the transfer initiate request, and if it indicates rejection, then it shall identify the reason for rejection. Rejection may occur if the new connection cannot be established, e.g. because of congestion. 7.2.1.3

S in g le S t e p C a ll Tr a n s f e r S e t u p This unconfirmed flow across rt from FE3 to FE4 is associated with a "basic call" Setup Information flow for the new call using the Transferred-to Number provided by FE2. Table 3 lists the service elements within the Single Step Call Transfer Setup information flow. Table 3 - Content of Single Step Call Transfer Setup Service element

Request

Transferring Address

Transferring Name

Service element Transferring Address if present shall contain the address of the user which routes the new connection to FE4. Service element Transferring Name if present shall contain the name of the user which routes the new connection to FE4. 7.2.1.4

S in g le S t e p C a ll Tr a n s f e r P o s t D ia l This is an unconfirmed flow across ru from FE3 to FE5 which indicates to FE5 that the transferred-to number is incomplete.

- 13 -

There are no service elements in this information flow. 7.2.1.5

S in g le S t e p C a ll Tr a n s f e r D ig it I n f o This is an unconfirmed flow across ru from FE5 to FE3 which provides to FE3 the transferred-to number. Table 4 lists the service elements within the Single Step Call Transfer Digit Info information flow. Table 4 - Content of Single Step Call Transfer Digit Info Service element

Request

Transferred-to Number

Sending Complete Indicator

Service element Transferred-to Number if present shall contain the digits of the transferred-to number so far available. The remaining part of the transferred-to number will be sent by repeating the single step call transfer digit info flow. Service element Sending Complete Indicator if present shall contain the indication that the number is complete. 7.2.1.6

S in g le S t e p C a ll Tr a n s f e r P o s t D ia l R e q u e s t This is an unconfirmed flow across rv from FE5 to FE6 which indicates to FE6 that the transferred-to number is incomplete. There are no service elements in this information flow.

7.2.1.7

D ig it I n d ic a t io n This is an unconfirmed flow across rv from FE6 to FE5 which conveys the digits to complete the transferred-to number. Table 5 lists the service elements within the Digit Indication information flow. T a b l e 5 - C o n t e n t o f S i n g l e S t e p C a ll Tr a n s f e r D ig it I n d ic a t io n Service element Digits

Request O

Service element Digits shall comprise the remaining digits to complete the transferred-to number. 7.2.1.8

Tr a n s f e r N o t if y This is an unconfirmed flow across rv from FE5 to FE6 and across rw from FE4 to FE7 which informs users of the successful completion of a Single Step Call Transfer, and appropriate details of the other user. It can be repeated to provide further information about the single step transfer that has already been notified. Table 6 lists the service elements within the Single Step Transfer Notify information flow. Table 6 - Content of Single Step Transfer Notify Service element

Request

Call History

Connected Name

Connected Subaddress

Terminal Details Request

Service element Call History is described in ECMA-142. Service element Connected Name shall comprise the elements of information flow INFORM4 of ECMA-163.

- 14 -

Service element Connected Subaddress shall be as defined in ECMA-148 and shall be included only when available from information flow Transfer Active. Service element Terminal Details Request shall be included if FE6 or FE7 is to be invited to send the Terminal Details information flow. 7.2.1.9

Terminal Details This is an unconfirmed information flow across rx from FE6 to FE7 or vice versa which allows the swapping of information between the users involved in the new call where such information is not necessarily stored by the network. Table 7 lists the service elements within the Terminal Details information flow. Table 7 - Content of Terminal Details Service element Connected Subaddress

Request O

Service element Connected Subaddress is described in ECMA-148. 7.2.1.10

Tr a n s f e r C o m p le t e This is an unconfirmed information flow across ru from FE3 to FE5 which indicates that a transfer has been effected. For the service elements within the Transfer Complete information flow refer to ECMA-177.

7.2.1.11

Tr a n s f e r A c t iv e This is an unconfirmed information flow across ru from FE3 to FE5 which indicates that answer has taken place following an alerting transfer. For the service elements within the Transfer Active information flow refer to ECMA-177.

7.2.1.12

Tr a n s f e r U p d a t e This is an unconfirmed flow across rt and ru which allows user B's FE5 and user C's FE4 to inform each other of all details about the transferred users that are known to the network if user C's number is known. For the service elements within the Transfer Update information flow refer to ECMA-177.

7.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 Below are examples of typical sequences of information flows. In addition to providing signalling procedures in support of these sequences, a stage 3 standard shall also cover other sequences arising from error situations, interactions with basic call, interactions with other supplementary services, different topologies, etc. In the figures, SS-SSCT information flows are represented by solid arrows and basic call information flows are represented by broken arrows. An ellipse embracing two information flows indicates that the two information flows occur simultaneously. Within a column representing an SS-SSCT functional entity, the numbers refer to functional entity actions listed in 7.3.

- 15 -

7.2.2.1

S u c c e s s f u l S in g le S t e p C a ll Tr a n s f e r , t r a n s f e r o c c u r s o n a c t iv e n e w c a ll Figure 4 shows the information flow sequence for normal operation of SS-SSCT when transfer occurs on active new call. rx rt rs

FE6

CCA

FE5

User B CC

FE3

FE1

CCA

601

req/ind

Note 5 Digit Indication req/ind

Note 6

501

FE4

User A CC

User C

401

Single Step Call Transfer Notify

FE7

CCA

201

req/ind

Single Step Call Transfer Initiate req/ind

Single Step Call Transfer 301 Post Dial req/ind

Note 5 Single Step

502 Call Transfer Digit Info req/ind

Single Step Call Transfer Setup

302

req/ind

Note 6

Setup req/ind Informmation req/ind Note 6

Transfer Single Step Complete Call Transfer 503 Notify req/ind req/ind

req/ind

701

Report

303

602

FE2

Single Step Call Transfer Invoke

101

Single Step Call Transfer Post Dial Request

req/ind Setup

304

resp/cfm Single Step call Transfer Initiate resp/cfm

102

202

Single Step Call Transfer Invoke resp/cfm

Terminal Details

701

req/ind

NOTE 5 This information flow is sent only in case of incomplete transferred-to number. NOTE 6 This information flows are sent only in case of incomplete transferred-to number. These actions may be repeated until the whole transferred-to number has been sent. Figure 4 - Information Flow Sequence - Normal Operation of SS-SSCT, transfer occurs on active new call The Terminal Details flow is optional. If it occurs it may occur in either or both directions and is initiated on receipt of a Single Step Transfer Notify containing element Terminal Details Request.

- 16 -

7.2.2.2

Successful Single Step Call Transfer, transfer occurs on alerting new call Figure 5 shows the information flow sequence for normal operation of SS-SSCT when transfer occurs on alerting new call. rx rt rs

FE6

CCA

FE5

User B CC

FE3

FE1

CCA

101

601

Single Step Single Step Call Transfer Call Transfer Post Dial Post Dial 301 501 Request req/ind req/ind

502

req/ind

Single Step Call Transfer Digit Info req/ind

Note 8

FE4

User A CC

User C

401

Single Step Call Transfer Notify

Single Step Call Transfer Invoke

FE7

CCA

201

req/ind

Single Step Call Transfer Initiate req/ind

302

Single Step Call Transfer Setup req/ind

Note 8

Setup req/ind Information

Note 8

req/ind

602

FE2

Note 7

Note 7 Digit Indication

Single Step Call Transfer Notify 503 req/ind

Transfer Complete

305

701

req/ind Single Step call Transfer Initiate

req/ind

Report

resp/cfm

102

202

Single Step Call Transfer Invoke resp/cfm

602

Single Step Call Transfer Notify req/ind

504

Transfer Active

Setup

306

resp/cfm

req/ind

Terminal Details

701

req/ind

NOTE 7 This information flow is sent only in case of incomplete transferred-to number. NOTE 8 This information flows are sent only in case of incomplete transferred-to number. These actions may be repeated until the whole transferred-to number has been sent. Figure 5 - Information Flow Sequence - Normal Operation of SS-SSCT, transfer occurs on alerting new call The Terminal Details flow is optional. If it occurs it may occur in either or both directions and is initiated on receipt of a Single Step Transfer Notify containing element Terminal Details Request.

- 17 -

7.2.2.3

Unsuccessful Single Step Call Transfer (setup fails) Figure 6 shows the information flow sequence for unsuccessful operation of SS-SSCT when basic call does not reach user C's PINX owing to congestion. rx rt rs

FE6

CCA

FE5

User B CC

FE3

FE1

CCA

101

301

FE2

FE4

User A CC

Single Step Call Transfer Invoke req/ind

User C

FE7

CCA

201

Single Step Call Transfer Initiate req/ind

Single Step Call Transfer Setup req/ind

Note 9 Setup req/ind

Release

303

req/ind

Single Step Call Transfer Initiate (Reject) resp/cfm

102

202 Note 10

Single Step Call Transfer Invoke (Reject) resp/cfm

NOTE 9 Basic call does not reach user C's PINX owing to congestion. NOTE 10 If single step call transfer fails, the original call shall continue. Figure 6 - Information Flow Sequence - Unsuccessful Operation of SS-SSCT (call setup fails)

- 18 -

7.3

Functional Entity actions The following FE actions shall occur at the points indicated in the figures of 7.2.2.

7.3.1

F u n c t io n a l En t it y a c t io n s o f F E1 101 FE1 detects the user request for single step call transfer. Local checks on the suitability of the transfer may be made and the request rejected on the basis of such checks. If the single step call transfer is not barred locally, a Single Step Call Transfer Invoke request is sent to FE2. 102

7.3.2

On receipt of the Single Step Call Transfer Invoke confirmation, FE1 informs the user of the result, and in the case of successful completion, it may release the original call if it has not yet been released.

F u n c t io n a l En t it y a c t io n s o f F E2 201 On receipt of a Single Step Call Transfer Invoke indication from FE1, FE2 identifies the original call and checks the validity of the request from the network's point of view. If the single step call transfer is found to be valid, a Single Step Call Transfer Initiate request is sent to FE3. If the single step call transfer is found to be invalid, a Single Step Call Transfer Invoke response is sent to FE1 indicating rejection. 202

7.3.3

On receipt of the Single Step Call Transfer Initiate confirmation from FE3, a Transfer Invoke response is sent to FE1 if FE3 indicates successful completion of the single step call transfer. If FE3 has been unable to complete the single step call transfer, the original call continues.

F u n c t io n a l En t it y a c t io n s o f F E3 301 On receipt of a Single Step Call Transfer Initiate indication from FE2, FE3 determines whether or not it can participate in the single step call transfer. If FE3 is not able to participate in the single step call transfer, a response indicating rejection is returned to FE2. Additionally FE3 checks if the received transferred-to number is complete. If the transferred-to number is not complete, a Single Step Call Transfer Post Dial indication is sent to FE5 and if a part of the transferred-to number is available and sufficient to route, a Single Step Call Transfer Setup request is sent to FE4 associated with a basic call request. Otherwise if the transferred-to number is complete a Single Step Call Transfer Setup request is sent to FE4 associated with a basic call request. 302

On receipt of one or more Single Step Call Transfer Digit Info indication(s) from FE5 and if no new call is established with FE4 and the transferred-to number is sufficient to route, a Single Step Call Transfer Setup request is sent to FE4 associated with a basic call request. Otherwise if a call is already established with FE4, a Information request with further digit(s) of the transferred-to number is sent to FE4. This action is repeated until the whole transferred-to number has been sent.

303

If the Service Element Await Connect of the Single Step Call Transfer Initiate indicated that the call shall be released after receipt of a Setup confirmation, then on receipt of a Report indication from FE4 no further action will be taken and the Setup confirmation of the new connection is awaited.

304

If the action described in 303 above applies, upon receipt of a Setup confirmation from FE4 the new connection is joined to the part of the original call towards user B, a response indicating successful completion is sent to FE2, the part of the original call towards user A is released and a Transfer Complete indication with callStatus "answered" is sent to FE5.

305

If the Service Element Await Connect of the Single Step Call Transfer Initiate indicated that the call shall be released after receipt of a Report indication, then on receipt of a Report indication from FE4 the new connection is joined to the part of the original call towards user B, a response indicating successful completion is sent to FE2, the part of the original call towards user A is released. and a Transfer Complete indication with callStatus "alerting" is sent to FE5. If instead the basic call associated with the Single Step Call Transfer Setup request fails, the Single Step Call Transfer Initiate is rejected and FE3 takes no further part in the Single Step Call Transfer.

- 19 -

306

If the action described in 305 above applies, upon receipt of a Setup confirmation from FE4 a Transfer Active indication is sent to FE5. If instead no Setup Confirmation is received, the connection towards user A is released.

7.3.4

F u n c t io n a l En t it y a c t io n s o f F E4 401 On receipt of the Single Step Call Transfer Setup indication from FE3 and in case of overlap sending upon completion of the transferred-to number, either a basic call alerting or a basic call connect indication is returned to FE3, and a Single Step Call Transfer Notify request is sent to the FE7. The Single Step Call Transfer Notify contains element Terminal Details Request unless it is sent to a user C that has not answered.

7.3.5

F u n c t io n a l En t it y a c t io n s o f F E5 501 On receipt of a Single Step Call Transfer Post Dial indication from FE3 a Single Step Call Transfer Post Dial request is sent to the associated FE6.

7.3.6

502

On receipt of the digits from FE6 one or more Single Step Call Transfer Digit Info indication(s) is (are) sent to FE3.

503

On receipt of a Transfer Complete indication from FE3, a Single Step Call Transfer Notify request is sent to the associated FE6 and details relevant to the network concerning the new user (user C) in the call may be stored.

504

On receipt of a Transfer Active indication from FE3, a Single Step Call Transfer Notify request is sent to the associated FE6.

F u n c t io n a l En t it y a c t io n s o f F E6 601 On receipt of a Single Step Call Transfer Post Dial request, FE6 sends digits to complete the transferred-to number to FE5. 602

7.3.7

On receipt of a Single Step Call Transfer Notify indication from FE5 or a Terminal Details indication from FE7, relevant details may be stored. In the case of receipt of a Single Step Call Transfer Notify indication containing element Terminal Details Request, a Terminal Details request may be sent to FE7 if appropriate.

F u n c t io n a l En t it y a c t io n s o f F E7 701 On receipt of a Single Step Call Transfer Notify indication from FE4 or a Terminal Details indication from FE6, relevant details may be stored. In the case of receipt of a Single Step Call Transfer Notify indication containing element Terminal Details Request, a Terminal Details request may be sent to FE6 if appropriate.

- 20 -

7.4

Functional Entity behaviour The FE behaviours shown below are intended to illustrate typical FE behaviour in terms of information flows sent and received. The behaviour of each FE is shown using the Specification and Description Language (SDL) defined in ITU-T Rec. Z.100.

7.4.1

Be h a v io u r o f F E1 Figure 7 shows the normal behaviour of FE1. Input signals from the left and output signals to the left represent primitives from and to user A. Input signals from the right and output signals to the right represent information flows from and to FE2.

Idle

SSCT request

Do local checks preclude transfer?

YES

SSCT invoke req/ind (to FE2)

Awaiting confirmation

SSCT invoke resp/cfm (from FE2)

SSCT successful?

YES

release original call

SSCT successful

Get cause

SSCT reject

Idle

Figure 7 - SS-SSCT, SDL for functional entity FE1

- 21 -

7.4.2

Be h a v io u r o f F E2 Figure 8 shows the normal behaviour of FE2. Input signals from the left and output signals to the left represent information flows from and to FE1. Input signals from the right and output signals to the right represent information flows from and to FE3. Idle

SSCT Invoke req/ind (from FE1)

Identify original call

Single Step Call Transfer allowed?

SSCT Invoke resp/cfm reject (to FE1)

YES

SSCT initiate req/ind (to FE3)

Idle

Awaiting Confirmation

SSCT Initiate resp/cfm (from FE3)

SSCT successful?

Original call shall not be released

YES

release original call

SSCT Invoke resp/cfm (to FE1)

Idle

SSCT Invoke resp/cfm reject (to FE1)

Idle

Figure 8 - SS-SSCT, SDL for Functional Entity FE2

- 22 -

7.4.3

Be h a v io u r o f F E3 Figure 9 shows the normal behaviour of FE3. Input signals from the left and output signals to the left represent information flows from and to FE5. Input signals from the right and output signals to the right represent information flows from and to FE4 and FE2 and basic call CCs collocated with FE4. Idle

SSCT initiate req/ind (from FE2)

Do local checks preclude transfer?

YES

Get cause

transferred-to number complete or sufficient to route on?

SSCT initiate req/ind reject (to FE2)

YES

new call with SSCT setup req/ind (to FE4)

Idle

SSCT Post Dial req/ind (to FE5)

enough digits to route to FE4?

YES

new call with SSCT setup req/ind (to FE4)

SSCT Digit Info req/ind (from FE5)

new call already established with FE4?

YES

Information req/ind (to BC)

new call with SSCT setup req/ind (to FE4)

transferred-to number complete? YES

Await Response (from BC)

F ig u r e 9 ( s h e e t 1 o f 2 ) - S S - S S C T, S D L f o r F u n c t io n a l En t it y F E3

- 23 -

Await Response (from BC)

Release req/ind (from BC)

Report req/ind (from BC)

YES

Await Connect (from BC)

Await Connect (from BC)?

Setup resp/cfm (from BC)

SSCT initiate resp/cfm (to FE2)

SSCT initiate resp/cfm (to FE2) Release req/ind (from BC)

Setup resp/cfm (from BC)

SSCT initiate resp/cfm reject (to FE2)

SSCT initiate resp/cfm (to FE2)

Call transfer complete req/ind (to FE5)

Setup resp/cfm (from BC)

Call transfer active req/ind (to FE5)

Idle

F ig u r e 9 ( s h e e t 2 o f 2 ) - S S - S S C T, S D L f o r F u n c t io n a l En t it y F E3

- 24 -

7.4.4

Be h a v io u r o f F E4 Figure 10 shows the normal behaviour of FE4. Input signals from the left and output signals to the left represent information flows from and to FE7. Input signals from the right and output signals to the right represent information flows from and to FE3 and basic call CCs collocated with FE3

Idle

SSCT setup req/ind (from FE3)

transferred-to number complete?

Information req/ind (from BC)

YES

Set up basic call to user C

SSCT notify req/ind (to FE7)

Idle

Figure 10 - SS-SSCT, SDL for Functional Entity FE4

- 25 -

7.4.5

Be h a v io u r o f F E5 Figure 11 shows the normal behaviour of FE5. Input signals from the left and output signals to the left represent information flows from and to FE6. Input signals from the right and output signals to the right represent information flows from and to FE3. Idle

SSCT Post Dial req/ind (from FE3)

Post Dial request req/ind (to FE6)

Call transfer complete req/ind (from FE3)

SSCT notify req/ind (to FE6)

Call transfer active req/ind (from FE3)

SSCT notify req/ind (to FE6)

Digit Indication (from FE6)

SSCT Digit Info req/ind (to FE3)

transferred-to number complete YES

Idle

Figure 11 - SS-SSCT, SDL for Functional Entity FE5

- 26 -

7.4.6

Be h a v io u r o f F E6 Figure 12 shows the normal behaviour of FE6. Input signals from the left and output signals to the left represent primitives from and to user B. Input signals from the right and output signals to the right represent information flows from and to other FEs.

Idle

SSCT Post Dial req/ind (from FE5)

Request user B to send remaining digits

Digit indication req/ind (to FE5)

SSCT notify req/ind (from FE5)

SSCT details req/ind (from FE7)

Details to user B

SSCT notify

SSCT details to send?

YES

transferred-to number complete?

SSCT details req/ind (to FE7)

YES

Idle

Figure 12 - SS-SSCT, SDL for Functional Entity FE6

- 27 -

7.4.7

Be h a v io u r o f F E7 Figure 13 shows the normal behaviour of FE7. Input signals from the left and output signals to the left represent primitives from and to user C. Input signals from the right and output signals to the right represent information flows from and to other FEs.

Idle

SSCT details req/ind (from FE6)

SSCT notify req/ind (from FE4)

SSCT notify (to user C)

SSCT details to send?

Details to user C

YES

SSCT details req/ind (to FE6)

Idle

Figure 13 - SS-SSCT, SDL for Functional Entity FE7

- 28 -

7.5

Allocation of functional entities to physical locations Table 8 illustrates the various scenarios possible, excluding the cases of stimulus terminals. Where a terminal involved is stimulus with respect to transfer, any FE shown as residing in the corresponding user's TE shall reside instead in that user's PINX. Table 8 - FE location scenarios Scenarios

Functional Entities User A FE1

User A FE2

FE3

User C FE4

User C FE7

User B FE5

User B FE6

Scenario 1

PINX

Scenario 2

PINX

other network

PINX

Scenario 3

PINX

other network

Scenario 4

PINX

other network

Scenario 5

PINX

other network

PINX

other network

Scenario 6

PINX

other network

Scenario 7

other network

PINX

other network

Scenario 8

other network

PINX

Scenario 9

other network

PINX

other network

PINX

Scenario 10

other network

PINX

Scenario 11

other network

PINX

- 29 -

Annex A ( in f o r ma tiv e )

Difference between Single Step Call Transfer and Call Transfer by Rerouting

The Single Step Call Transfer supplementary service is a service which enables a transferring user to replace an existing call with a transferred user by a new call between transferred user and transferred-to user whereby the transferring user does not have a call established with the transferred-to user prior to that single step call transfer. The single step call transfer executing entity which reroutes the transferred user to the transferred-to user is located in the call path between the transferring user and the transferred user. The Call Transfer by Rerouting supplementary service (ECMA-177, ECMA-178) is a service which enables a transferring user to transform two of that users calls into a new call between the transferred user and the transferredto user. The call transfer executing entity which reroutes the transferred user to the transferred-to user is prescribed to be the entity nearest to the transferred user.

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

+41 22 849.60.01 [email protected]

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

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

ECMA-299 — Private Integrated Services Network (PISN) - Specification, functional model and information flows - Single step call transfer supplementary service (SSCT-SD) (December 2001)

Related documents