Conceptio › Archive › ECMA International

ECMA Internationalopen access

ECMA-185 — Private Integrated Services Network (PISN) - Specification, functional model and information flows - Call completion supplementary services (CCSD) (June 1997)

ECMA International · ECMA International

ECMA International · Standards · License: Open Access

completion ecma ecmainternational flows information integrated model network

ecma, standard, ecma international, specification, ecma-185, ecma 185, 185, private, integrated, services, network, pisn, functional, model, and, information, flows, call, completion, supplementary, ccsd

Standard ECMA-185 2nd E dition - J une 1997

Standardizing

Information

and

Communication

Systems

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

P h o n e : + 4 1 2 2 8 4 9 . 6 0 . 0 0 - F a x : + 4 1 2 2 8 4 9 . 6 0 . 0 1 - U R L : h t t p : / / www. e c m a . c h - I n t e r n e t : h e l p d e s k @ e c m a . c h

Standard ECMA-185 2nd E dition - J une 1997

Standardizing

Information

and

Communication

Systems

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

P h o n e : + 4 1 2 2 8 4 9 . 6 0 . 0 0 - F a x : + 4 1 2 2 8 4 9 . 6 0 . 0 1 - U R L : h t t p : / / www. e c m a . c h - I n t e r n e t : h e l p d e s k @ e c m a . c h IW E-185ii.doc 14-08-97 09,24

Brief History

This Standard is one of a series of ECMA Standards defining services and signalling protocols applicable to Private Integrated Services Networks (PISNs). The series uses ISDN concepts as developed by ITU-T and conforms to the framework of International Standards for Open Systems Interconnection as defined by ISO/IEC. It has been produced under ITSTC work item M-IT-05 2.2.3 and under ETSI work items DE/ECMA-00007 and RE/ECMA-00129. This particular Standard specifies the Call Completion supplementary services: • Call Completion to Busy Subscriber (SS-CCBS) • Call Completion on No Reply (SS-CCNR). 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-185 (published by ECMA in December 1992), this 2nd Edition incorporates changes in order to achieve complete alignment with International Standard ISO/IEC 13866:1995(E) published by ISO/IEC in November 1995.

Adopted as 2nd Edition of Standard ECMA-185 by the General Assembly of June 1997.

- i -

Table of contents 1 Scope

2 Conformance

3 References (normative)

4 Definitions

4.1 External definitions

4.2 Other definitions

4.2.1 Additional network feature

4.2.2 Busy

4.2.3 Call, basic call

4.2.4 Call completion

4.2.5 Free

4.2.6 Path reservation

4.2.7 Recall timer

4.2.8 Retention timer

4.2.9 SS-CC recall

4.2.10 SS-CC service duration timer

4.2.11 User A

4.2.12 User B

5 Acronyms

6 SS-CCBS stage 1 specification

6.1 Description

6.1.1 General description

6.1.2 Qualifications on applicability to telecommunication services

6.2 Procedures

6.2.1 Provision/Withdrawal

6.2.2 Normal procedures

6.2.3 Exceptional Procedures

6.3 Interactions with other supplementary services

6.3.1 Calling Line Identification Presentation (SS-CLIP)

6.3.2 Connected Line Identification Presentation (SS-COLP)

6.3.3 Calling/Connected Line Identification Restriction (SS-CLIR)

6.3.4 Calling Name Identification Presentation (SS-CNIP)

6.3.5 Connected Name Identification Presentation (SS-CONP)

6.3.6 Calling/Connected Name Identification Restriction (SS-CNIR)

6.3.7 Completion of Calls on No Reply (SS-CCNR)

6.3.8 Call Transfer (SS-CT)

6.3.9 Call Forwarding Unconditional (SS-CFU)

6.3.10 Call Forwarding Busy (SS-CFB)

- ii -

6.3.11 Call Forwarding on No Reply (SS-CFNR)

6.3.12 Path Replacement (ANF-PR)

6.4 Interworking considerations

6.5 SS-CCBS overall SDL

7 SS-CCNR stage 1 description

7.1 Description

7.1.1 General description

7.1.2 Qualifications on applicability to telecommunication services

7.2 Procedures

7.2.1 Provision/Withdrawal

7.2.2 Normal Procedures

7.2.3 Exceptional procedures

7.3 Interaction with other supplementary services

7.3.1 Calling Line Identification Presentation (SS-CLIP)

7.3.2 Connected Line Identification Presentation (SS-COLP)

7.3.3 Calling/Connected Line Identification Restriction (SS-CLIR)

7.3.4 Calling Name Identification Presentation (SS-CNIP)

7.3.5 Connected Name Identification Presentation (SS-CONP)

7.3.6 Calling/Connected Name Identification Restriction (SS-CNIR)

7.3.7 Completion of Calls to Busy Subscribers (SS-CCBS)

7.3.8 Call Transfer (SS-CT)

7.3.9 Call Forwarding Unconditional (SS-CFU)

7.3.10 Call Forwarding Busy (SS-CFB)

7.3.11 Call Forwarding on No Reply (SS-CFNR)

7.3.12 Path Replacement (ANF-PR)

7.4 Interworking considerations

7.5 SS-CCNR Overall SDL

8 SS-CC stage 2 specification

8.1 Functional model

8.1.1 Functional model description

8.1.2 Description of the functional entities

8.1.3 Relationship to basic call functional model

8.2 Information flows

8.2.1 Definition of information flows

8.2.2 Relationship of information flows to Basic Call information flows

8.2.3 Examples of information flow sequences

8.3 Functional entity actions

8.3.1 Functional entity actions of FE1

8.3.2 Functional entity actions of FE2

8.3.3 Functional entity actions of FE3

8.3.4 Functional entity actions of FE4

- iii -

8.4 Functional entity Behaviour

8.4.1 Behaviour of FE1

8.4.2 Behaviour of FE2

8.4.3 Behaviour of FE3

8.4.4 Behaviour of FE4

8.5 Allocation of functional entities to physical locations

8.6 Interworking considerations

Annex A - Bibliography

- iv -

Scope This Standard, specifies supplementary services Call Completion (SS-CC), which are applicable to various basic services supported by Private Integrated Services Network (PISN). Basic services are specified in ECMA-142. SS-CC consists of two Supplementary services: the Completion of Calls to Busy Subscribers supplementary service (SS-CCBS) and the Completion of Calls on No Reply supplementary service (SS-CCNR). SS-CCBS allows completion of a call to a subscriber that was unsuccessful because of a busy condition and SS-CCNR allows completion of a call to a subscriber that was unsuccessful because the subscriber, although alerted, did not answer. Supplementary service specifications are produced in three stages, according to the method described in ETS 300 387. This Standard specifies the stage 1 and stage 2 specifications of SS-CC. The stage 1 specifications (clauses 6 and 7) specify the supplementary services as seen by the users of PISNs. The stage 2 specification (clause 8) specifies 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 the stage 1 and stage 2 clauses which are relevant to the interface or equipment to which the stage 3 standard applies. The stage 1 and stage 2 clauses which a stage 3 standard for the Completion of Calls to Busy Subscribers (CCBS) supplementary service shall support are clauses 6 and 8 respectively. The stage 1 and stage 2 clauses which a stage 3 standard for the Completion of Calls on No Reply (CCNR) supplementary service shall support are clauses 7 and 8 respectively.

References (normative) The following standards contain provisions which, through reference in this text, constitute provision 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-142

Private Integrated Services Network - Circuit-mode 64 kbit/s Bearer Services - Service Description, Functional Capabilities and Information Flows (International Standard ISO/IEC 11574)

ISO/IEC 11579-1

Information technology - Telecommunications and information exchange between systems Private Integrated Services Network - Part 1: Reference configuration for PISN Exchanges (PINX)

ETS 300 387

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

ITU-T Rec. I.112

Vocabulary of terms for ISDNs (1993)

ITU-T Rec. I.210

Principles of telecommunication services supported by an ISDN and the means to describe them (1993)

ITU-T Rec. I.221

Common specific characteristics of services (1993)

ITU-T Rec. Z.100

Specification and description language (1993)

- 2 -

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)

– Private Integrated Services Network (PISN)

(ISO/IEC 11579-1)

– Private Integrated Services Network Exchange (PINX)

(ISO/IEC 11579-1)

– 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 entity (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: – r1_setup request/indication/response/confirmation – r1_setup_reject request/indication – r1_report request/indication – r1_disconnect request/indication – r2_setup request/indication/response/confirmation – r2_report request/indication – r2_release request/indication – r3_setup request/indication/response/confirmation – r3_setup_reject request/indication – r3_report request/indication This Standard refers to the following basic call information flow elements defined in ECMA-142: – Connection Type (CT) – Destination Number (DN) – Destination Subaddress (DS) – Originating Number (ON) – Originating Subaddress (OS)

- 3 -

4.2

Other definitions

4.2.1

Additional network feature A capability, over and above that of a basic service, provided by a PISN, but not directly to a User.

4.2.2

Busy A property of a User for whom either a “network determined user busy” or “user determined user busy” condition (see clause 3.1 of ITU-T Rec. I.221) exists.

4.2.3

Call, basic call An instance of the use of a basic service.

4.2.4

Call completion The successful presentation of a previously unsuccessful Call to a destination user (User B) which occurs when the call has entered an alerting phase or has been answered.

4.2.5

Free A property of a User who can accept any attempt by the PISN to present a call to that User (i.e. allow the call to reach the alerting or answered state).

4.2.6

Path reservation The reservation of resources prior to SS-CC Recall in order that a connection path through the PISN is available when User A accepts the SS-CC Recall. NOTE Path Reservation does not guarantee that User B will be free when User A accepts the SS-CC Recall.

4.2.7

Recall timer This timer specifies the length of time the network shall wait for a response from user A to a CC Recall.

4.2.8

Retention timer This timer specifies the period of time the network retains the originating call information after a valid call attempt is released.

4.2.9

SS-CC recall An indication informing User A that User B is no longer busy (in the case of SS-CCBS) or has just completed a period of activity (in the case of SS-CCNR). Acceptance of this indication by User A will cause the call to be completed by the PISN.

4.2.10

SS-CC service duration timer This timer specifies the length of time that the service shall be active within the network.

4.2.11

User A The specific User that originated the call and requested the supplementary service.

4.2.12

User B The User that was initially addressed in the original call set up.

Acronyms ANF

Additional Network Feature

Call Control (functional entity)

CCA

Call Control Agent (functional entity)

CCBS

Completion of Calls to Busy Subscribers

CCI

Call Control Identifier

CCNR

Completion of Calls on No Reply

Call Completion De-registered

- 4 -

Cancellation Reason

Connection Type

Destination Number

Failure Cause

Functional Entity

FEA

Functional Entity Action

ISDN

Integrated Services Digital Network

Monitor Type

NDUB

Network Determined User Busy

Originating Number

PINX

Private Integrated Services Network Exchange

PISN

Private Integrated Services Network

Reject Cause

Request List

Request Maintained

RVC

Reservation Capability

SDL

Specification and Description Language

Status Indicator

SS-CC

Supplementary Service Call Completion

NOTE This is a generic term, used to describe aspects common to both SS-CCBS and SS-CCNR.

SS-CCBS

Supplementary Service Completion of Calls to Busy Subscribers

SS-CCNR

Supplementary Service Completion of Calls on No Reply

Terminal Equipment

UDUB

User Determined User Busy

SS-CCBS stage 1 specification

6.1 6.1.1

Description General description Completion of Calls to Busy Subscribers (SS-CCBS) is a supplementary service which is offered to a calling User A. On encountering a busy called User B, it allows User A to request that the PISN monitors User B and notifies User A when User B becomes free. On response by User A to that notification, the PISN shall attempt to complete the call to User B.

6.1.2

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

6.2 6.2.1

Procedures Provision/Withdrawal SS-CCBS may be provided after pre-arrangement with the service provider (by means of service profile control), or may be available generally to all Users. SS-CCBS may be withdrawn on request of the User or for administrative reasons.

- 5 -

The subscription parameters and values offered by a PISN shall be an implementation matter. A PISN may offer more or less parameters and values than those specified below. Possible subscription options are summarized in table 1. Table 1 - SS-CCBS Subscription parameters Subscription option Recall mode

Values: – SS-CC Recall offered to all compatible terminals (note) – SS-CC Recall offered to the terminal which has invoked SS-CCBS

NOTE If the user has more than one compatible terminal (e.g., passive bus arrangement), this option will result in SSCC Recall being offered simultaneously to all those terminals, thereby allowing acceptance by any one of those terminals. 6.2.2 6.2.2.1

Normal procedures Activation/deactivation/registration/Interrogation SS-CCBS is permanently activated. No information needs to be registered with the PISN for this supplementary service, and therefore interrogation is not applicable.

6.2.2.2

Invocation and operation When a call from User A fails because the destination User, User B, is busy, the PISN shall retain the call information provided by User A, as described in 9.2.1 of ECMA-142, for a period during which User A shall be able to request SS-CCBS. On receipt of a request for SS-CCBS during that period, the PISN shall check whether it is possible to initiate the service, and if so shall send an acknowledgment to User A, start monitoring User B and start the SS-CCBS Service Duration Timer. The acknowledgment means that User A can expect to receive a SS-CC Recall if User B becomes free within the period of the SS-CCBS Service Duration Timer. NOTE 1 The fact that User B is already being monitored, as a result of a call completion request from another user, need not cause rejection of the request from User A. The handling of multiple requests against the same User B is an implementation matter, typically involving some sort of queue arranged in chronological or priority order. NOTE 2 The fact that User A has already invoked call completion against another user need not cause rejection of any further requests for call completion from User A. The handling of multiple requests by the same User A is an implementation matter. NOTE 3 The period during which SS-CCBS can be invoked and the value of the SS-CCBS Service Duration timer are implementation specific. After the SS-CCBS request has been acknowledged, User A shall be able to receive and initiate other calls. A PISN may provide User A with the ability to request a list of outstanding SS-CC requests that User A has invoked. If the Recall mode is "SS-CC Recall offered to all compatible terminals", details of all requests made by that user should be provided. If the Recall mode is "SS-CC Recall offered to the terminal which has invoked SS-CCBS", only details of requests made by the user from that terminal should be provided. The list will be empty if there are no outstanding SS-CC requests. When the monitoring of User B indicates that User B has become free, and if User A is also free, the PISN shall provide SS-CC Recall, and start the SS-CC Recall timer.

- 6 -

If User A accepts the SS-CC Recall, the PISN shall attempt to complete the call between User A and User B. If the call is successfully presented to User B and enters an alerting phase or is answered, SS-CCBS shall be regarded as complete. 6.2.2.3

Cancellation The PISN shall provide User A with the ability to request cancellation of at least one of the following: − all outstanding SS-CC requests for which a SS-CC Recall is still expected; − the most recent SS-CC request for which a SS-CC Recall is still expected; and, − a specific SS-CC request for which a SS-CC Recall is still expected. If the Recall mode is "SS-CC Recall offered to all compatible terminals", requests made by that user should be cancelable. If the Recall mode is "SS-CC Recall offered to the terminal which has activated SS-CCBS", requests made by the user from that terminal should be cancellable. User A shall be informed of successful cancellation.

6.2.3

Exceptional Procedures

6.2.3.1

Activation/deactivation/registration/interrogation Not applicable.

6.2.3.2 6.2.3.2.1

Invocation and Operation Rejection of SS-CCBS Service request If User A is not permitted to request SS-CCBS, the PISN shall reject the SS-CCBS request with an indication of whether denial is short or long term. Short term denial shall be used for temporary conditions where a later request for SS-CCBS might be successful. Examples of conditions that may result in a short term denial are: − limit of requests by User A already reached; − no call information retained; − limit of requests against User B already reached; or, − duplicate request (see 6.2.3.2.5), Long term denial shall be used when later requests will also be rejected. Examples of a conditions that may result in a long term denial are: − SS-CCBS not provided to User A; or, − interworking with a network which does not support SS-CCBS; − SS-CCBS not allowed against User B (note). NOTE This is an implementation option that can apply to certain classes of users.

6.2.3.2.2

User A is busy on SS-CC recall If User A is found to be busy when User B becomes free, the PISN shall wait for both Users to become free before providing SS-CC Recall and starting the SS-CC Recall timer. As an option, the PISN can notify User A that the PISN is attempting to complete a call. NOTE On receipt of such a notification, User A can either:

− ignore the notification, thereby causing the SS-CC Recall to be delayed; − cancel the SS-CCBS request; or, − free resources by disposing of an existing call, thereby allowing the SS-CC Recall to proceed.

- 7 -

6.2.3.2.3

Network congestion If path reservation is used by the PISN, network congestion can delay the SS-CC Recall, which will not occur until a path has been reserved and both Users are free. If the PISN does not use path reservation, or interworks with a network which does not allow path reservation, the call completion attempt can fail after User A has accepted the SS-CC Recall because of network congestion. In this case, User A shall be informed of the failure and whether the SS-CCBS request has been maintained by the PISN and a further SS-CC Recall can be expected. NOTE Alternative (implementation specific) procedures can also be provided, but are beyond the scope of this Standard.

6.2.3.2.4

User B becomes busy after successful SS-CC recall If User B is busy for the call resulting from a successful SS-CC Recall of User A, the PISN shall either: − abandon SS-CCBS and release reserved path if path reservation has been performed, indicating the reason for the failure to User A and that the SS-CCBS request has been canceled. In such a case the PISN may allow User A, as an implementation option, the option to re-invoke SS- CCBS if call completion to User B is still required; or, NOTE The method used in the PISN to allow User A to re-invoke SS-CCBS is outside the scope of this Standard. − resume monitoring of User B, indicating the reason for the failure to User A and that the SS-CCBS request has been maintained. In such a case, User A may, as a User option, request cancellation of the SS-CCBS request, if call completion to User B is no longer required. As a PISN option, if User B makes an outgoing call after SS-CC Recall has been started, but before User A has accepted the SS-CC Recall, then User B may be notified that the PISN is attempting to complete a call. NOTE This gives User B the opportunity to abandon call initiation in order to allow the SS-CCBS call to complete.

6.2.3.2.5

User B becomes busy during path reservation If user B is found to be busy when path reservation is performed, the path shall be released and the PISN shall wait for User B to become not busy before reattempting path reservation.

6.2.3.2.6

Duplicate SS-CCBS requests If User A has already requested SS-CCBS on User B for a particular Basic service, and is awaiting recall, any subsequent request from User A to invoke SS-CCBS on User B, for the same Basic service, shall cause the PISN to either: − reject the request as a duplicate request; or, − accept the request as valid. NOTE In the case that the PISN accepts the duplicate SS-CCBS request, User A can receive one or more SS-CC Recalls dependent on the treatment of the duplicate request by the PISN.

6.2.3.2.7

Other failure situations A particular request for the service shall be automatically canceled by the PISN, and User A shall be notified if: − User B and/or User A is still busy after the SS-CCBS Service Duration Timer expires; − User A does not accept the SS-CC Recall before the SS-CC Recall timer expires; − User B invokes or activates a service that conflicts with the existing SS-CCBS invocation;

- 8 -

− for any reason , the PISN is unable to continue with the CCBS invocation. 6.2.3.3

Cancellation A cancellation request shall be rejected if there are no SS-CC requests for User A or if the request is to cancel a specific SS-CC request which does not exist.

6.3

Interactions with other supplementary services Interactions with other supplementary services and ANFs for which PISN standards were available at the time of publication of this Standard are specified below. NOTE Annex A anticipates interactions with future supplementary services and ANFs.

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

Calling/Connected Line Identification Restriction (SS-CLIR) If User A requests override of the SS-CLIR default value for a call, and the call encounters a busy User B, the request to override the default value shall be retained by the network and shall apply to a call resulting from the use of SS-CCBS.

6.3.4

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

6.3.5

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

6.3.6

Calling/Connected Name Identification Restriction (SS-CNIR) If User A requests override of the SS-CNIR default value for a call, and the call encounters a busy User B, the request to override the default value shall be retained by the network and shall apply to a call resulting from the use of SS-CCBS.

6.3.7

Completion of Calls on No Reply (SS-CCNR) If User A has SS-CCNR activated on User B, and User A requests SS-CCBS on User B, this request shall be treated as a duplicate SS-CCBS request in accordance with 6.2.3.2.5. NOTE When User B is busy (the pre-requisite for invocation of SS-CCBS by User A) before SS-CC Recall has been started relating to a previous SS-CCNR request, the pending SS-CCNR request has effectively become an SSCCBS request, as it is awaiting a free User B in order to recall User A. If an SS-CCBS request is then received from User A, relating to User B, this is therefore effectively a duplicate SS-CCBS request and is treated as such by the PISN.

6.3.8

Call Transfer (SS-CT) No interaction.

6.3.9

Call Forwarding Unconditional (SS-CFU) a) SS-CFU activated by user B before user A requests SS-CCBS If the call to User B is diverted to User C by SS-CFU and User C is busy, then a SS-CCBS request from User A shall be applied to the diverted-to User C. b) SS-CFU activated by user B after user A requests SS-CCBS If User B activates SS-CFU after User A has requested SS-CCBS and whilst the SS-CC Recall has not yet been accepted by User A, the SS-CCBS request shall either continue to be applied to User B or be canceled.

- 9 -

c) SS-CFU activation by user A If User A invokes SS-CCBS whilst SS-CFU is activated, or User A invokes SS-CCBS and subsequently activates SS-CFU, SS-CC Recall shall still be given to User A. 6.3.10

Call Forwarding Busy (SS-CFB) a) SS-CFB activated by user B before user A requests SS-CCBS If the call from User A to User B is diverted to User C by SS-CFB and User C is busy, then a SS-CCBS request made by User A shall be applied either to the diverted-to User C or to the originally called User B. b) SS-CFB activated by user B after user A requests SS-CCBS If User B activates SS-CFB after User A has requested SS-CCBS and whilst the SS-CC Recall has not yet been accepted by User A, the SS-CCBS request shall continue to be applied to User B. c) SS-CFB activation by user A If User A invokes SS-CCBS whilst SS-CFB is activated, or User A invokes SS-CCBS and subsequently activates SS-CFB, this shall not affect the provision of the SS-CC Recall to User A.

6.3.11

Call Forwarding on No Reply (SS-CFNR) If User B activates SS-CFNR after User A has requested SS-CCBS and whilst the SS-CC Recall has not yet been accepted by User A, then the SS-CCBS request shall continue to be applied to User B. NOTE In such a case, the call resulting from successful completion of SS-CCBS can be subject to SS-CFNR if not answered. If User A invokes SS-CCBS whilst SS-CFNR is activated, or User A invokes SS-CCBS and subsequently activates SS-CFNR, this shall not affect the provision of the SS-CC Recall to User A.

6.3.12

Path Replacement (ANF-PR) No interaction.

6.4

Interworking considerations Where Users A and B are on a different network, the availability of SS-CCBS to User A will be limited by the capabilities of the other network and the interworking functions between the PISN and the other network. If User B is connected to a public ISDN and the public ISDN version of the SS-CCBS service is available at the network interworking point, User A shall be able to request SS-CCBS on public ISDN User B. In addition, a User A served by the Public ISDN shall be able to request SS-CCBS on a PISN User B. NOTE This assumes peer cooperation between the public and private ISDN in provision of the SS-CCBS service

6.5

SS-CCBS overall SDL Figure 1 contains the dynamic description of SS-CCBS using the Specification and Description Language (SDL) defined in ITU-T Rec. Z.100. The SDL process represents the behaviour of the network in providing SS-CCBS. The relationship of this process to the basic call process is indicated in the annotations. Input signals from the left and output signals to the left represent primitives from and to User A. Input signals from the right represent internal stimuli.

- 10 -

idle CCBS request

CCBS ?

YES

internal failure of SS-CC

Service dur. timer expiry

Request maintained ?

cancel SS-CC req.

awaiting free User B

SS-CC failed req. not maintnd

CCBS Confirm

Long Term Denial

awaiting free User B

SHORT

Short Term Denial

idle

User B free

User A free ?

NO SS-CC failed req. maintnd

Short or long term ?

LONG

available

YES

start service dur. timer

SS-CC cancelled

awaiting free

YES

User A

User A free stop service dur. timer cancel SSCC request

idle

YES NO

Path reservation possible ?

Service dur. timer expiry

cancel

YES

idle

User B still free ?

SS-CC req.

awaiting free User B

SS-CC cancelled

Initiate path reservation

any SS-CC state

cancel request

reservation failure

reservation successful

cancel SS-CC request stop service dur. timer

cancellation successful

idle

pending path reservation

Path res still possible ?

stop service dur. timer

cancel SS-CC req.

SS-CC recall request

stop service dur. timer

start timer CC-Recall

SS-CC failed req. not maintnd

pending recall

idle

YES

Initiate path reservation pending path reservation

Figure 1 - SS-CCBS, Overall SDL (sheet 1 of 2)

Service dur. timer expiry cancel SS-CC req. SS-CC cancelled

idle

- 11 -

pending recall

This applies only to non-reservation

Network congestion

SS-CC recall accept

SS-CC recall reject

Stop timer CC-Recall

complete call to user B

cancel SS-CC req.

call completion pending

idle

Call completed

User B busy

Expiry timer CC-Recall

Note

Call completed re-register SS-CC req.

cancel SS-CC req.

SS-CC failed req. maintnd start servc. duration timer awaiting free User B

cancel SS-CC req.

re-register SS-CC req.

SS-CC failed req. not maintnd

SS-CC failed req. maintnd

idle

start servc. duration timer

idle

awaiting free User B

NOTE These notifications may be the same as the basic call notification of call completion and need not be specific to SSCCBS. Figure 1 - SS-CCBS, Overall SDL (sheet 2 of 2)

- 12 -

SS-CCNR stage 1 description

7.1

Description

7.1.1

General description Completion of Calls on No Reply (SS-CCNR) is a supplementary service which is offered to a calling User A. On encountering a called User B which does not answer, it allows User A to request that the PISN monitors User B and notifies User A when User B becomes free after a subsequent period of activity. On response by User A to that notification, the PISN shall attempt to complete the call to User B. NOTE User activities that constitute a subsequent period of activity are implementation specific and beyond the scope of this Standard.

7.1.2

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

7.2

Procedures

7.2.1

Provision/Withdrawal SS-CCNR may be provided after pre-arrangement with the service provider (by means of service profile control), or may be available generally to all Users. SS-CCNR may be withdrawn on request of the User or for administrative reasons. The subscription parameters and values offered by a PISN shall be an implementation matter. A PISN may offer more or less parameters and values than those specified below. Possible subscription options are summarised in table 2, which shall apply to the whole access of the served user. Table 2 - SS-CCNR Subscription parameters Subscription option Recall mode

Values: − SS-CC Recall offered to all compatible terminals − SS-CC Recall offered to the terminal which has activated SS-CCNR

7.2.2 7.2.2.1

Normal Procedures Activation/deactivation/registration/interrogation Sub-clause 6.2.2.1 shall apply, with the exception that 'SS-CCBS' shall be replaced by 'SS-CCNR'.

7.2.2.2

Invocation and operation When a call from User A fails because the destination User, User B, does not answer, the PISN shall retain the call information provided by User A, as described in 9.2.1 of ECMA-142, for a period during which User A shall be able to request SS-CCNR. User A shall also be able to request SS-CCNR whilst User B is alerting. On receipt of a request for SS-CCNR, the PISN shall check whether it is possible to initiate the service, and if so shall send an acknowledgment to User A, start monitoring User B and start the SS-CCNR Service Duration Timer. The acknowledgment means that User A can expect to receive a SS-CC Recall if User B becomes free, after a subsequent period of activity, within the period of the SS-CCNR Service Duration Timer. NOTE 1 The fact that User B is already being monitored, as a result of a call completion request from another user, need not cause rejection of the request from User A. The handling of multiple requests against the same User B is an implementation matter, typically involving some sort of queue arranged in chronological or priority order.

- 13 -

NOTE 2 The fact that User A has already invoked call completion against another user need not cause rejection of any further requests for call completion from User A. The handling of multiple requests by the same User A is an implementation matter. NOTE 3 The period during which SS-CCNR can be invoked and the value of the SS-CCNR Duration timer are implementation specific. After the SS-CCNR request has been acknowledged, User A shall be able to receive and initiate other calls. A PISN may provide User A with the ability to request a list of outstanding SS-CC requests that User A has invoked. If the Recall mode is "SS-CC Recall offered to all compatible terminals", details of all requests made by that user should be provided. If the Recall mode is "SS-CC Recall offered to the terminal which has activated SS-CCNR", only details of requests made by the user from that terminal should be provided. The list will be empty if there are no outstanding SS-CC requests. When the monitoring of User B indicates that User B has become free after a period of activity (related to the same basic service as the original call to User B), and if User A is also free, the PISN shall provide SS-CC Recall, and start the SS-CC Recall timer. If User A accepts the SS-CC Recall, the PISN shall attempt to complete the call between User A and User B. If the call is successfully presented to User B and enters an alerting phase or is answered, SS-CCNR shall be regarded as complete. 7.2.2.3

Cancellation Sub-clause 6.2.2.3 shall apply, with the exception that 'SS-CCBS' shall be replaced by 'SS-CCNR'.

7.2.3

Exceptional procedures

7.2.3.1

Activation/deactivation/registration and Interrogation Not applicable.

7.2.3.2 7.2.3.2.1

Invocation and operation Rejection of SS-CCNR service request Sub-clause 6.2.3.2.1 shall apply, with the exception that 'SS-CCBS' shall be replaced by 'SS-CCNR'.

7.2.3.2.2

User A is busy on SS-CC recall If User A is found to be busy when User B becomes free after a period of activity, the PISN shall wait for both Users to become free before providing SS-CC Recall and starting the SS-CC Recall timer. As an option, the PISN can notify User A that the PISN is attempting to complete a call. NOTE On receipt of such a notification, User A can either: − ignore the notification, thereby causing the SS-CC Recall to be delayed; − cancel the SS-CCNR request; or, − free resources by disposing of an existing call, thereby allowing the SS-CC Recall to proceed.

7.2.3.2.3

Network congestion Sub-clause 6.2.3.2.3 shall apply, with the exception that 'SS-CCBS' shall be replaced by 'SS-CCNR.

7.2.3.2.4

User B becomes busy after successful SS-CC recall If User B is busy for the call resulting from a successful SS-CC Recall of User A, the PISN shall either: − abandon SS-CCNR indicating the reason for the failure to User A and that the SS- CCNR request has been cancelled. In such a case, User A may, as a User option, invoke SS-CCBS if call completion to User B is still required; or, − automatically invoke SS-CCBS monitoring of User B, indicating the reason for the failure to User A and that SS-CCBS has been invoked. In such a case, User A may, as a User option, request cancellation of the SS- CCBS request, if call completion to User B is no longer required.

- 14 -

As a PISN option, if User B makes an outgoing call after SS-CC Recall has been started, but before User A has accepted the SS-CC Recall, then User B may be notified that the PISN is attempting to complete a call. NOTE This gives User B the opportunity to abandon call initiation in order to allow the SS-CCBS call to complete. 7.2.3.2.5

7.2.3.2.6

Duplicate SS-CCNR requests Sub-clause 6.2.3.2.5 shall apply, with the exception that 'SS-CCBS' shall be replaced by 'SS-CCNR'

7.2.3.2.7

Other failure situations A particular request for the service shall be automatically cancelled by the PISN, and User A shall be notified if: − User B has still had no period of activity before the SS-CCNR Service Duration Timer expires; − User B and/or User A are still busy (after a period of activity by User B) when the SS-CCNR Service Duration Timer expires; − User A does not accept the SS-CC Recall before the SS-CC Recall timer expires; − User B invokes or activates a service that conflicts with the existing SS-CCNR invocation; − for any reason, the PISN is unable to continue with the CCNR invocation.

7.2.3.3

Cancellation Sub-clause 6.2.3.3 shall apply, with the exception that 'SS-CCBS' shall be replaced by 'SS-CCNR'.

7.3

Interaction with other supplementary services Interactions with other supplementary services and ANFs for which PISN standards were available at the time of publication of this Standard are specified below. NOTE Annex A anticipates interactions with future supplementary services and ANFs.

7.3.1

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

7.3.2

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

7.3.3

Calling/Connected Line Identification Restriction (SS-CLIR) If User A requests override of the SS-CLIR default value for a call, and the call is not answered by User B, the request to override the default value shall be retained by the network and shall apply to a call resulting from the use of SS-CCNR.

7.3.4

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

7.3.5

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

7.3.6

Calling/Connected Name Identification Restriction (SS-CNIR) If User A requests override of the SS-CNIR default value for a call, and the call is not answered by User B, the request to override the default value shall be retained by the network and shall apply to a call resulting from the use of SS-CCNR.

- 15 -

7.3.7

Completion of Calls to Busy Subscribers (SS-CCBS) Sub-clause 6.3.12 shall apply.

7.3.8

Call Transfer (SS-CT) No interaction.

7.3.9

Call Forwarding Unconditional (SS-CFU) a) SS-CFU activated by user B before user A requests SS-CCNR If the call to User B is diverted to User C by SS-CFU and User C does not answer, then a SS-CCNR request from User A shall be applied to the diverted-to User C. b) SS-CFU activated by user B after user A requests SS-CCNR If User B activates SS-CFU after User A has requested SS-CCNR and whilst the SS-CC Recall has not yet been accepted by User A, the SS-CCNR request shall either continue to be applied to User B or be cancelled. c) SS-CFU activation by user A If User A invokes SS-CCNR whilst SS-CFU is activated, or User A invokes SS-CCNR and subsequently activates SS-CFU, SS-CC Recall shall still be given to User A.

7.3.10

Call Forwarding Busy (SS-CFB) a) SS-CFB activated by user B before user A requests SS-CCNR If the call from User A to User B is diverted to User C by SS-CFB and C does not answer, then a SS-CCNR request made shall be applied to the diverted-to User C. b) SS-CFB activated by user B after user A requests SS-CCNR If User B activates SS-CFB after User A has requested SS-CCNR and whilst the SS-CC Recall has not yet been accepted by User A, the SS-CCNR request shall continue to be applied to User B. c) SS-CFB activation by user A If User A invokes SS-CCNR whilst SS-CFB is invoked, or User A invokes SS-CCNR and subsequently invokes SS-CFB, this shall not affect the provision of the SS-CC Recall to User A.

7.3.11

Call Forwarding on No Reply (SS-CFNR) If the call to User B is diverted to User C by SS-CFNR and User C does not answer, then a SS-CCNR request from User A shall be applied to either User B or to User C. If User B activates SS-CFNR after User A has requested SS-CCNR and whilst the SS-CC Recall has not yet been accepted by User A, the SS-CCNR request is not affected. If User A invokes SS-CCNR whilst SS-CFNR is activated, or User A invokes SS-CCNR and subsequently activates SS-CFNR, this shall not affect the provision of the SS-CC Recall to User A.

7.3.12

Path Replacement (ANF-PR) No interaction.

7.4

Interworking considerations Where User B is on a different network, the availability of SS-CCNR to User A will be limited by the capabilities of the other network and the interworking functions between the PISN and the other network. If User B is connected to a public ISDN and the public ISDN version of SS-CCNR is available at the network interworking point, User A shall be able to request SS-CCNR on public ISDN User B. In addition, a User A served by the Public ISDN shall be able to request SS-CCNR on a PISN User B. NOTE This assumes peer cooperation between the public and private ISDN in provision of SS-CCNR.

- 16 -

7.5

SS-CCNR Overall SDL Figure 2 contains the dynamic description of SS-CCNR using the Specification and Description Language (SDL) defined in ITU-T Rec. Z.100. The SDL process represents the behaviour of the network in providing SS-CCNR. It is presented as the procedure and state requirements for SS-CCNR that are additional to those for SS-CCBS, as shown in figure 1. The relationship of this process to the basic call process is indicated in the annotations. Input signals from the left and output signals to the left represent primitives from and to User A. Input signals from the right represent internal stimuli.

idle CCNR request CCNR available ? YES

start service dur. timer CCNR Confirm

Short or long term ? LONG Long Term Denial

SHORT

Short Term Denial

awaiting activity at User B internal failure of SS-CC

activity at User B

idle Service dur. timer expiry

YES

Request maintained ?

SS-CC failed req. maintnd

stop service dur. timer

cancel SS-CC req.

awaiting activity at User B

SS-CC failed req. not maintnd

idle

awaiting free User B

SS-CC cancelled

idle

Figure 2 - Additions to SS-CCBS overall SDL for SS-CCNR

- 17 -

SS-CC stage 2 specification

8.1

Functional model

8.1.1

Functional model description The functional model shall comprise the following functional entities (FEs): FE1

Originating SS-CC Agent FE

FE2

Originating SS-CC Controlling FE

FE3

Terminating SS-CC Controlling FE

FE4

Terminating SS-CC Agent FE

The following functional relationships shall exist between these FEs: ra

between FE1 and FE2,

between FE2 and FE3,

between FE3 and FE4.

Figure 3 shows these FEs and relationships. ra

FE1

FE2

FE3

FE4

Figure 3 - Functional model for SS-CC 8.1.2 8.1.2.1

Description of the functional entities Originating SS-CC agent FE, FE1 The FE that serves the User that wishes to invoke either of the call completion services (SS-CCBS or SSCCNR).

8.1.2.2

Originating SS-CC controlling FE, FE2 The FE within the network which co-operates with its peer (FE3) to provide the PISN call completion supplementary service as requested by FE1.

8.1.2.3

Terminating SS-CC controlling FE, FE3 The FE within the network which co-operates with its peer (FE2) to provide the PISN call completion supplementary service as requested by FE1. It also interacts with FE4 to provide the monitoring information that is required for the successful operation of the call completion services.

8.1.2.4

Terminating SS-CC agent FE, FE4 The FE that serves the monitored User (B).

8.1.3

Relationship to basic call functional model An example of a relationship between the FEs for SS-CC and FEs for the basic call is shown in figure 4.

r1 CCA

FE3

FE2

FE1

r2 CC

FE4

r3 CC

CCA

Figure 4 - Example Relationship between model for SS-CC and Basic Call

- 18 -

8.2

Information flows

8.2.1 8.2.1.1

Definition of information flows ra_CC_cancellation_access ra_CC_cancellation_access is a confirmed information flow across ra from FE1 to FE2 which cancels the SSCC service. Table 3 lists the service elements within the ra_CC_cancellation_access information flow. The column headed "Request" indicates which of these elements are mandatory (M) and which are optional (O) in a ra_CC_cancellation_access request/indication information flow. The column headed "Confirm" indicates which of these service elements are mandatory (M) and which are optional (O) in a ra_CC_cancellation_access response/confirmation information flow. Table 3 - Information content of ra_CC_cancellation_access Service Element

Request

Confirm

CC Identifier (CCI)

Reject Cause (RC)

M (note)

NOTE This service element shall be included when the cancellation of SS-CC cannot be performed and shall indicate the reason for failure. Examples of the reasons that cancellation may not be possible are:

− SS-CC request does not exist; or, − no invoked SS-CC requests exist. 8.2.1.2

ra_CC_cancelled ra_CC_cancelled is an unconfirmed information flow across ra from FE2 to FE1 which indicates that the SSCC service has been cancelled. Table 4 lists the service elements within the ra_CC_cancelled information flow. The column headed "Request" indicates which of these service elements are mandatory (M) and which are optional (O) in a ra_CC_cancelled request/indication information flow. Table 4 - Information content of ra_CC_cancelled Service Element

Request

Cancellation Reason (CR)

CC Identifier (CCI)

Connection Type (CT)

O (note 1)

Originating Number (ON)

O (note 2)

Originating Subaddress (OS)

NOTE 1 This service element shall only be sent when the recall mode is SS-CC recall offered to all compatible terminals. NOTE 2 This service element shall be included where there is more than one PISN number associated with User A's access. 8.2.1.3

ra_CC_failed ra_CC_failed is an unconfirmed information flow across ra from FE2 to FE1 informing User A that the SS-CC service has failed, subsequent to successful recall of User A.

- 19 -

Table 5 lists the service elements within the ra_CC_failed information flow. The column headed "Request" indicates which of these service elements are mandatory (M) and which are optional (O) in a ra_CC_failed request/indication information flow. Table 5 - Information content of ra_CC_failed Service Element

Request

Failure Cause (FC)

M (note 1)

Request Maintained (RM)

O (note 2)

NOTE 1 This service element shall indicate the reason for failure of SS-CC. Examples of reasons for failure are: – User B busy again, or – Network Congestion. NOTE 2 This service element shall be included when the SS-CC request has been maintained by the PISN subsequent to the failure of the original completion attempt. 8.2.1.4

ra_CC_list ra_CC_list is a confirmed information flow across ra from FE1 to FE2 which requests a ‘list’ of all outstanding SS-CC requests that user A has invoked. The response contains a list of those requests invoked by User A. Table 6 lists the service elements within the ra_CC_list information flow. The column headed "Request" indicates which of these service elements are mandatory (M) and which are optional (O) in a ra_CC_list request/indication information flow. The column headed "Confirm" indicates which of these service elements are mandatory (M) and which are optional (O) in a ra_CC_list response/confirmation information flow. Table 6 - Information content of ra_CC_list Service Element

Request

Confirm

O (note 1)

Reject Cause (RC)

O (note 2)

Request List (RL)

O (note 3)

CC Identifier (CCI) Originating Number (ON)

NOTE 1 This service element shall be included where there is more than one PISN number associated with User A's access, otherwise it shall be omitted. NOTE 2 This service element shall be included if the CC_list confirm/response indicates rejection and indicate the reason for rejection, otherwise it shall be omitted. NOTE 3 This service element shall be included if the CC_list confirm/response indicates success and shall include a list of PISN numbers on which User A has invoked SS-CC, otherwise it shall not be included. In the case of recall offered to all compatible terminals the corresponding CC Identifiers shall be included together with information to enable terminals to decide whether they are compatible. 8.2.1.5

ra_CC_recall_accepted ra_CC_recall_accepted is an unconfirmed information flow across ra from FE1 to FE2 in order to indicate that User A has accepted the SS-CC Recall and wishes to complete the original call to User B.

- 20 -

Table 7 lists the service elements within the ra_CC_recall_accepted information flow. The column headed "Request" indicates which of these service elements are mandatory (M) and which are optional (O) in a ra_CC_recall_accepted request/indication information flow. Table 7 - Information content of ra_CC_recall_accepted Service Element

Request

CC Identifier (CCI) 8.2.1.6

ra_CC_rem_user_free ra_CC_rem_user_free is an unconfirmed information flow across ra from FE2 to FE1 indicating that User B is not busy and instructing FE1 to recall User A. Table 8 lists the service elements within the ra_CC_rem_user_free information flow. The column headed "Request" indicates which of these service elements are mandatory (M) and which are optional (O) in a ra_CC_rem_user_free request/indication information flow. Table 8 - Information content of ra_CC_rem_user_free Service Element

Request

CC Identifier (CCI)

Connection Type (CT)

Destination Number (DN)

Destination Subaddress (DS)

Originating Number (ON)

O (note)

Originating Subaddress (OS)

NOTE This service element shall be included where there is more than one PISN number associated with User A's access. 8.2.1.7

ra_CC_request ra_CC_request is a confirmed information flow across ra from FE1 to FE2 which invokes the SS-CC service. The response indicates whether the request to invoke SS-CC has been accepted or rejected. It also indicates the reason if the response indicates rejection. Table 9 lists the service elements within the ra_CC_request information flow. The column headed "Request" indicates which of these service elements are mandatory (M) and which are optional (O) in a ra_CC_request request/indication information flow. The column headed "Confirm" indicates which of these service elements are mandatory (M) and which are optional (O) in a ra_CC_request response/confirmation information flow. Table 9 - Information content of ra_CC_request Service Element

Request

Confirm

CC Identifier (CCI)

Recall Mode (RM)

Reject Cause (RC)

O (note)

- 21 -

NOTE This service element shall be included if the CC_request cannot be accepted. Examples of possible error conditions are as follows:

− − − − − 8.2.1.8

limit of requests reached locally (User A) limit of requests reached remotely (User B) duplicate invocation SS-CC not provided interworking with a network that does not support SS-CC.

ra_CC_status_req ra_CC_status_req is a confirmed information flow across ra from FE2 to FE1 which ascertains the status of User A. The confirmation indicates whether User A is busy or free. Table 10 lists the service elements within the ra_CC_status_req information flow. The column headed "Request" indicates which of these service elements are mandatory (M) and which are optional (O) in a ra_CC_status_req request/indication information flow. The column headed "Confirm" indicates which of these service elements are mandatory (M) and which are optional (O) in a ra_CC_status_req response/confirmation information flow. Table 10 - Information content of ra_CC_status_req Service Element

Request

Confirm

CC Identifier (CCI)

O (note 1)

Connection Type (CT)

O (note 2)

Originating Number (ON)

O (note 3)

Originating Subaddress (OS)

Status Indicator (SI)

M (note 4)

NOTE 1 CCI shall be sent in the case of specific recall. NOTE 2 CT shall only be sent when the subscription option "SS-CC Recall offered to all compatible terminals" is subscribed to. NOTE 3 ON shall be included where there is more than one PISN number associated with User A's access. NOTE 4 This service element shall indicate either: – busy, or – free. 8.2.1.9

ra_CC_stop_recall ra_CC_stop_recall is an unconfirmed flow across ra from FE2 to FE1 in order to inform FE1 that another FE1 has accepted the recall. This applies in the case where SS-CC recall is offered to all compatible terminals. Table 11 lists the service elements within the ra_CC_stop_recall information flow. Table 11 - Information content of ra_CC_stop_recall Service Element CC identifier (CCI)

Request M

- 22 -

8.2.1.10

ra_CC_user_B_free ra_CC_user_B_free is an unconfirmed information flow across ra from FE2 to FE1 in order to inform User A, when User A is known to be busy, that User B is now free. Table 12 lists the service elements within the ra_CC_user_B_free information flow. The column headed "Request" indicates which of these service elements are mandatory (M) and which are optional (O) in a ra_CC_user_B_free request/indication information flow. Table 12 - Information content of ra_CC_user_B_free Service Element

Request

CC Identifier (CCI)

Connection Type (CT)

Destination Number (DN)

Destination Subaddress (DS)

Originating Number (ON)

O (note)

Originating Subaddress (OS)

NOTE This service element shall be included where there is more than one PISN number associated with User A's access. 8.2.1.11

rb_CC_call rb_CC_call is an unconfirmed information flow across rb from FE2 to FE3 which initiates offering of the completed call to User B. If Path reservation has not been performed, it also cancels the SS-CC service. There are no service elements in this information flow.

8.2.1.12

rb_CC_call_reject rb_CC_call_reject is an unconfirmed information flow across rb from FE3 to FE2 which indicates that offering of the completed call to User B has been unsuccessful. Table 13 lists the service elements within the rb_CC_call_reject information flow. The column headed "Request" indicates which of these service elements are mandatory (M) and which are optional (O) in a rb_CC_call_reject request/indication information flow. Table 13 - Information content of rb_CC_call_reject Service Element Reject Cause (RC)

Request M (note)

NOTE This service element shall indicate the reason for failure. An example of a reason is: User B busy. 8.2.1.13

rb_CC_cancellation rb_CC_cancellation is an unconfirmed information flow across rb from FE2 to FE3 or across rb from FE3 to FE2 which cancels the SS-CC service. There are no service elements in this information flow.

8.2.1.14

rb_CC_free_notification rb_CC_free_notification is an unconfirmed information flow across rb from FE3 to FE2 informing FE2 that User B is now free. There are no service elements in this information flow.

- 23 -

8.2.1.15

rb_CC_monitor rb_CC_monitor is a confirmed information flow across rb from FE2 to FE3 which initiates monitoring at FE3 or re-initiates monitoring in the case where a SS-CC request has failed (e.g. User B busy) and the PISN provides automatic re-registration of the SS-CC service. The response indicates whether or not FE3 has successfully initiated monitoring of User B. Table 14 lists the service elements within the rb_CC_monitor information flow. The column headed "Request" indicates which of these service elements are mandatory (M) and which are optional (O) in a rb_CC_monitor request/indication information flow. The column headed "Confirm" indicates which of these service elements are mandatory (M) and which are optional (O) in a CC_monitor response/confirmation information flow. Table 14 - Information content of rb_CC_monitor Service Element

Request

Confirm

Connection Type (CT)

Destination Number (DN)

Destination Subaddress

Monitor Type (MT)

M (note 1)

Originating Number (ON)

Originating Subaddress

Reject Cause (RC)

O (note 2)

Reservation Capability (RVC)

O (note 3)

Retain Capability

O (note 4)

NOTE 1 This service element shall indicate either: – Monitor for free User B, or – Monitor for free User B after period of activity. NOTE 2 This service element shall be included if the rb_CC_monitor request/indication cannot be accepted. Examples of reasons for rejection are: – limit of requests reached – SS-CC not provided, or – duplicate invocation. NOTE 3 This service element may be included and shall indicate whether or not path reservation is supported by FE3 in order to allow FE2 to decide whether to invoke path reservation or not. If this element is not contained in the rb_CC_monitor request/response received by FE2, an attempt to initiate path reservation may still fail because FE3 does not support path reservation. NOTE 4 This service element may be included if the rb_CC_monitor request received by FE3 contained the RC Retain Capabilityservice element, otherwise the element shall be omitted. 8.2.1.16

rb_CC_path_reserve rb_CC_path_reserve is a confirmed information flow across rb from FE2 to FE3 which reserves a network connection for the completed call. The response indicates whether or not the reservation was successful. This information flow shall be sent if the path reservation version of SS-CC is provided, otherwise is not required.

- 24 -

Table 15 lists the service elements within the rb_CC_path_reserve information flow. The column headed "Request" indicates which of these service elements are mandatory (M) and which are optional (O) in a rb_CC_path_reserve request/indication information flow. The column headed "Confirm" indicates which of these service elements are mandatory (M) and which are optional (O) in a rb_CC_path_reserve response/confirmation information flow. Table 15 - Information content of rb_CC_path_reserve Service Element

Request

Confirm

O (note)

Reject Cause (RC) NOTE

This service element shall be included if FE3 rejects the rb_CC_path_reserve request. It shall indicate either:

− path reservation failed because FE3 does not support path reservation; or, − path reservation failed for other reasons. Examples are: User B busy or lack of resources at FE3. 8.2.1.17

rb_CC_resume_completion rb_CC_resume_completion is an unconfirmed information flow across rb from FE2 to FE3 which informs FE3 that User A is no longer busy and that FE3 should re-instate monitoring of User B, in the case that path reservation is not to be performed. There are no service elements in this information flow.

8.2.1.18

rb_CC_suspend_completion rb_CC_suspend_completion is an unconfirmed information flow across rb from FE2 to FE3 which informs FE3 that User A is temporarily busy in the case that path reservation has not been performed. There are no service elements in this information flow.

8.2.1.19

rb_CC_suspend_path_reservation rb_CC_suspend_path_reservation is an unconfirmed information flow across rb from FE2 to FE3 which informs FE3 that User A is temporarily busy and recall of User A will be delayed. NOTE This flow is accompanied by a basic call flow towards FE3 to clear the path established by the path reserve sequence. There are no service elements in this information flow.

8.2.1.20

rc_CC_status_req rc_CC_status_req is a confirmed information flow across rc from FE3 to FE4 which ascertains the status of User B. The confirmation indicates whether User B is busy or free. Table 16 lists the service elements within the rc_CC_status_req information flow. The column headed "Request" indicates which of these service elements are mandatory (M) and which are optional (O) in a rc_CC_status_req request/indication information flow. The column headed "Confirm" indicates which of these service elements are mandatory (M) and which are optional (O) in a rc_CC_status_req response/confirmation information flow. Table 16 - Information content of rc_CC_status_req Service Element

Request

Confirm

Connection Type (CT)

Destination Number (DN)

O (note 1)

Destination Subaddress (DS)

Status Indicator (SI)

M (note 2)

- 25 -

NOTE 1 DN shall be included where there is more than one PISN number associated with User B's access. NOTE 2 This service element shall indicate either: – busy, or – free. 8.2.2

Relationship of information flows to Basic Call information flows The ra_CC_recall_accept request/indication information flow shall be sent across ra in conjunction with the basic call r1_setup request/indication sent to initiate call establishment by User A in response to recall. The rb_CC_cancellation request/indication information flow shall be sent across rb in conjunction with r2_release request/indication when User A rejects SS-CC recall and path reservation has already been performed. The rb_CC_call request/indication information flow shall be sent across rb in conjunction with the basic call information flow r2_setup request/indication in the case of successful recall of User A when path reservation is not used. The rb_CC_path_reserve request/indication information flow shall be sent across rb in conjunction with the basic call information flow r2_setup request/indication sent to reserve the network path. The rb_CC_path_reserve response/confirmation information flow shall be sent across rb in conjunction with the basic call information flow r2_release request/indication clearing the established network path in the case of failure of the reservation. The rb_CC_suspend_path_reservation request/indication information flow shall be sent across rb in connection with the basic call information flow r2_release request/indication used to clear down the network path in the case that User A is temporarily unavailable after the network path has been reserved. The rb_CC_call_reject request/indication information flow shall be sent across rb in conjunction with the basic call information flow r2_release request/indication if the call offer to User B is unsuccessful. The ra_CC_cancelled request/indication information flow shall be sent across ra in conjunction with the basic call r1_report request/indication or r1_setup response/confirmation in the case where SS-CC is successful. Table 17 summarizes the relationship of the SS-CC information flows to those of basic call.

- 26 -

Table 17 - Relationship of SS-CC information flows to Basic Call Independent of basic call ?

With basic call flow ?

request

yes

confirm

yes

request

yes

Information flow ra_CC_cancellation_access ra_CC_cancelled

Basic call flows:

r1_report_req. r1_setup_resp.

ra_CC_failed

request

yes

ra_CC_list

request

yes

confirm

yes

ra_CC_recall_accepted

request

yes

r1_setup_req.

rb_CC_call

request

yes

r2_setup_req

rb_CC_call_reject

request

yes

r2_release req

rb_CC_cancellation

request

yes

r2_release req.

ra_CC_recall_accepted

request

yes

r1_setup_req.

ra_CC_rem_user_free

request

yes

ra_CC_request

request

yes

confirm

yes

request

yes

confirm

yes

ra_CC_user_B_free

request

yes

rb_CC_free_notification

request

yes

rb_CC_monitor

request

yes

confirm

yes

request

yes

r2_setup req.

confirm

yes

r2_release req.

rb_CC_resume_completion

request

yes

rb_CC_suspend_completion

request

yes

rb_CC_suspend_path_

request

yes

request

yes

confirm

yes

ra_CC_status_req

rb_CC_path_reserve

reservation rc_CC_status_req

r1_disconnect req.

r2_release req.

- 27 -

8.2.3

Examples of information flow sequences Signalling procedures shall be provided in support of the information flow sequences shown 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-CC 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-CC functional entity, the numbers refer to functional entity actions are listed in clause 8.3. The following acronyms are used in figures 5 through 29: req: cfm: ind: resp: rem:

8.2.3.1

request confirmation indication response remote

Successful invocation of SS-CC

8.2.3.1.1

Successful invocation of SS-CCBS Figure 5 shows the information flow sequence for successful invocation of SS-CC when the SS-CCBS service is requested. FE1

CCA

r1_disconnect ind/req

CC request

101 102

201

ra_CC_request req/ind

FE2

202

FE3 r2

rb_CC_monitor 301 req/ind

ra_CC_request CC confirm

103

cfm/resp

rb_CC_monitor 203

FE4 CCA

r3_setup_reject ind/req

r2_release ind/req

cfm/resp

Figure 5 - Successful invocation of SS-CC (SS-CCBS)

- 28 -

8.2.3.1.2

Successful Invocation of SS-CCNR Figure 6 shows the information flow sequence for successful invocation of SS-CC when the SS-CCNR service is requested. NOTE This example shows invocation of SS-CCNR after releasing the original call. If SS-CCNR is invoked before releasing the original call, r1_disconnect req/ind and the resultant Basic Call information flows will occur later and FEA 220 will not apply. ra

FE1

CCA

10 2

r1_report ind/req r1_disco nnect req/ind CC req ue st

FE2

FE4 CCA

r3_report ind/req

r2_release req/ind

r3_ disconnect req/ind

rb_CC_ monitor

20 2

req/ind

r2_report ind/req

r2_release req/ind

ra_CC_request

r2_report ind/req 22 0

FE3

30 1

req/ind rb_CC_mo nitor ra_CC_request CC co nfirm

10 3

20 3

cfm/resp

Figure 6 - Successful invocation of SS-CC (SS-CCNR)

8.2.3.2

Status request procedure, User A Figure 7 shows the status request procedure for ascertaining the status of User A in the case that User A's status is not known by FE2. FE1 CCA

ra r1

ra_CC_status_req 112

FE2 CC

FE3 r2

FE4

r3 CC

21 4

ind/req ra_CC_status_req resp/cfm

21 5

Figure 7 - Status request procedure, User A

CCA

- 29 -

8.2.3.3

Status request procedure, User B Figure 8 shows the status request procedure for ascertaining the status of User B in the case that User B's status is not known by FE3. FE1 CCA

FE2

FE3 r2

302

303

FE4 CCA

rc_CC_status_req req/ind

401

rc_CC_status_req cfm/resp

Figure 8 - Status request procedure, User B

8.2.3.4

Cancellation of previously invoked SS-CC request by User A Figure 9 shows the information flow sequence where User A requests cancellation of a previously invoked SSCC request. FE1

ra r1

CCA

cancel CC

Successful cancel

r2 CC

104 ra_CC_cancellation_access req/ind

FE2

205

ra_CC_cancellation_access cfm/resp 105

FE3 r2

rc FE4 r3

rb_CC_cancellation 305 req/ind

Figure 9 - Cancellation of previously invoked SS-CC request

CCA

- 30 -

8.2.3.5

Remote cancellation of previously invoked SS-CC request for service reasons Figure 10 shows the information flow sequence where FE3 initiates cancellation of a previously invoked SSCC request. ra

FE2

FE1 r1

FE3 r2

CCA

r3 CC

rb_CC_cancellation CC failed

114

ra_CC_cancelled 206 req/ind

FE4 CCA

306

ind/req

Figure 10 - Remote cancellation of previously invoked SS-CC request for service reasons

8.2.3.6

Local cancellation of previously invoked SS-CC request for service reasons Figure 11 shows the information flow sequence where FE2 initiates cancellation of a previously invoked SSCC request, e.g. for expiry of the SS-CC Service duration timer. ra

FE1

CCA

CC fail ed

FE2 CC

ra_CC_cancelled req/ind

114

FE3

FE4

r2 CC

r3 CC

CCA

rb_CC_cancellation

20 7

30 5

req/ind

Figure 11 - Local cancellation of previously invoked SS-CC request for service reasons

8.2.3.7

List of SS-CC request status Figure 12 shows the information flow sequence where User A requests the status of one or more previously invoked SS-CC requests. ra FE1 CCA

FE2 r1

FE3 r2

list CC requests

107

ra_CC_list req/ind

208

ra_CC_list list of CC requests

108 cfm/resp

Figure 12 - List of SS-CC request status

FE4 r3

CCA

- 31 -

8.2.3.8

Successful completion of SS-CC (without reservation) Figure 13 shows the information flow sequence where the SS-CC request is successfully completed without prior reservation of a network path. FE1 CCA

ra r1

FE2

FE3

r2 CC

rb_CC_free_notification 204 CC recall request

ra_CC_rem_user_free

FE4 r3

304

ind/req

221

ind/req CC recall accepted

ra_CC_recall_accepted 110 req/ind r1_setup req/ind

ra_CC_stop_recall 115

311

req/ind r2_setup req/ind

r2_setup req/ind

r2_report ind/req

r2_setup cfm/resp

r3_setup req/ind

req/ind

r1_report ind/req ra_CC_cancelled 111

rb_CC_call

209

req/ind r1_setup cfm/resp

210

312

r3_report ind/req

r3_setup cfm/resp

Figure 13 - Successful completion of SS-CC (without reservation)

CCA

- 32 -

8.2.3.9

Successful completion of SS-CC (path reservation successful) Figure 14 shows the information flow sequence where the SS-CC request is successfully completed after prior reservation of a network path. FE1

ra r1

CCA

FE2 r2

204

FE3

rc r3

rb_CC_free_notification

CCA

304

ind/req

224

rb_CC_path_reserve req/ind r2_setup req/ind

CC recall request

ra_CC_rem_user_free 211

309

r2_setup req/ind

rb_CC_path_reserve resp/cfm

ind/req CC recall accepted

110 ra_CC_recall_accepted req/ind r1_setup req/ind 115

311

req/ind

ra_CC_stop_recall req/ind

r1_report ind/req 111

rb_CC_call 209

ra_CC_cancelled req/ind r1_setup cfm/resp

210

r2_report req/ind

r2_setup resp/cfm

r2_report req/ind

r2_setup resp/cfm

FE4

312

r3_setup req/ind r3_report ind/req

r3_setup resp/cfm

Figure 14 - Successful completion of SS-CC (path reservation successful)

- 33 -

8.2.3.10

Successful completion of SS-CC (path reservation attempted, fall back to non-reservation) Figure 15 shows the information flow sequence where the SS-CC request is successfully completed after an attempt to reserve a network path fails and fall back to non-reservation occurs. FE1 CCA

ra r1

FE2 CC

FE3 r2

rc r3

rb_CC_free_notification 304

204

224

ind/req

rb_CC_path_reserve req/ind r2_setup req/ind

211 CC recall request

ra_CC_rem_user_free ind/req

CC recall accepted

110

309

r2_setup req/ind

rb_CC_path_reserve resp/cfm r2_release r2_release ind/req ind/req

ra_CC_recall_accepted req/ind r1_setup req/ind

rb_CC_call

209

115

req/ind

r1_report ind/req 111

ra_CC_cancelled req/ind r1_setup cfm/resp

311

req/ind

ra_CC_stop_recall

210

r2_setup req/ind

r2_report ind/req

r2_setup cfm/resp

r3_setup req/ind 312

r3_report ind/req

r3_setup cfm/resp

Figure 15 - Successful completion of SS-CC (path reservation attempted, fall back to non-reservation)

FE4 CCA

- 34 -

8.2.3.11

Local rejection of SS-CC by PISN Figure 16 shows the information flow sequence where FE2 rejects the request for SS-CC - i.e. local rejection. FE1 CCA

FE2

FE3

FE4

r3 CCA

CC request

102

Long/Short term denial

103

ra_CC_request req/ind

202

ra_CC_request resp/cfm

Figure 16 - Local rejection of SS-CC

8.2.3.12

Remote rejection of SS-CC by PISN Figure 17 shows the information flow sequence where FE3 rejects the request for SS-CC - i.e. remote rejection. FE1 CCA

FE2

FE3 r2

CC request

102

ra_CC_request req/ind

202

rb_CC_monitor req/ind rb_CC_monitor

Long/Short term denial

103

ra_CC_request

203

conf/resp

cfm/resp

Figure 17 - Remote rejection of SS-CC

301

FE4

r3 CCA

- 35 -

8.2.3.13

User A busy when User B becomes not busy (without reservation, request suspended) Figure 18 shows the information flow sequence where User A is busy when the PISN attempts SS-CC Recall without prior reservation of a network path and the FE2 requests FE3 to suspend the SS-CC request with a view to re-initiating monitoring of User B. FE1 CCA

ra r1

FE2 CC

204

ra_CC_user_B_free 221 ind/req

222

FE3 r2

rb_CC_free_notification

rc r3

304

ind/req

rb_CC_suspend_completion req/ind

rb_CC_resume_monitoring

FE4

313

308

req/ind

Figure 18 - User A busy on recall (without reservation, request suspended)

CCA

- 36 -

8.2.3.14

User A busy when User B becomes not busy (path reservation successful) Figure 19 shows the information flow sequence where User A is busy when the PISN attempts SS-CC Recall with prior reservation of a network path. FE1 CCA

ra r1

204

116

ra_CC_user_B_free 226 ind/req

224

FE2 r2

FE3 r2

rb_CC_free_notification

304

ind/req

rb_CC_suspend_completion req/ind

rb_CC_path_reserve

313

309

req/ind r2_setup req/ind ra_CC_rem_user_free 211

CC recall request

r2_setup req/ind

rb_CC_path_reserve resp/cfm

ind/req

CC recall accepted

110

ra_CC_recall_accepted req/ind r1_setup req/ind

rb_CC_call req/ind

209

ra_CC_stop_recall 115

req/ind

r2_setup req/ind

311

r2_setup req/ind

Figure 19 - User A busy on SS-CC Recall (path reservation successful)

FE4 CCA

- 37 -

8.2.3.15

User A busy when User B becomes not busy (path reservation attempted, fall back to nonreservation) Figure 20 shows the information flow sequence where User A is busy when the PISN attempts SS-CC Recall when prior reservation of a network path has failed and fall back to non-reservation occurs. FE1

ra r1

FE2

FE3

CCA

ra_CC_use r_ B_free

2 21

ind/req rb_CC_suspend_completion req/ind

ind/req

224

r3 CC

rb_CC_free_notification 20 4

FE4

304

30 9

rb_CC_path_reserve 30 9

req/ind r2_setup req/ind

r2_setup req/ind

rb_CC_path_reserve 211 CC reca ll req uest

110

r2_release ind/req

ra_CC_rem_user_free ind/req

CC reca ll acce pted

resp/cfm

ra_CC_recall_accepted req/ind r1_setup req/ind ra_CC_stop_recall

115

req/ind

rb_CC_call

20 9

req/ind r2_setup req/ind

311

r2_se tup req/ind

Figure 20 - User A busy on SS-CC Recall (path reservation attempted, fall back to non-reservation)

CCA

- 38 -

8.2.3.16

No response by User A to SS-CC Recall (without reservation) Figure 21 shows the information flow sequence where User A rejects the SS-CC Recall without prior reservation of a network path. FE1

ra r1

CCA

FE2 r2 CC

FE3

r2 CC

FE4

rb_CC_free_notification 204

CC recall request

ra_CC_rem_user_free

304 ind/req

221

ind/req

rb_CC_cancellation ra_CC_cancelled 114

227

req/ind

305

ind/req

Figure 21 - Rejection of SS-CC Recall by User A (without reservation)

CCA

- 39 -

8.2.3.17

No response by User A to SS-CC Recall (path reservation successful) Figure 22 shows the information flow sequence where User A rejects the SS-CC Recall with prior reservation of a network path. FE1 CCA

ra r1

FE2 r2

FE3 r2

FE4 r3

rb_CC_free_notification 20 4

22 4

304

ind/req

rb_CC_path_reserve req/ind r2_se tup req/ind

309

r2_se tup req/ind

rb_CC_path_reserve CC reca ll req uest

ra_CC_rem_user_free 211

resp/cfm

ind/req

rb_CC_cancellation 2 27 ra_ CC_cancelled 114

ind/req

305 req/ind r2_release req/ind

r2_release req/ind

Figure 22 - Rejection of SS-CC recall by User A (path reservation successful)

CCA

- 40 -

8.2.3.18

No response by User A to SS-CC recall (path reservation attempted, fall back to nonreservation) Figure 23 shows the information flow sequence where User A rejects the SS-CC Recall when prior reservation of a network path has failed and fall back to non-reservation occurs. FE1 CCA

ra r1

FE2 r2 CC

FE3 CC

rb_CC_free_notification 204

22 4

r2 CC

FE4

304

ind/req

rb_CC_path_reserve 309

req/ind r2_se tup req/ind CC re cal l re qu est

ra_CC_rem_user_free 211 ind/req

114

ra_CC_cancelled ind/req

r2_se tup req/ind rb_CC_path_reserve resp/co nf r2_release ind/req

r2_release ind/req

227

rb_CC_cancellation

30 5

req/ind

Figure 23 - Rejection of SS-CC recall by User A (path reservation attempted, fall back to non-reservation)

CCA

- 41 -

8.2.3.19

Successful SS-CC recall, User B busy (without reservation) Figure 24 shows the information flow sequence where User A accepts SS-CC Recall, but User B has become busy by the time the completed call is offered, without prior reservation of a network path. FE1 CCA

CC recall accepted

110

ra r1

FE3 r2

FE4

r3 CC

CCA

req/ind rb_CC_call

209

311

req/ind r2_setup req/ind

req/ind

r2_setup req/ind

rb_CC_call_reject 219 106

ra_CC_recall_accepted

r1_setup req/ind ra_CC_stop_recall 115

FE2

312

r3_setup_reject ind/req

req/ind

ra_CC_failed ind/req r1_disconnect ind/req

r3_setup req/ind

r2_release ind/req

Figure 24 - Successful SS-CC Recall, User B busy (without reservation)

- 42 -

8.2.3.20

Successful SS-CC recall, User B busy (path reservation successful) Figure 25 shows the information flow sequence where User A accepts SS-CC Recall, but User B has become busy by the time the completed call is offered, with prior reservation of a network path. FE1 CCA

CC-recall accepted

110

FE2

FE3 r2

FE4

r3 CC

CCA

ra_CC_recall_accepted req/ind

209

r1_setup req/ind

rb_CC_call req/ind

311

r3_setup req/ind

ra_CC_stop_recall 115

CC failed

106

req/ind

ra_CC_failed ind/req r1_disconnect ind/req

219

rb_CC_call_reject ind/req r2_release r2_release ind/req ind/req

312

r3_setup_reject ind/req

Figure 25 - Successful SS-CC recall, User B busy (path reservation successful)

- 43 -

8.2.3.21

Successful SS-CC recall, no path to User B (without reservation) Figure 26 shows the information flow sequence where User A accepts SS-CC Recall, without prior reservation of a network path, but there is no path to User B because of congestion. FE1 CCA

CC recall accepted

110

FE2

FE4 r3

req/ind 209

ra_CC_stop_recall

106

FE3

ra_CC_recall_accepted r1_setup req/ind

115

req/ind r2_setup req/ind

req/ind

ra_CC_failed ind/req r1_disconnect ind/req

rb_CC_call

216

r2_release ind/req rb_CC_cancellation req/ind

305

Figure 26 - Successful SS-CC recall, no path to User B (without reservation)

CCA

- 44 -

8.2.3.22

Failure of path reservation due to network congestion Figure 27 shows the information flow sequence where the attempt to reserve a network path for the call completion fails due to network congestion. ra

FE1

FE2

FE3

FE4

CCA

CCA rb_CC_path_reserve 22 4

req/ind r2_setup req/ind

213

r2_release ind/req (note 1) rb_CC_path_reserve req/ind (n ote 2) r2_setup req/ind

r2_setup req/ind

NOTE 1 This basic call primitive relating to the path reservation attempt is an implicit CC_path_reserve resp/cfm indicating rejection. NOTE 2 Path reservation may be re-attempted by FE2 at some point after the original failure, however a PISN may place a limit on the number of path reservation attempts that will be made. Figure 27 - Failure of path reservation due to network congestion

8.2.3.23

Failure of path reservation due to busy User B Figure 28 shows the information flow sequence where the attempt to reserve a network path for the call completion fails because User B is again busy. FE1

ra r1

CCA

FE2 CC

224

FE3 r2

rb_CC_path_reserve req/ind

rc r3

309

r2_setup req/ind

211

FE4

r2_setup req/ind rb_CC_path_reserve resp/conf r2_release r2_release ind/req ind/req

Figure 28 - Failure of path reservation due to busy User B

CCA

- 45 -

8.3

Functional entity actions The following actions shall occur at the points indicated in the figures of 8.2. 3. NOTE In the actions below, whenever the status of Users A or B is required, no details of the procedures to be used are given. It is left up to the capabilities of FE2 and FE3 as to whether this determination is made by means of the status request procedure (see figures 7 and 8) or by some other (e.g. internal) means. In addition, FE2 and FE3 may attempt to determine the status of either User A or User B respectively at any point in the SS-CC service, whether indicated in the following actions explicitly or not. The actions only indicate when the status of these users is specifically required for the correct operation of SS-CC.

8.3.1

8.3.2

Functional entity actions of FE1 101

Store information related to failed or cleared unanswered basic call to enable User A to request SS-CC.

102

Send ra_CC_request req/ind to FE2.

103

Present result of request for SS-CC to User A. If response indicates rejection, discard details of SS-CC.

104

Send ra_CC_cancellation_access req/ind to FE2.

105

Present an indication of the result of the cancellation to User A. If cancellation is successful, discard details of SS-CC.

106

Present indication of failure to User A. If SS-CC has been deregistered, discard details of SS-CC.

107

Send ra_CC_list req/ind to FE2.

108

Present response to User A.

110

Send ra_CC_recall_accept req/ind to FE2. This shall be accompanied by a basic call r1_setup req/ind toward FE2.

111

Discard details of SS-CC.

112

Send ra_CC_status_req cfm/resp to FE2 indicating whether User A is busy or free.

114

Forward notification of CC failure to User A. Discard details of SS-CC.

115

Stop SS-CC recall if not already accepted.

116

Inform User A that User B is not busy.

Functional entity actions of FE2 201

Store details of failed basic call (with the exception of any originating or Destination subaddress information). NOTE Action 201 could also be initiated by receipt of a busy indication as part of another Supplementary Service, rather than via the release of the basic call.

202

If SS-CC is possible, send rb_CC_monitor req/ind to FE3 to monitor User B. If SS-CC is not possible, send a ra_CC_request cfm/resp indicating SS-CC rejection to FE1.

203

If the SS-CC request has been accepted, send ra_CC_request cfm/resp to FE1 to indicate SS-CC acceptance, store whether FE3 supports path reservation and start the SS-CC service duration timer relevant to the service requested (SS-CCBS or SS-CCNR). If the rb_CC_monitor resp/cfm does not indicate acceptance, send ra_CC_request cfm/resp to FE1 to indicate that FE3 did not accept the monitor request and discard details of the SS-CC request.

204

Record the fact that User B is not busy and determine status of User A.

- 46 -

205

Check that the SS-CC request identified in the ra_CC_cancellation_access req/ind is valid. If valid, send rb_CC_cancellation req/ind to FE3, and ra_CC_cancellation_access resp/cfm to FE1, to acknowledge that cancellation has been successful and discard details of the SS-CC request. Stop the SS-CC service duration timer relevant to the service originally requested (SS-CCBS or SS-CCNR). If the request is not valid, send ra_CC_cancellation_access resp/cfm to FE1 indicating the reason cancellation could not take place.

206

Send ra_CC_cancelled req/ind to FE1 to indicate the reason for SS-CC cancellation to User A. Discard details of SS-CC. Stop the SS-CC service duration timer relevant to the service originally requested (SS-CCBS or SS-CCNR).

207

In order to cancel SS-CC, send rb_CC_cancellation req/ind to FE3 and send ra_CC_cancelled req/ind to FE1 to inform User A of the failure of SS-CC. Stop the SS-CC service duration timer relevant to the service originally requested (SS-CCBS or SS-CCNR).

208

If the request is valid, determine the status of the outstanding SS-CC requests and return ra_CC_list resp/cfm to FE1 indicating this status. If the request is not valid, return ra_CC-list resp/cfm to FE1 indicating the reason for failure.

209

Stop SS-CC recall timer. If recall is to all compatible terminals, send ra_CC-Stop-Recall to FE1. Send rb_CC_call req/ind to FE3. If path reservation has not been requested or has not been successful, this flow shall be accompanied by a basic call r2_setup req/ind towards FE3.

210

Discard details of SS-CC request. Stop the SS-CC service duration timer relevant to the service originally requested (SS-CCBS or SS-CCNR). Send ra_CC cancelled req/ind to FE1.

211

If path reservation has been successful, send ra_CC_rem_user_free req/ind to FE1, start SS-CC recall timer and stop service duration timer. If path reservation was not successful and FE3 supports the path reservation capability, FE2 shall: – if FE3 has not de-registered SS-CC and the failure is due to a short term condition (e.g. network congestion), or to User B busy: • after an interval, attempt to re-reserve the network path by sending rb_CC_path_reserve req/ind to FE3; or, • send rb_CC_cancellation req/ind to FE3, ra_CC_failure req/ind to FE1, discard details of SS-CC and stop SS-CC service duration timer. – if FE3 has not de-registered SS-CC and the failure is due to a long term condition (e.g. invalid destination), send rb_CC_cancellation req/ind to FE3, sendra_CC_failure req/ind to FE1, discard details of SS-CC and stop SS-CC service duration timer. – if FE3 has de-registered SS- CC either: • attempt to re-register SS-CC by sending rb_CC_monitor req/ind to FE3; or, • send ra_CC_failed req/ind to FE1, discard details of SS-CC and stop SS-CC service duration timer. If path reservation was not successful and FE3 does not support the path reservation capability, send ra_CC_rem_user_free req/ind to FE1.

213

If the failure is due to a short term condition (e.g. network congestion) either: – after an interval, attempt to re-reserve the network path by sending rb_CC_path_reserve req/ind to FE3; or, – send rb_CC_cancellation req/ind to FE3, send ra_CC_cancelled req/ind to FE1, discard details of SS-CC and stop SS-CC service duration timer. If the failure is due to a long term condition (e.g. invalid destination), send rb_CC_cancellation req/ind to FE3, send ra_CC_cancelled req/ind to FE1, discard details of SS-CC and stop SS-CC service duration timer.

- 47 -

214

In order to check the status of User A, send a ra_CC_status_req req/ind to FE1

215

Determine status of User A.

216

Send ra_CC_failed req/ind to FE1 to indicate that the SS-CC recall has failed and service not retained. Send rb_CC-cancellation req/ind to FE3. Discard details of SS-CC.

217

Send ra_CC_user_B_free and monitor User A’s status to determine when User A becomes free.

219

Send ra_CC_failed req/ind to FE1 to indicate that the SS-CC recall has failed and whether the service has been cancelled or is continuing. If automatic re-registration of SS-CC is supported and SS-CC has been de-registered, send rb_CC_monitor req/ind to FE3 to re-register SS-CC ( not shown). If automatic re-registration of SS-CC is not supported: – if SS-CC has not been de- registered, send rb_CC_cancellation req/ind to FE3 ( not shown).; and, – discard details of SS-CC.

220

Store details of cleared call (with the exception of any originating or Destination subaddress information).

221

Determine the status of User A. – If User A is free: • start SS-CC Recall timer; and • send ra_CC_rem_user_free req/ind to FE1. – If User A is busy: • send ra_CC_user_B_free req/ind to FE1; • send rb_CC_suspend_completion to FE3; and • monitor for a call being cleared to User A.

222

Determine status of User A. – If User A is free, send rb_CC_resume_monitoring req/ind to FE3. – If User A is busy, monitor for a call being cleared to User A.

8.3.3

224

On determining that User A is not busy, send rb_CC_path_reserve req/ind to FE3 in conjunction with basic call setup req/ind.

225

Send ra_CC_request conf/resp to FE1 to indicate that FE3 did not accept the monitor request and discard details of the SS-CC request.

226

Determine status of User A. If User A is busy, send ra_CC_User_B_free req/ind to FE1, Optionally send rb_CC-suspend_completion to FE3, and monitor for a call being alerted by User A.

227

On expiry of the SS-CC recall timer, send rb_CC_cancellation req/ind to FE3, send ra_CC_cancelled to FE1 and discard details of SS-CC. If a path reservation has been reserved, send r2.release req/ind with the rb_CC-cancellation req/ind.

Functional entity actions of FE3 301

If SS-CC is possible: – if the request was for SS-CCBS, store request against User B, and: • if User B is free, return rb_CC_monitor resp/cfm to FE2 indicating acceptance of the SS-CC request followed by rb_CC_free_notification to FE2 to indicate that User B is now free; or • if User B is busy, return rb_CC_monitor resp/cfm to FE2 indicating acceptance of the SS-CC request and continue to monitor User B’s status to determine when User B becomes free.

- 48 -

– if the request was for SS-CCNR, return rb_CC_monitor resp/cfm to FE2 indicating acceptance of the request. If SS-CC is not possible, return rb_CC_monitor resp/cfm to FE2 indicating the reason for rejection. 302

In order to determine the status of User B, send a rc_CC_status_req req/ind to FE4.

303

Determine status of User B.

304

Send rb_CC_free_notification req/ind to FE2 to indicate that User B is free.

305

De-register SS-CC on User B and discard details of SS-CC request.

306

In order to cancel SS-CC, send rb_CC_cancellation req/ind to FE2 and de-register SS-CC on User B.

307

Mark the related SS-CC request as temporarily suspended and await a further request for path reservation from FE2.

308

Resume monitoring of User B's status to determine when User B becomes free.

309

If path reservation is supported by FE3 and User B is free, send rb_CC_path_reserve resp/cfm indicating success of path reservation to FE2 If path reservation is supported by FE3 and if User B is busy, send rb_CC_path_reserve resp/cfm indicating that reservation has failed, accompanied by a basic call flow to release the reserved path. If path reservation is not supported by FE3, send rb_CC_path_reserve resp/cfm indicating that reservation is not supported, accompanied by a basic call flow to release the reserved path.

311

Offer completed call to User B by means of the basic call.

312

If the basic call to User B is accepted and FE3 is informed that User B has reached the Alerting state, discard details of the SS-CC request. If the basic call to User B is not accepted by User B, send rb_CC_call_reject req/ind to FE2 (accompanied by a basic call reject indication) indicating the reason for failure of SS-CC and whether the SS-CC registration has been maintained.

313 8.3.4

Functional entity actions of FE4 401

8.4

Mark the related SS-CC attempt on User B as suspended and await notification from FE2 to resume monitoring of User B. Respond to rc_CC_status_req req/ind by sending rc_CC_status_req cfm/resp to FE3 indicating whether User B is busy or free.

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.

8.4.1

Behaviour of FE1 Figure 29 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 to and from FE2 and internal stimuli. Only FE1 behaviour for the subscription option value "SS_CC_recall offered to the terminal which has invoked SS-CC" is shown.

- 49 -

fe1_idle Basic call cleared (busy)

Basic call alerting

retain info for SS-CC

fe1_ccnr possible

fe1_cc possible

CC request

Basic call cleared

list CC requests

ra_CC_list resp/conf

CC request

ra_CC_request req/ind

retain info for SS-CC

ra_CC_list req/ind

CC list result

ra_CC_request req/ind

fe1_request pending

fe1_cc possible

fe1_cc_possible

fe1_request pending

ra_CC_req resp/conf

request accepted ?

YES

CC Confirm

Short or long term ? L ONG

fe1_cc invoked

Long Term Denial

SH ORT

Short Term Denial

fe1_idle ra_CC_canc. ind/req

cancel request

CC list result

CC failed req. not maintd.

ra_CC_cancel req/ind

fe1_cc invoked

fe1_idle

fe1_cancel pending

list CC requests

ra_CC_list resp/conf

ra_CC_list req/ind fe1_cc invoked

ra_CC_rem usr_free i/r

user A free ?

ra_CC_cancel conf/resp

ra_CC_status ind/req

user A free ? YES

ra_CC_status resp/conf

fe1_cc invoked

YES

ra_CC_rem usr_free c/f

fe1_cc invoked

CC recall request fe1_recall pending

cancellation successful ?

YES

cancellation successful

cancellation failed

fe1_idle

fe1_cc invoked

Figure 29 - Behaviour of FE1 (sheet 1 of 2)

- 50 -

fe1_recall pending CC recall accept

CC recall reject

ra_CC_failed ind/req

ra_CC_recall accept r/i

ra_CC_recall reject r/i

fe1_completion pending

CC still registered ?

fe1_idle

Basic Call alerting

ra_CC_failed ind/req

Call completed

CC still registered ?

fe1_idle

ra_CC_canc. ind/req NO

YES

CC failed req. maintnd

CC failed req. not maintnd

fe1_cc invoked

fe1_idle

list CC requests

ra_CC_list resp/conf

ra_CC_list req/ind

CC list result

fe1_recall pending

YES

CC failed req. maintnd

CC failed req. not maintnd

fe1_idle

fe1_cc invoked

Figure 29 - Behaviour of FE1 (sheet 2 of 2)

- 51 -

8.4.2

Behaviour of FE2 Figure 30 shows the normal Behaviour of FE2. Input signals from the right and output signals to the right represent information flows from and to FE3 and internal stimuli. Input signals from the left and output signals to the left represent information flows to and from FE1. fe2_idle Basic call cleared (busy)

Basic call alerting

retain info for SS-CC

fe2_ccnr possible

start retention timer

ra_CC_req ind/req

Basic call cleared

Retention timer expiry

ra_CC_list ind/req

fe2_ccbs possible

stop retention timer (if running)

retain info for SS-CC

discard info for SS-CC

obtain list info.

fe2_idle

ra_CC_list resp/conf

ra_CC_list ind/req

ra_CC_req ind/req

Retention timer expiry

start retention timer

obtain list info.

stop retention timer (if running)

discard info for SS-CC

fe2_ccnr possible

ra_CC_list resp/conf fe2_ccbs possible

CCNR possible ?

fe2_idle

fe2_ccnr possible

YES

CCBS possible ?

YES

rb_monitor req/ind (ccbs)

ra_CC_req resp/conf

start monitor superv. timer

discard info for SS-CC

fe2_monitor pending

fe2_idle

rb_monitor req/ind (ccnr)

ra_CC_req resp/conf

start monitor superv. timer

discard info for SS-CC

fe2_monitor pending

fe2_idle

rb_CC_mon. conf/resp

Supervision timer expiry

ra_CC_list ind/req

CC accepted ?

ra_CC_req resp/conf

obtain list info.

discard info for SS-CC

ra_CC_list resp/conf

fe2_idle

fe2_monitor pending

YES

response to 1st monitor ? YES

ra_CC_failed req/ind

response to 1st monitor ? YES

ra_CC_req resp/conf

discard info for SS-CC

CCBS or CCNR ?

fe2_idle

CCNR

CCBS

start CCBS duration timer

start CCNR duration timer

fe2_awaiting free_notif.

Figure 30 - Behaviour of FE2 (sheet 1 of 4)

- 52 -

fe2_awaiting free_notif.

CCBS dur. timer expiry

CCNR dur. timer expiry

ra_CC_cancel. acc. ind/req

ra_CC_list ind/req

rb_CC_cancel. ind/req

obtain list info.

ra_CC_canc. req/ind

ra_CC_list resp/conf

discard info for SS-CC

ra_CC_failed req/ind

fe2_awaiting free_notif.

fe2_idle

discard info for SS-CC

ra_CC_canc. acc. resp/conf

rb_CC_cancel. req/ind

fe2_idle

fe2_awaiting free_notif.

ra_CC_canc. acc. resp/conf

ra_CC_list ind/req

basic call (reserv) failed

obtain list info.

rb_CC_cancel. req/ind

rb_free_notif. ind/req stop duration timer

Cancel valid ? YES

Path reservation possible ?

YES

discard info for SS-CC

rb_path_res. req/ind

ra_CC_remote user_free rq/in

fe2_idle

fe2_pending reservation

fe2_awaiting user_A_status

rb_CC_path res. conf/resp

YES

ra_CC_list resp/conf A

CC deregistered at FE3 ?

YES

fe2_pending reservation NO

Temporary condition ? YES

rb_CC_cancel req/ind

rb_path_res. req/ind

rb_monitor req/ind

ra_CC_failed req/ind

fe2_pending reservation

start monitor superv. timer

discard info for SS-CC

fe2_monitor pending

fe2_idle

ra_CC_recall req/ind

Path reservation successful ? YES ra_CC_recall req/ind

start CCrecall timer

fe2_pending recall

Reservation possible ? NO

ra_CC_remote user_free cf/rs

ra_CC_cancel acc. ind/req

User A busy ? YES

Cancel valid ? YES

ra_CC_canc acc. resp/conf

rb_CC_cancel req/ind

fe2_awaiting free_notif.

ra_CC_cancel acc. resp/conf discard info for SS-CC fe2_idle

Figure 30 - Behaviour of FE2 (sheet 2 of 4)

start CCrecall timer fe2_pending recall

Reservation performed ? accompanied by path clearing

YES

rb_CC_susp. req/ind

fe2_awaiting user A free

- 53 -

fe2_pending recall ra_CC_list ind/req

ra_CC_recall accept ind/req

obtain list info.

rb_CC_call req/ind

ra_CC_list resp/conf

fe2_await_res completion

ra_CC_recall reject ind/req accompanied by basic call rb_CC_cancel setup to FE3 in case of req/ind non-reservation

discard info for SS-CC

fe2_pending recall

fe2_idle

rb_call_reject ind/req

ra_CC_list ind/req obtain list info.

Basic call alerting

fe2_idle

ra_CC_list resp/conf fe2_await_non res_completion

rb_CC_cancel req/ind

CC deregistered at FE3 ? YES

ra_CC_failed req/ind discard info for SS-CC fe2_idle

ra_CC_failed req/ind CC deregistered at FE3 ? NO

fe2_awaiting free_notif.

YES

rb_monitor req/ind start monitor superv. timer fe2_monitor pending

Figure 30 - Behaviour of FE2 (sheet 3 of 4)

- 54 -

fe2_awaiting user A free rb_CC_cancel req/ind

Stimulus to check user A

ra_CC_failed req/ind discard CC request fe2_idle ra_CC_status req/ind fe2_awaiting status of A rb_CC_cancel req/ind ra_CC_failed req/ind discard CC request fe2_idle

ra_CC_status conf/resp User A free ? NO

fe2_awaiting user A free

YES

rb_monitor req/ind start monitor superv. timer fe2_monitor pending

Figure 30 - Behaviour of FE2 (sheet 4 of 4)

- 55 -

8.4.3

Behaviour of FE3 Figure 31 shows the normal Behaviour of FE3. Input signals from the right and output signals to the right represent information flows from and to FE4 and internal stimuli. Input signals from the left and output signals to the left represent information flows to and from FE2.

fe3_idle rb_monitor ind/req

CC possible ?

YES

CCBS or CCNR ?

CCNR

CCBS

A rb_CC_monitor resp/conf

rc_CC_status req/ind

fe3_idle

rb_CC_monitor resp/conf start CCNR serv. dur. timer

fe3_awaiting initial_status

fe3_awaiting activity at B

rc_CC_status conf/resp

YES

rb_CC_cancel req/ind

User B free ?

discard CC request

rb_CC_monitor resp/conf

rb_CC_free notif. req/ind

start CCBS serv. dur. timer

fe3_await completion

Activity by User B

fe3_idle

fe3_awaiting user B free rb_CC_cancel req/ind discard CC request fe3_idle rb_CC_cancel req/ind

Stimulus to check B

rc_CC_status req/ind fe3_awaiting status of B rc_CC_status conf/resp User B free ?

discard CC request fe3_idle

fe3_awaiting user B free

Figure 31 - Behaviour of FE3 (sheet 1 of 3)

YES

rb_CC_free notif. req/ind fe3_await completion

- 56 -

fe3_await completion Outgoing call from user B

rb_CC_cancel ind/req

discard CC request rc_CC_recall pend. req/ind

fe3_idle

rb_CC_path res ind/req Path reservation supported ? YES

rb_CC_susp. ind/req start suspension timer

rb_CC_path res resp/conf

path reservation unsuccesful (path cleared)

fe3_await completion

rb_CC_call ind/req

rc_CC _status req/ind

Offer call to User B

fe3_awaiting final_status

fe3_await B’s_response

rc_CC_status conf/resp

User B free ?

Suspension timer expiry

rb_CC_cancel ind/req

rb_CC_cancel req/ind

discard CC request

fe3_idle

fe3_idle YES

path reservation unsuccesful (path cleared)

rb_CC _path res resp/conf

rb_CC_path res resp/conf

fe3_await recall CC registration maintained by FE3

fe3_cc suspended

fe3_awaiting user B free

fe3_idle

Figure 31 - Behaviour of FE3 (sheet 2 of 3)

path reservation succesful

rb_CC_resume ind/req

- 57 -

fe3_await recall rb_CC_susp. reserv. ind/req

rb_CC_call ind/req

rb_CC_cancel ind/req

start suspension timer

Offer call to User B

discard CC request

fe3_cc_reserv. suspended

fe3_await B’s_response

fe3_idle

Suspension timer expiry

rb_CC_cancel ind/req

rb_CC_path res req/ind

rb_CC_cancel req/ind

discard CC request

fe3_idle

User B alerting or connected

Call rejected by User B rb_CC_call reject req/ind

CC unsuccessful, reserved path cleared in case of reservation

fe3_idle

fe3_idle CC registration maintained by FE3

fe3_awaiting user B free

fe3_idle

Figure 31 - Behaviour of FE3 (sheet 3 of 3)

8.4.4

Behaviour of FE4 Figure 32 shows the normal Behaviour of FE4. Input signals from the left and output signals to the left represent information flows from and to FE3. Input signals from the right and output signals to the right represent primitives to and from User B. fe4_idle rc_CC_status_request ind/req rc_CC_status_request resp/conf fe4_idle

Figure 32 - Behaviour of FE4

- 58 -

8.5

Allocation of functional entities to physical locations The allocations of FEs to physical equipment shown in table 17 shall apply. Table 17 - Scenarios for the allocation of FEs to physical equipment Scenarios

Functional Entities User A

User B

FE1

FE2

FE3

FE4

1 Users A and B in PISN

PINX

2 User A in PISN, User B in other network

PINX

Other network

3 User B in PISN and user A in other network

Other network

PINX

4 Users A and B in other network

Other network

Table 17 illustrates the various scenarios possible, excluding the cases of stimulus terminals. Where a terminal involved is stimulus with respect to SS-CC, any FE shown as residing in the corresponding user's TE shall reside instead in that user's PINX.

8.6

Interworking considerations When interworking with a public ISDN, the SS-CC service will always fall back to the non-path reservation mode due to the capabilities of the public ISDN service. The gateway PINX shall ensure that the acknowledgment of the SS-CC monitor request generated from a received monitor confirmation from the public ISDN is forwarded to the requestor of SS-CC indicating “reservation not supported” in the case that monitoring of a Public ISDN user is requested. When the PISN is monitoring a PISN user on behalf of a Public ISDN user, the service will always use the non-path reservation mode requested by the Public ISDN. When interworking with a non-standard network which supports only path reservation, the gateway PINX shall ensure that the acknowledgment of the SS-CC monitor request generated from a received monitor confirmation from the non-standard network is forwarded to the requestor of SS-CC indicating “reservation supported” in the case that monitoring of a user in that other network is requested. If the PISN uses the non-path reservation subsequent to this request, the gateway PINX will be responsible for performing the reservation in the other network when the CC_call request/indication flow is received from FE2.

- 59 -

Annex A (informative)

Bibliography

ITU-T Rec I.253.3

Completion of Calls to Busy Subscribers

ITU-T Rec I.253.4

Completion of Calls on No Reply

Printed copies can be ordered from: ECMA 114 Rue du Rhône CH-1204 Geneva Switzerland Fax: Internet:

+41 22 849.60.01 [email protected]

Files can be downloaded from our FTP site, ftp.ecma.ch, logging in as anonymous and giving your E-mail address as password. This Standard is available from library ECMA-ST as a compacted, self-expanding file in MSWord 6.0 format (file E185-DOC.EXE) and as an Acrobat PDF file (file E185-PDF.PDF). File E185-EXP.TXT gives a short presentation of the Standard. Our web site, http://www.ecma.ch, gives full information on ECMA, ECMA activities, ECMA Standards and Technical Reports.

ECMA 114 Rue du Rhône CH-1204 Geneva Switzerland This Standard ECMA-185 is available free of charge in printed form and as a file. See inside cover page for instructions

ECMA-185 — Private Integrated Services Network (PISN) - Specification, functional model and information flows - Call completion supplementary services (CCSD) (June 1997)

Related documents