Conceptio › Archive › ECMA International

ECMA Internationalopen access

ECMA-193 — Private Integrated Services Network (PISN) - Specification, functional model and information flows - Do not disturb and do not disturb override supplementary services (DND(O)SD) (June 1997)

ECMA International · ECMA International

ECMA International · Standards · License: Open Access

ecma ecmainternational flows information integrated model network pisn

ecma, standard, ecma international, specification, ecma-193, ecma 193, 193, private, integrated, services, network, pisn, functional, model, and, information, flows, not, disturb, override, supplementary, dnd

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

Standardizing

Information

and

Communication

Systems

Private Integrated Services Network (PISN) Specification, Functional Model and Information Flows Do Not Disturb and Do Not Disturb Override 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-193 2nd E dition - J une 1997

Standardizing

Information

and

Communication

Systems

Private Integrated Services Network (PISN) Specification, Functional Model and Information Flows Do Not Disturb and Do Not Disturb Override Supplementary Services (DND(O)SD)

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 Ecma-193.doc

19-08-97 11,41

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 and under ETSI work item DE/ECMA-00013. This particular Standard specifies the Do Not Disturb (DND) and Do Not Disturb Override (DNDO) supplementary services. This Standard is based upon the practical experience of ECMA member companies and the results of their active and continuous participation in the work of ISO/IEC JTC1, ITU-T, ETSI and other international and national standardization bodies. It represents a pragmatic and widely based consensus. There are currently no equivalent services specified by ITU-T or ETSI for public ISDNs. Compared to the 1st Edition of Standard ECMA-193 (published by ECMA in June 1993), this 2nd Edition incorporates changes in order to achieve complete alignment with International Standard ISO/IEC 14842:1996(E) published by ISO/IEC in September 1996.

Adopted as 2nd Edition of Standard ECMA-193 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 Call, basic call

4.2.3 Consultation timer

4.2.4 Originating number

4.2.5 Originating subaddress

4.2.6 Path retention

4.2.7 Served user

5 Acronyms

6 SS-DND 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 and ANFs

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 to Busy Subscriber (SS-CCBS)

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

6.3.9 Call Transfer (SS-CT)

6.3.10 Call Forwarding Unconditional (SS-CFU)

6.3.11 Call Forwarding Busy (SS-CFB)

6.3.12 Call Forwarding No Reply (SS-CFNR)

6.3.13 Call Deflection (SS-CD)

6.3.14 Path Replacement (ANF-PR)

6.3.15 Do Not Disturb Override (SS-DNDO)

- ii -

6.3.16 Call Offer (SS-CO)

6.3.17 Call Intrusion (SS-CI)

6.4 Interworking considerations

6.5 Overall SDL

7 SS-DNDO stage 1 specification

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 Interactions with other supplementary services and ANFs

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 Subscriber (SS-CCBS)

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

7.3.9 Call Transfer (SS-CT)

7.3.10 Call Forwarding Unconditional (SS-CFU)

7.3.11 Call Forwarding Busy (SS-CFB)

7.3.12 Call Forwarding No Reply (SS-CFNR)

7.3.13 Call Deflection (SS-CD)

7.3.14 Path Replacement (ANF-PR)

7.3.15 Do Not Disturb (SS-DND)

7.3.16 Call Offer (SS-CO)

7.3.17 Call Intrusion (SS-CI)

7.4 Interworking considerations

7.5 Overall SDL

8 SS-DND stage 2 specification

8.1 Functional model

8.1.1 Functional model description

8.1.2 Description of functional entities

8.1.3 Relationship of functional model 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

- iii -

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

8.3.5 Functional entity actions of FE5

8.3.6 Functional entity actions of FE6

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.4.5 Behaviour of FE5

8.4.6 Behaviour of FE6

8.5 Allocation of functional entities to physical equipment

8.6 Interworking considerations

9 SS-DNDO stage 2 specification

9.1 Functional model

9.1.1 Functional model description

9.1.2 Description of functional entities

9.1.3 Relationship of functional model to basic call functional model

9.2 Information flows

9.2.1 Definition of information flows

9.2.2 Relationship of information flows to basic call information flows

9.2.3 Examples of information flow sequences

9.3 Functional entity actions

9.3.1 Functional entity actions of FE1

9.3.2 Functional entity actions of FE2

9.3.3 Functional entity actions of FE3

9.4 Functional entity behaviour

9.4.1 Behaviour of FE1

9.4.2 Behaviour of FE2

9.4.3 Behaviour of FE3

9.5 Allocation of functional entities to physical equipment

9.6 Interworking considerations

- iv -

Scope This Standard specifies the Supplementary Services Do Not Disturb (SS-DND) and Do Not Disturb Override (SS-DNDO), which are applicable to various basic services supported by Private Integrated Services Networks (PISN). Basic services are specified in ECMA-142. SS-DND is a supplementary service which enables a served user to cause the PISN to reject any calls, or just those associated with a specified basic service, addressed to the served user's PISN number. The calling user is given an appropriate indication. Incoming calls are rejected as long as the service is active. The served user's outgoing service is unaffected. SS-DNDO is a supplementary service which enables a served user to override SS-DND at a called user; that is, to allow the call to proceed as if the called user had not activated SS-DND. SS-DND and SS-DNDO are described separately because SS-DND is a service used by a called user, and SS-DNDO is a service used by a calling user. This leads to describing two very related state machines. NOTE 1 It is possible to implement SS-DND without implementing SS-DNDO. Supplementary service specifications are produced in three stages, according to the method described in ETS 300 387. This Standard contains the stage 1 and stage 2 specifications of SS-DND and SS-DNDO. The stage 1 specifications (clauses 6 and 7) specify the supplementary service as seen by users of PISNs. The stage 2 specification (clauses 8 and 9) identify the functional entities involved in the supplementary service and the information flows between them.

Conformance In order to conform to this Standard, a stage 3 standard shall specify signalling protocols and equipment behaviour that are capable of being used in a PISN which supports the supplementary service specified in this Standard. This means that, to claim conformance, a stage 3 standard is required to be adequate for the support of those aspects of clauses 6 to 9 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 Do Not Disturb supplementary service is required to support are clauses 6 and 8. The stage 1 and stage 2 clauses which a stage 3 standard for the Do Not Disturb Override supplementary service is required to support are clauses 7 and 9.

References (normative) The following standards contain provisions which, through reference in this text, constitute provisions of this Standard. All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. In the case of references to ECMA Standards that are aligned with ISO/IEC International Standards, the number of the appropriate ISO/IEC International Standard is given in brackets after the ECMA reference. ECMA-142

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

ECMA-148

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

ECMA-163

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

ISO/IEC 11571

Information technology - Telecommunications and information exchange between systems Numbering and sub-addressing in private integrated services networks

ISO/IEC 11579-1

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

- 2 -

ETS 300 387

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

ITU-T Rec. I.112

Vocabulary of terms for ISDNs (1993)

ITU-T Rec. I.210

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

ITU-T Rec. Z.100

Specification and description language (1993)

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)

− Calling Party Name

(ECMA-163)

− Connection

(ITU-T Rec. I.112)

− Name

(ECMA-163)

− Number

(ISO/IEC 11571)

− 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)

− Subaddress

(ISO/IEC 11571)

− 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: − CHAN ACK request/indication − Disconnect request/indication − Release request/indication − Release response/confirmation − Report request/indication − Setup request/indication − Setup response/confirmation.

- 3 -

This Standard refers to the following basic call information flow service elements defined in ECMA-142: − Destination Number − Connection type. This Standard refers to the following information flow elements defined in ECMA-148: − Originating number − Originating subaddress.

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 PISN user.

4.2.2

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

4.2.3

Consultation timer A timer governing the time in which the calling user is allowed to request invocation of SS-DNDO after being informed that a call has failed because of SS-DND active at the destination. The duration of the timer is an implementation option.

4.2.4

Originating number The number of the calling user.

4.2.5

Originating subaddress The subaddress of the calling user.

4.2.6

Path retention The retention of the network connection between the Originating CC and the Destination CC so that a supplementary service (such as SS-DNDO) can be invoked without establishing a new connection.

4.2.7

Served user The user for which SS-DND is activated or deactivated, or for which SS-DND is invoked.

Acronyms ANF

Additional Network Feature

Call Control (functional entity)

CCA

Call Control Agent (functional entity)

CCBS

Call Completion to Busy Subscriber

CCNR

Call Completion on No Reply

Call Deflection

CFB

Call Forwarding Busy

CFNR

Call Forwarding No Reply

CFU

Call Forwarding Unconditional

Call Intrusion

CLIP

Calling Line Identification Presentation

CLIR

Calling/Connected Line Identification Restriction

CNIP

Calling Name Identification Presentation

CNIR

Calling/Connected Name Identification Restriction

- 4 -

Call Offer

COLP

Connected Line Identification Presentation

CONP

Connected Name Identification Presentation

Call Transfer

DND

Do Not Disturb

DNDO

Do Not Disturb Override

DNDOCL DNDO Capability Level

DNDPL

DND Protection Level

Functional Entity

ISDN

Integrated Services Digital Network

MSN

Multiple Subscriber Number

PINX

Private Integrated Services Network Exchange

PISN

Private Integrated Services Network

Path Replacement

SDL

Specification and Description Language

Supplementary Service

Terminal Equipment

SS-DND stage 1 specification

6.1 6.1.1

Description General description SS-DND is a supplementary service which enables a served user to cause the PISN to reject any calls, or just those associated with a specified basic service, addressed to the served user's PISN number. The calling user is given an appropriate indication. Incoming calls are rejected as long as the service is active. The served user's outgoing service is unaffected. The related supplementary service Do Not Disturb Override allows a calling user to override Do Not Disturb, subject to service profiles. The SS-DND service is provided on a PISN number. For a given PISN number, this service (including options) may be subscribed to for each basic service to which the user of the number subscribes, or collectively for all the basic services to which the user subscribes.

6.1.2

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

6.2 6.2.1

Procedures Provision/withdrawal SS-DND is provided or withdrawn after pre-arrangement with the service provider. SS-DND is provided on a per PISN number basis and per basic service basis. For each PISN number, the supplementary service can be subscribed to for all basic services subscribed to by that PISN number, or for only some of the basic services subscribed to by that PISN number. SS-DND subscription parameters may apply separately to each basic service to which SS-DND is subscribed, or for all the basic services to which SS-DND is subscribed. If SS-DNDO is implemented then the subscription parameter "DND protection level" (DNDPL) shall be provided. The DNDPL has a value in the range 0 to 3 where 0 means no protection against DNDO and 3 means

- 5 -

total protection against DNDO. The values 0 and 3 shall be offered. The values 1 and 2 may, as an implementation option, be offered. The effect of the subscription parameter DNDPL shall be as described in clause 6.3.15. The subscription parameter "Served user notification of invocation of SS-DND" may be provided. If it is not provided, as an implementation option, the network may or may not notify the served user of DND invocation. 6.2.2

Normal procedures

6.2.2.1

Activation/deactivation/registration/interrogation A PISN shall provide activation/deactivation by the served user (local activation/deactivation). In addition the PISN may provide activation/deactivation by another user (remote activation/deactivation). No information needs to be registered with the PISN for this supplementary service. A PISN may provide interrogation, which can be local, remote or both.

6.2.2.1.1

Local activation/deactivation To activate SS-DND the served user shall supply: 1. information as to whether SS-DND is to apply to all basic services for which SS-DND is subscribed to or to a specific basic service out of the basic services for which SS-DND is subscribed to; 2. where there is more than one PISN number assigned to the access (i.e. in the context of an MSN arrangement), the PISN number for which SS-DND shall apply. As an implementation option, it may be possible for the served user to select a tone or announcement to be given to the calling user on invocation of SS-DND. The method of making this selection is outside the scope of this Standard. To deactivate SS-DND the served user shall supply: 1. information as to whether SS-DND is no longer to apply to all basic services for which SS-DND is subscribed to or to a specific basic service out of the basic services for which SS-DND is subscribed to; 2. where there is more than one PISN number assigned to the access (i.e. in the context of an MSN arrangement), the PISN number for which SS-DND shall no longer apply. If a single number is used by more than one terminal, activation/deactivation of SS-DND shall be possible from any terminal that uses this number. When the served user requests activation/deactivation of SS-DND, the service provider shall return notification of acceptance or rejection of the request (see exceptional procedures for a list of possible causes of rejection). This notification shall be sent only to the terminal from which the request was received. When the served user successfully activates/deactivates SS-DND, the service provider shall send a notification to all the served user's terminals that are compatible with the service (or services) for which the activation/deactivation has been performed. In the case of successful activation, the notification may include the DNDPL of the served user.

6.2.2.1.2

Remote activation/deactivation If remote activate/deactivation is provided the following shall apply: A specially authorized user may activate and/or deactivate SS-DND at the served user. Authorization shall be implementation dependent (e.g. attendants may be authorized). To activate SS-DND, the authorized user shall supply: 1. information as to whether SS-DND is to apply to all basic services for which SS-DND is subscribed to or to a specific basic service out of the basic services for which SS-DND is subscribed to; 2. the PISN number for which SS-DND shall apply. To deactivate SS-DND, the authorized user shall supply: 1. information as to whether SS-DND is no longer to apply to all basic services for which SS-DND is subscribed to or to a specific basic service out of the basic services for which SS-DND is subscribed to;

- 6 -

2. the PISN number for which SS-DND shall no longer apply. NOTE 2 The use of a password facility for remote activation/deactivation as an implementation option is not excluded. When the authorized user so activates or deactivates SS-DND, the service provider shall return notification of acceptance or rejection of the request (see exceptional procedures for a list of possible causes of rejection). If the request is accepted, then the notification shall be given to the terminal from which the request has been made, and to all the served user's terminals compatible with the basic service or services for which the activation/deactivation is performed; this notification may, as an implementation option, include the DNDPL of the served user. If the request is rejected, then the notification shall only be given to the terminal from which the request has been made. 6.2.2.1.3

Local interrogation If local interrogation is provided, a PISN shall support interrogation on a per PISN number basis. The PISN response to an interrogation request shall provide the following information to the user: − if SS-DND is not activated for any basic service, an indication to that effect; − if SS-DND is activated for any basic service or services, a list of basic services for which SS-DND is active. The PISN response to an interrogation request may additionally provide the DNDPL for each basic service for which SS-DND is active.

6.2.2.1.4

Remote interrogation If remote interrogation is provided, a specially authorized user may interrogate SS-DND conditions at the served user. Authorization shall be implementation dependent (e.g. attendants may be authorized). The remote interrogation request and response shall include the information as specified for local interrogation and additionally the request shall contain the PISN number of the served user. NOTE 3 The use of a password facility for remote interrogation as an implementation option is not excluded.

6.2.2.2

Invocation and operation When SS-DND is active for some PISN number for some service, incoming calls to that PISN number for that service shall not be presented to the served user. The call is regarded as unsuccessful and an indication that the call has failed due to SS-DND shall be returned to the calling user. For the basic services for which ECMA-142 requires tones or announcements to be given to indicate progress or otherwise of the call, an inband tone or announcement shall be given to the calling user on invocation of SS-DND. For other basic services defined in ECMA-142, an in-band tone or announcement may be given to the calling user on invocation of SS-DND. NOTE 4 It is an implementation option which tones or announcements are given. The served user, as a subscription option, may receive a notification of each invocation of SS-DND on incoming calls to the served user. This notification shall include the following information: Bearer Capability information and, if available, High Layer Compatibility information and Low Layer Compatibility information. NOTE 5 The calling party address and/or name may be provided by SS-CLIP and SS-CNIP respectively; see clauses 6.3.1 and 6.3.4.

- 7 -

6.2.3

Exceptional procedures

6.2.3.1

Activation/deactivation/registration/interrogation If the PISN cannot accept an activation/deactivation/interrogation request, then the user making the request shall be informed. Possible causes for rejection are: 1. Service not subscribed to; 2. Insufficient information; 3. Not authorized to perform activation/deactivation/interrogation.

6.2.3.2

Invocation and operation None.

6.3

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

6.3.1

Calling Line Identification Presentation (SS-CLIP) The served user shall receive, as part of the served user notification of the invocation of SS-DND, the Calling Line Identification of the calling party, unless SS-CLIR applies and the served user has no override capability.

6.3.2

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

6.3.3

Calling/Connected Line Identification Restriction (SS-CLIR) When Calling Line Identification Restriction is invoked, the Calling Line Identification shall not be presented to the served user (as part of the notification that SS-DND has been invoked) unless the served user has an override category.

6.3.4

Calling Name Identification Presentation (SS-CNIP) The served user shall receive, as part of the served user notification of the invocation of SS-DND, the Calling Name Identification of the calling party, unless SS-CNIR applies and the served user has no override capability.

6.3.5

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

6.3.6

Calling/Connected Name Identification Restriction (SS-CNIR) When Calling Name Identification Restriction is invoked, the Calling Name Identification shall not be presented to the served user (as part of the notification that SS-DND has been invoked) unless the served user has an override category.

6.3.7 6.3.7.1

Completion of Calls to Busy Subscriber (SS-CCBS) Interactions caused by SS-DND at the destination of SS-CCBS If SS-CCBS is invoked on a destination with SS-DND active, then the SS-CCBS invocation shall fail due to SS-DND active. NOTE 6 This can occur if, at the time of the original call setup, SS-DND was not active but SS-DND is subsequently activated before the calling user requests SS-CCBS. If at the time the PISN attempts to complete the call to the destination following SS-CCBS recall SS-DND is active at the destination, then SS-CCBS shall be cancelled with appropriate indication to the calling user.

6.3.7.2

Interactions caused by SS-DND at the originator of SS-CCBS A SS-CCBS recall shall override SS-DND.

- 8 -

6.3.8 6.3.8.1

Completion of Calls on No Reply (SS-CCNR) Interactions caused by SS-DND at the destination of SS-CCNR If SS-CCNR is invoked on a destination with SS-DND active, then the SS-CCNR invocation shall fail due to SS-DND active. NOTE 7 This can occur if, at the time of the original call setup, SS-DND was not active but SS-DND is subsequently activated before the calling user requests SS-CCNR. If at the time the PISN attempts to complete the call to the destination following SS-CCNR recall SS-DND is active at the destination, then the SS-CCNR shall fail with appropriate indication to the calling user.

6.3.8.2

Interactions caused by SS-DND at the originator of CCNR A SS-CCNR recall shall override SS-DND.

6.3.9

Call Transfer (SS-CT) No interaction.

6.3.10

Call Forwarding Unconditional (SS-CFU) On a call to a PISN number with SS-CFU active, the call forwarding shall be invoked regardless of whether or not SS-DND is active. At a forwarded-to number, the call is treated as an incoming call and, if SS-DND is active, SS-DND shall be invoked. If SS-DND is invoked at the forwarded-to number, then the call forwarding is regarded as being unsuccessful and the call shall be cleared following the procedures in SS-CFU. If the call is cleared back to the original calling user, then the calling user shall be informed that the call failed because of SS-DND. If SS-CFNR or Call Deflection from Alert has previously occurred, then the call shall be cleared back to the served user of SS-CFNR or Call Deflection from Alert.

6.3.11

Call Forwarding Busy (SS-CFB) On a call to a PISN number with SS-CFB and SS-DND active, then SS-DND shall be invoked regardless of the busy state of the PISN number and call forwarding shall not take place. At a forwarded-to number, the call is treated as an incoming call and, if SS-DND is active, SS-DND shall be invoked at that number. If SS-DND is invoked at the forwarded-to number, then the call forwarding shall be regarded as being unsuccessful and the call shall be cleared following the procedures in SS-CFB. If the call is cleared back to the original calling user, then the calling user shall be informed that the call failed because of SS-DND. If SS-CFNR or Call Deflection from Alert has previously occurred, then the call shall be cleared back to the served user of SS-CFNR or Call Deflection from Alert.

6.3.12

Call Forwarding No Reply (SS-CFNR) On a call to a PISN number with SS-CFNR and SS-DND active, then SS-DND shall be invoked and call forwarding shall not take place. At a forwarded-to number, the call is treated as an incoming call and, if SS-DND is active, SS-DND shall be invoked at that number. If SS-DND is invoked at a forwarded-to number reached either directly by SS-CFNR or indirectly via subsequent invocations of SS-CFU and/or SS-CFB and/or Call Deflection Immediate, then the setup of the forwarded call shall fail and the procedures of SS-CFNR shall apply.

6.3.13

Call Deflection (SS-CD) On a call to a PISN number with SS-DND active, SS-DND will be invoked and therefore SS-CD cannot be invoked. At a diverted-to number reached as a result of Call Deflection Immediate, the call shall be treated as an incoming call and, if SS-DND is active, SS-DND shall be invoked at that number. If SS-DND is invoked at the diverted-to number, then Call Deflection Immediate shall be regarded as being unsuccessful and the call shall be cleared following the procedures for Call Deflection Immediate. If the call is cleared back to the original calling user, then the calling user shall be informed that the call failed because of SS-DND. If SS-CFNR or Call Deflection from Alert has already previously occurred, then the call shall be cleared back to the served user of SS-CFNR or Call Deflection from Alert.

- 9 -

At a diverted-to number reached as a result of Call Deflection from Alert, the call shall be treated as an incoming call and, if SS-DND is active, SS-DND shall be invoked at that number. If SS-DND is invoked at the diverted-to number reached either directly from Call Deflection from Alert or indirectly via subsequent invocations of SS-CFU, SS-CFB or Call Deflection Immediate, then the set up of the diverted call shall fail and the procedures of Call Deflection from Alert shall apply. 6.3.14

Path Replacement (ANF-PR) No interaction.

6.3.15

Do Not Disturb Override (SS-DNDO) If SS-DND and SS-DNDO are invoked, and SS-DNDO is allowed, then the call shall succeed as if SS-DND was not active. SS-DNDO is allowed provided the calling user has subscribed to SS-DNDO and the "DNDO Capability Level" (DNDOCL - see clause 7.2.1) of the calling user is greater than the "DND Protection Level" (DNDPL - see clause 6.2.1) of the called user.

6.3.16

Call Offer (SS-CO) If SS-CO has been invoked: − as part of the initial call setup (i.e. by SS-CO immediate invocation), − following consultation (i.e. by SS-CO Consultation), or − by SS-CO network invocation (delayed), and if, at the time of invocation, SS-DND is active at the destination and has not been successfully overridden, then the invocation of SS-CO shall be rejected, and the procedures of SS-DND shall apply.

6.3.17

Call Intrusion (SS-CI) If a call for which SS-CI has been invoked as part of the initial call set up (immediate invocation) fails because of SS-DND active, then the invocation of SS-CI shall be rejected.

6.4

Interworking considerations A call originating in another network to a PISN destination for which SS-DND is activate will be rejected. An appropriate indication may be given to the calling user; this indication may depend on the requirements of the originating network.

6.5

Overall SDL Figure 1 contains the dynamic description of SS-DND using the Specification and Description Language (SDL) defined in ITU-T Rec. Z.100 (1993). The SDL process represents the behaviour of the PISN in providing SS-DND. Input signals from the left and output signals to the left represent primitives from and to the user activating, deactivating or interrogating SS-DND, or from the basic call process, or to the calling user. Output signals to the right represent primitives to the compatible terminals of the served user.

- 10 -

Figure 1 (part 1) - SS-DND, overall SDL

- 11 -

Process dnd_s1

ds1p3(2) idle

call to served user without DNDO request (from basic call process)

SS_DND active for requested basic service yes

Allow basic call to proceed normally

idle

served user notification served user option

always notify

served user to be notified yes no DND_ invoked

basic call to release

DND_ invoked

idle

Figure 1 (part 2) - SS-DND, overall SDL

never notify

- 12 -

SS-DNDO stage 1 specification

7.1

Description

7.1.1

General description SS-DNDO is a supplementary service which enables a calling user to override SS-DND at a called user, allowing the call to proceed as if the called user had not activated SS-DND. The SS-DNDO service is provided on a PISN number. For a given PISN number, this service may be subscribed to for each basic service to which the user of the number subscribes, or collectively for all the basic services to which the user subscribes.

7.1.2

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

7.2

Procedures

7.2.1

Provision/withdrawal SS-DNDO is provided or withdrawn after pre-arrangement with the service provider. SS-DNDO is provided on a per PISN number basis and per basic service basis. For each PISN number, the supplementary service can be subscribed to for every basic service subscribed to by that PISN number, or for only some of the basic services subscribed to by that PISN number. SS-DNDO subscription parameters may apply separately to each basic service to which SS-DNDO is subscribed, or for all the basic services to which SS-DNDO is subscribed. The subscription parameter "DNDO Capability Level" (DNDOCL) shall be provided. The DNDOCL has a value in the range 1 (lowest capability) to 3 (highest capability). At least one of the DNDOCL values shall be offered. The effect of the subscription parameter DNDOCL shall be as described in clause 6.3.15. At least one of the three methods of invoking SS-DNDO (see clause 7.2.2.2) shall be offered. For a subscription to be valid, at least one of the methods of invoking SS-DNDO shall be subscribed to, and if Network invocation is subscribed to, the other two methods of invoking SS-DNDO shall not be subscribed to.

7.2.2 7.2.2.1

Normal procedures Activation/deactivation/registration/interrogation None.

7.2.2.2

Invocation and operation There are three different ways of invoking SS-DNDO. A PISN shall offer one or more of these ways. These ways are: 1. Network invocation: The network shall automatically invoke SS-DNDO whenever the calling user makes a call to a user with SS-DND active, if required by the service profile of the calling user. 2. Consultation: The calling user, on being informed that a call has failed because of SS-DND active at the destination and that SS-DNDO may be possible, shall be able, within a defined period (consultation timer), to request invocation of SS-DNDO. 3. Immediate invocation: The calling user shall be able to request invocation of SS-DNDO as part of the initial call set up. Once SS-DNDO has been invoked in a call, it applies to the complete call setup, including any call diversions that take place, and any requests for Call Offer or Intrusion, until a called user is alerting or has answered. If the called user does not have SS-DND active, the invocation of SS-DNDO shall have no effect. If the called user has SS-DND active and SS-DNDO is invoked, then the network shall investigate whether or not the calling user is allowed to override SS-DND. If the calling user is not allowed to override SS-DND, then the

- 13 -

procedures of SS-DND shall apply; if the calling user is allowed to override SS-DND, then the call proceeds as if the called user did not have SS-DND active. 7.2.3

Exceptional procedures

7.2.3.1

Activation/deactivation/registration/interrogation None.

7.2.3.2

Invocation and operation If the calling user requests invocation of SS-DNDO as part of the initial call request, and immediate invocation is not provided to the calling user, then the request shall be ignored and the call shall proceed as if the request had not been made. In the case of consultation, the request for invocation of SS-DNDO may be rejected, e.g. because SS-DNDO is not allowed. If consultation applies to the call, the call shall be released either if the calling user does not request invocation within the defined timer period (consultation timer) or if the calling user requests invocation within the defined timer period (consultation timer) and this request is rejected.

7.3

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) No interaction.

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) No interaction.

7.3.7

Completion of Calls to Busy Subscriber (SS-CCBS) No interaction. NOTE 8 Once the conditions have been reached for a possible invocation of SS-CCBS, any previous invocation of SS-DNDO in the call no longer applies, and it is not possible to invoke SS-DNDO together with SS-CCBS. If the called user has SS-DND active, clause 6.3.7.1 applies.

7.3.8

Completion of Calls on No Reply (SS-CCNR) No interaction. NOTE 9 Once the conditions have been reached for a possible invocation of SS-CCNR, any previous invocation of SS-DNDO in the call no longer applies, and it is not possible to invoke SS-DNDO together with SS-CCNR. If the called user has SS-DND active, clause 6.3.8.1 applies.

7.3.9

Call Transfer (SS-CT) No interaction.

- 14 -

7.3.10

Call Forwarding Unconditional (SS-CFU) At a forwarded-to number for which SS-DND is active: 1. If SS-CFNR or Call Deflection from Alert has already been invoked in the call, clause 7.3.12 or 7.3.13 respectively shall apply. 2. If neither SS-CFNR nor Call Deflection from Alert has been invoked in the call and SS-DNDO has already been invoked, then the invocation of SS-DNDO applies to the forwarded-to number. 3. If neither SS-CFNR nor Call Deflection from Alert nor SS-DNDO have been invoked in the call, then if the calling user is informed that the call has failed because of SS-DND active at the destination and if the calling user invokes SS-DNDO, then the invocation of SS-DNDO shall apply to the forwarded-to number.

7.3.11

Call Forwarding Busy (SS-CFB) On a call to a PISN number with SS-CFB and SS-DND active for which SS-DNDO is successfully invoked, SS-CFB proceeds normally as if the PISN number did not have SS-DND active. At a forwarded-to number for which SS-DND is active: 1. If SS-CFNR or Call Deflection from Alert has already been invoked in the call, clause 7.3.12 or 7.3.13 respectively shall apply. 2. If neither SS-CFNR nor Call Deflection from Alert has been invoked in the call and SS-DNDO has already been invoked, then the invocation of SS-DNDO applies to the forwarded-to number. 3. If neither SS-CFNR nor Call Deflection from Alert nor SS-DNDO have been invoked in the call, then if the calling user is informed that the call has failed because of SS-DND active at the destination and if the calling user invokes SS-DNDO, then the invocation of SS-DNDO shall apply to the forwarded-to number.

7.3.12

Call Forwarding No Reply (SS-CFNR) On a call to a PISN number with SS-CFNR and SS-DND active for which SS-DNDO is successfully invoked, SS-CFNR proceeds normally, i.e. as if the PISN number did not have SS-DND active. At a forwarded-to number for which SS-DND is active, if SS-CFNR has been invoked in the call, SS-DNDO shall not be applied. The setup of the forwarded call shall fail and the procedures of SS-CFNR shall apply.

7.3.13

Call Deflection (SS-CD) On a call to a PISN number at which SS-DND is active and for which SS-DNDO has been successfully invoked, Call Deflection Immediate or Call Deflection from Alert can occur. At a diverted-to number reached as a result of Call Deflection Immediate and for which SS-DND is active: − If SS-CFNR or Call Deflection from Alert has previously been invoked, SS-DNDO shall not apply, the diverted call shall fail and the procedures of SS-CFNR or Call Deflection from Alert respectively shall apply. − If neither SS-CFNR nor Call Deflection from Alert has previously been invoked but SS-DNDO has been invoked, then the invocation of SS-DNDO shall apply to the diverted-to number. − If neither SS-CFNR nor Call Deflection from Alert nor SS-DNDO has previously been invoked, then if the calling user is informed that the call has failed because of SS-DND active at the destination and if the calling user invokes SS-DNDO, then the invocation of SS-DNDO shall apply to the diverted-to number. At a diverted-to number for which SS-DND is active, if Call Deflection from Alert has been invoked in the call, SS-DNDO shall not be applied. The set up of the diverted call shall fail and the procedures of Call Deflection from Alert shall apply.

7.3.14

Path Replacement (ANF-PR) No interaction.

7.3.15

Do Not Disturb (SS-DND) Clause 6.3.15 shall apply.

- 15 -

7.3.16

Call Offer (SS-CO) If the called user has SS-DND active and SS-DNDO is successfully invoked, then: − if Call Offer network invocation (immediate), immediate invocation or network invocation (delayed) is applicable to the call, then the invocation of Call Offer shall apply to the call after SS-DND has been overridden; − if Call Offer consultation applies to the call, it shall apply after SS-DND has been overridden.

7.3.17

Call Intrusion (SS-CI) If a called user has SS-DND active, and SS-DNDO is successfully invoked, then: − if SS-CI immediate invocation is applicable to the call, then the invocation of SS-CI shall apply to the call after SS-DND has been overridden; − if SS-CI consultation is applicable to the call, it shall apply after SS-DND has been overridden.

7.4

Interworking considerations 1. For a call originating in a network that does not support SS-DND and/or SS-DNDO, then the PISN may automatically invoke SS-DNDO. If the invocation is not successful (due to the destination in the PISN having SS-DND active and a DNDPL which prevents SS-DNDO) then the call will be rejected due to SS-DND active, according to the procedures of SS-DND. 2. If a call is made, with invocation of SS-DNDO, to a destination in a network that does not support SS-DNDO, then the invocation of SS-DNDO will be ignored.

7.5

Overall SDL Figure 2 contains the dynamic description of SS-DNDO using the Specification and Description Language (SDL) defined in ITU-T Rec. Z.100 (1993). The SDL process represents the behaviour of the PISN in providing SS-DNDO to a calling user. Input signals from the left and output signals to the left represent primitives from and to the calling user. Input signals from the right represent inputs from the basic call process or from an internal process.

- 16 -

Process DNDO_s1

os1p2(3) idle

Call request with DNDO request

Call request without DNDO request

Immediate invocation not implemented

1 Immediate invocation implemented

Immediate invocation subscribed to yes

Network invocation implemented

Network invocation not implemented

no Network invocation of SS-DNDO subscribed to

yes 1

Consultation implemented

Consultation not implemented

Consultation subscribed to yes wait_2

wait_1

Call to proceed normally

idle

Figure 2 (part 1) - SS-DNDO, overall SDL

- 17 -

Process DNDO_s1

os1p3(3) wait_2

destination identified, DND not active

destination identified, DND active

SS_DNDO allowed yes

Call to proceed normally

Call cleared (from basic call process)

idle

Call to fail following procedures of SS-DND

idle

Figure 2 (part 2) - SS-DNDO, overall SDL

- 18 -

Process DNDO_s1

os1p4(3) wait_1

Call cleared (from basic call process)

destination identified, SS-DND active Call to proceed normally

SS_DNDO not allowed

idle

destination identified, SS-DND not active

yes no start consultation timer

idle

DND active, DNDO possible

active

consultation timer expiry

SS-DNDO request

Call cleared (from basic call process)

idle

SS-DNDO possible and allowed yes

reject

Call to fail following procedures of SS-DND

Call to proceed normally

idle

Figure 2 (part 3) - SS-DNDO, overall SDL

- 19 -

SS-DND stage 2 specification

8.1

Functional model

8.1.1

Functional model description The functional model shall comprise the following functional entities: FE1 FE2 FE3 FE4 FE5 FE6

Calling user's service agent; Calling user's service control agent; SS-DND detection and control entity; Served user's service agent; (De)activating/interrogating user's service control agent; (De)activating/interrogating user's service agent.

The following functional relationships shall exist between these FEs: ra rb rc rd re

between FE1 and FE2; between FE2 and FE3; between FE3 and FE4; between FE3 and FE5; between FE5 and FE6.

Figure 3 shows these FEs and relationships.

ra FE 1

rb FE 2

FE 3

FE 4

rd re

FE 5

FE 6

Figure 3 - Functional model for SS-DND 8.1.2 8.1.2.1

Description of functional entities Calling user's service agent, FE1 This functional entity receives the information from FE2 that SS-DND has been invoked and is responsible for passing this on to the calling user.

8.1.2.2

Calling user's service control agent, FE2 This functional entity: − receives the information from FE3 that SS-DND has been invoked, and is responsible for passing this on to FE1; − if required, produces the in-band tone or announcement to inform the calling user of the invocation of SS-DND.

8.1.2.3

SS-DND detection and control entity, FE3 This functional entity: − maintains the SS-DND activation state of the called user; − processes activation/deactivation/interrogation requests from FE5, checking the operation is allowed, performing an operation as appropriate and informing FE5 of the result. − informs FE4 of changes in the SS-DND activation state; − on an incoming call to the called user, invokes SS-DND if SS-DND is active; − on invocation of SS-DND, informs FE2 and, if the implementation/subscription options so requires, FE4; − if required, produces the in-band tone or announcement to inform the calling user of the invocation of SS-DND.

- 20 -

8.1.2.4

Served user's service agent, FE4 This functional entity: − receives from FE3 indications of changes in the SS-DND activation state and informs the served user of these changes; − receives from FE3 the indication that SS-DND has been invoked, and informs the called (i.e. served) user of this.

8.1.2.5

(De)activating/interrogating user's service control agent, FE5 This functional entity: − checks whether the (de)activating/interrogating user is authorized to change the SS-DND activation state of the served user; − if the user is not authorized, sends a reject message to FE6; − if the user is authorized, sends the request to FE3, and passes the response from FE3 to FE6. In the case of local activation/deactivation/interrogation, FE5 is collocated with FE3.

8.1.2.6

(De)activating/interrogating user's service agent, FE6 This functional entity receives PISN user requests for changing and interrogating the SS-DND activation state, passes these to FE5, and passes the response from FE5 back to the PISN user. NOTE 10 FE6 may supply an in-band tone or announcement to the (de)activating/interrogating user to indicate the result of the operation. This is outside the scope of this Standard.

8.1.3

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

CCA

FE 2

r3 CCA

ra FE 1

FE 3 rd

FE 4

re FE 5

FE 6

Figure 4 - Example relationship between models for SS-DND and basic call

8.2

Information flows

8.2.1

Definition of information flows In the tables listing the service elements in information flows, the column headed "Request" indicates which of these service elements are mandatory (M) and which are optional (O) in a request/indication information flow, and the column headed "Confirm" indicates which of these service elements are mandatory (M) and which are optional (O) in a response/confirmation information flow.

8.2.1.1

ra_DND_invoked ra_DND_invoked is an unconfirmed information flow across ra between FE2 and FE1 which is used to indicate that SS-DND has been invoked. There are no service elements within the ra_DND_invoked information flow.

- 21 -

8.2.1.2

rb_DND_invoked rb_DND_invoked is an unconfirmed information flow across rb between FE3 and FE2 which is used to indicate that SS-DND has been invoked. There are no service elements in this information flow.

8.2.1.3

rc_Activated rc_Activated is an unconfirmed information flow across rc from FE3 to FE4 used to indicate that SS-DND has been successfully activated. Table 1 lists the service elements within the rc_Activated information flow. Table 1 - Content of rc_Activated Element

Request

Basic Service

M (Note 11)

Served user's MSN number

O (Note 12)

DND Protection Level

O (Note 13)

NOTE 11 Indicates a particular basic service or all basic services. NOTE 12 This shall only be included if MSN applies for the served user. NOTE 13 If present, this lists the DNDPL of the basic service or basic services for which SS-DND has been activated. 8.2.1.4

rc_Deactivated rc_Deactivated is an unconfirmed information flow across rc from FE3 to FE4 used to indicate that SS-DND has been deactivated. Table 2 lists the service elements within the rc_Deactivated information flow. Table 2 - Content of rc_Deactivated Element

Request

Basic Service

M (Note 14)

Served user's MSN number

O (Note 15)

NOTE 14 Indicates a particular basic service or all basic services. NOTE 15 This shall only be included if MSN applies for the served user. 8.2.1.5

rc_DND_invoked rc_DND_invoked is an unconfirmed information flow across rc from FE3 to FE4 which is used to inform the served user that SS-DND has been invoked. Table 3 lists the service elements within the rc_DND_invoked information flow.

- 22 -

Table 3 - Content of rc_DND_invoked Element

Request

Served user's MSN number

O (Note 16)

Connection type

Originating number

O (Note 17)

Originating subaddress

O (Note 17)

Calling party name

O (Note 18)

NOTE 16 The served user's MSN number is only required if MSN applies to the served user. NOTE 17 This information shall be included as defined for the Identification supplementary services in ECMA-148. NOTE 18 This conveys the calling party name and shall be included as defined in the information flow INFORM1 in ECMA-163. 8.2.1.6

rd_Activate rd_Activate is a confirmed information flow across rd from FE5 to FE3 used to request SS-DND activation. Table 4 lists the service elements within the rd_Activate information flow. Table 4 - Content of rd_Activate Element

Request

Confirm

Basic Service

M (Note 19)

O (Note 20)

Served user's number

O (Note 21)

Served user's MSN number

O (Note 22)

Result

M (Note 23)

DND Protection Level

O (Note 24)

NOTE 19 In the request this indicates a particular basic service or all basic services. NOTE 20 This may be present in the confirmation if the result indicates "accepted" and it lists the basic services for which SS-DND has been activated. NOTE 21 This shall only be included in remote activation information flows. NOTE 22 This shall only be included in non-remote activation information flows and if MSN applies for the served user. NOTE 23 This takes the values "accepted", "rejected".

- 23 -

NOTE 24 This may be present in the confirmation if the result indicates "accepted" and it lists the DNDPL of the basic services for which SS-DND has been activated. 8.2.1.7

rd_Deactivate rd_Deactivate is a confirmed information flow across re from FE6 to FE5 used to request SS-DND deactivation. Table 5 lists the service elements within the rd_Deactivate information flow. Table 5 - Content of rd_Deactivate Element

Request

Basic Service

M (Note 25)

Served user's number

O (Note 26)

Served user's MSN number

O (Note 27)

Result

Confirm

M (Note 28)

NOTE 25 Indicates a particular basic service or all basic services. NOTE 26 This shall only be included in remote deactivation information flows. NOTE 27 This shall only be included in non-remote deactivation information flows and if MSN applies for the served user. NOTE 28 This takes the values "accepted", "rejected". 8.2.1.8

rd_Interrogate rd_Interrogate is a confirmed information flow across rd from FE5 to FE4 used to request SS-DND interrogation. Table 6 lists the service elements within the rd_Interrogate information flow. Table 6 - Content of rd_Interrogate Element

Request

Served user's number

O (Note 30)

Served user's MSN number

O (Note 31)

Confirm

Basic Services

M (Note 29)

Result

M (Note 32)

DND Protection Level

O (Note 33)

NOTE 29 This lists the basic services for which SS-DND is active. If SS-DND is not active for any basic service, the list is empty.

- 24 -

NOTE 30 This shall only be included in remote interrogation information flows. NOTE 31 This shall only be included in non-remote interrogation information flows and if MSN applies for the served user. NOTE 32 This takes the values “accepted”, “rejected”. NOTE 33 This may be present in the confirmation. It lists the DNDPL of the basic services for which SS-DND is active. 8.2.1.9

re_Activate re_Activate is a confirmed information flow across re from FE6 to FE5 used to request SS-DND activation. Table 7 lists the service elements within the re_Activate information flow. Table 7 - Content of re_Activate Element

Request

Confirm

Basic Service

M (Note 34)

O (Note 35)

Served user's number

O (Note 36)

Activating user's MSN number

O (Note 37)

Result

M (Note 38)

DND Protection Level

O (Note 39)

NOTE 34 Indicates a particular basic service or all basic services. NOTE 35 This may be present in the confirmation if the result indicates “accepted” and it lists the basic services for which SS-DND has been activated. NOTE 36 This shall only be included in remote activation information flows. NOTE 37 This shall only be included if MSN applies for the activating user. NOTE 38 This takes the values "not authorized", "accepted", "rejected". NOTE 39 This may be present in the confirmation if the result indicates "accepted". It lists the DNDPL of the basic services for which SS-DND has been activated. 8.2.1.10

re_Deactivate re_Deactivate is a confirmed information flow across re from FE6 to FE5 used to request SS-DND deactivation. Table 8 lists the service elements within the re_Deactivate information flow.

- 25 -

Table 8 - Content of re_Deactivate Element

Request

Basic Service

M (Note 40)

Served user's number

O (Note 41)

Deactivating user's MSN number

O (Note 42)

Result

Confirm

M (Note 43)

NOTE 40 Indicates a particular basic service or all basic services. NOTE 41 This shall only be included in remote deactivation information flows. NOTE 42 This shall only be included if MSN applies for the deactivating user. NOTE 43 This takes the values "not authorized", "accepted", "rejected". 8.2.1.11

re_Interrogate re_Interrogate is a confirmed information flow across re from FE6 to FE5 used to request SS-DND interrogation. Table 9 lists the service elements within the re_Interrogate information flow. Table 9 - Content of re_Interrogate Element

Request

Served user's number

O (Note 45)

Interrogating user's MSN number

O (Note 46)

Confirm

Result

M (Note 47)

Basic Services

O (Note 44)

DND Protection Level

O (Note 48)

NOTE 44 This is present in the confirmation if and only if result is "allowed". It lists the basic services for which SS-DND is active. If SS-DND is not active for any basic service, the list is empty. NOTE 45 This shall only be included in remote interrogation information flows. NOTE 46 This shall only be included if MSN applies for the interrogating user. NOTE 47 This takes the values "not allowed", "allowed".

- 26 -

NOTE 48 This may be present in the confirmation if result is "allowed". It lists the DNDPL of the basic services for which SS-DND is active. 8.2.2

Relationship of information flows to basic call information flows ra_DND_invoked request/indication shall be sent: − with r1_DISCONNECT request/indication if no tone or announcement is to be given to the calling user; − with r1_REPORT request/indication (specifying Report Type = "call rejection" and Call History = "In-band information") if a tone or announcement is to be given to the calling user and no r1_REPORT request/indication has previously been sent; − independently of any basic call information flow if a tone or announcement is to be given to the calling user and r1_REPORT request/indication has previously been sent. rb_DND_invoked request/indication shall be sent: − with r2_RELEASE request/indication if no tone or announcement is to be given by FE3 to the calling user; − with r2_REPORT request/indication (specifying Report Type = "call rejection" and Call History = "In-band information") if a tone or announcement is to be given by FE3 to the calling user and no r2_REPORT request/indication has previously been sent; − independently of any basic call information flow if a tone or announcement is to be given by FE3 to the calling user and r2_REPORT request/indication has previously been sent. All other information flows shall be sent independently of basic call information flows. Table 10 summarizes the relationship of the SS-DND information flows with those of the basic call.

- 27 -

Table 10 - Relationship of the SS-DND information flows with the basic call Information flow

8.2.3

Independent of basic call flow

With basic flow

Basic call flows

ra_DND_invoked

request

yes

r1_REPORT_request/indication, r1_DISCONNECT_request/indication

rb_DND_invoked

request

yes

r2_REPORT_request/indication, r2_RELEASE_request/indication

rc_Activated

request

yes

rc_Deactivated

request

yes

rc_DND_invoked

request

yes

rd_Activate

request

yes

rd_Activate

confirm

yes

rd_Deactivate

request

yes

rd_Deactivate

confirm

yes

rd_Interrogate

request

yes

rd_Interrogate

confirm

yes

re_Activate

request

yes

re_Activate

confirm

yes

re_Deactivate

request

yes

re_Deactivate

confirm

yes

re_Interrogate

request

yes

re_Interrogate

confirm

yes

Examples of information flow sequences A stage 3 standard for SS-DND shall provide signalling procedures in support of the information flow sequences specified below. In addition, signalling procedures should be provided to cover other sequences arising from error situations, interactions with basic call, interactions with other supplementary services, different topologies, etc.. In the figures, SS-DND 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-DND functional entity, the numbers refer to functional entity actions listed in 8.3. The following abbreviations are used: req

request

ind

indication

resp

response

cfm

confirmation

- 28 -

8.2.3.1

Normal operation of SS-DND Figure 5 shows the information flow sequence for normal operation of SS-DND, in which an in band tone or announcement is given by FE3. The calling user may release the call using normal basic call procedures; FE3 may release the call using normal basic call procedures, e.g. after completion of an announcement. The indication of SS-DND invocation given to the served user is optional and depends on the subscription options of the served user.

FE1 CCA

ra r1

r1_SETUP req/ind r1_CHAN ACK req/ind

FE2 CC

rb r2

r2_SETUP req/ind

FE3

FE4

301

r2_CHAN ACK req/ind r2_REPORT req/ind rb_DND_invoked 201 req/ind

rc_DND-invoked req/ind

r1_REPORT req/ind ra_DND_invoked 101 req/ind In band tone or announcement

Figure 5 - Information flow sequence - normal operation of SS-DND with tone or announcement to calling user from FE3

401

- 29 -

Figure 6 shows the information flow sequence for normal operation of SS-DND, in which no in band tone or announcement is given to the calling user. FE3 releases the call. The indication of SS-DND invocation given to the served user is optional and depends on the subscription options of the served user.

FE1 CCA

ra r1

r1_SETUP req/ind r1_CHAN ACK req/ind

FE2 CC

rb r2

r2_SETUP req/ind

FE4

303

r2_CHAN ACK req/ind r2_RELEASE req/ind rb_DND_invoked 203 req/ind

r1_DISCONNECT req/ind ra_DND_invoked 101 req/ind

FE3

rc_DND-invoked req/ind

r2_RELEASE res/con

r1_RELEASE req/ind r1_RELEASE res/con Figure 6 - Information flow sequence - normal operation of SS-DND with no tone or announcement to calling user

401

- 30 -

Figure 7 shows the information flow sequence for normal operation of SS-DND, in which an in band tone or announcement is given to the calling user by FE2. The calling user may release the call using normal basic call procedures; FE2 may release the call using normal basic call procedures, e.g. after completion of an announcement. The indication of SS-DND invocation given to the served user is optional and depends on the subscription options of the served user.

FE1 CCA

ra r1

r1_SETUP req/ind r1_CHAN ACK req/ind

FE2 CC

rb r2

r2_SETUP req/ind

FE4

303

r2_CHAN ACK req/ind r2_RELEASE req/ind rb_DND_invoked 202 req/ind

r2_REPORT req/ind ra_DND_invoked 101 req/ind In band tone or announcement

FE3

rc_DND-invoked req/ind

r2_RELEASE res/con

Figure 7 - Information flow sequence - normal operation of SS-DND with tone or announcement to calling user from FE2

401

- 31 -

8.2.3.2

Activation/deactivation/interrogation of SS-DND Figure 8 shows in generic form the information flow sequence for successful activation/deactivation/ interrogation of SS-DND. A particular information flow sequence is obtained by replacing X, Y and Z as shown in table 11: Table 11 - Mapping of X, Y, Z into information flows

FE6

601

Activate

re_Activate

rd_Activate

rc_Activated

Deactivate

re_Deactivate

rd_Deactivate

rc_Deactivated

Interrogate

re_Interrrogate

rd_Interrrogate

X req/ind

FE5

FE3

501 Y req/ind

302 Z req/ind

502

602

FE4

402

Y con/res

X con/res

Figure 8 - Information flow sequence for successful activation/deactivation/interrogation of SS-DND

- 32 -

8.3

Functional entity actions The following FE actions shall occur at the points indicated in the figures of 8.2.3.

8.3.1

Functional entity actions of FE1 101

8.3.2

8.3.3

The ra_DND_invoked indication is processed (in addition to the basic call actions resulting from the processing of the REPORT_indication or the DISCONNECT_indication, if received together with ra_DND_invoked indication). A REPORT_indication primitive marked as call rejected due to SS-DND is sent to the calling user.

Functional entity actions of FE2 201

The rb_DND_invoked_indication is processed (in addition to the basic call actions resulting from the processing of the REPORT_indication, if received together with rb_DND_invoked_indication). An ra_DND_invoked_request is sent to FE1.

202

In addition to the basic call actions resulting from the processing of the RELEASE_indication, the rb_DND_invoked_indication is processed. An in band source shall be applied to the information channel and an ra_DND_invoked_request shall be sent (possibly together with an r1_REPORT_request) to FE1.

203

In addition to the basic call actions resulting from the processing of the RELEASE_indication, the rb_DND_invoked_indication is processed. An ra_DND_invoked_request shall be sent (together with an r1_DISCONNECT_request) to FE1.

Functional entity actions of FE3 301

In addition to the basic call actions resulting from the processing of the SETUP_indication: − an in-band source shall be applied to the information channel, and an rb_DND_invoked_request (together with an r2_REPORT_request to the preceding CC, unless this has already been sent in connection with some other supplementary service) shall be sent to FE2; − if the served user is to receive an indication that SS-DND has been invoked, then an rc_DND_invoked_request shall be sent to FE4.

302

The rd_Activate indication, rd_Deactivate indication or rd_Interrogate indication is processed: − a rd_Activate response, rd_Deactivate response or rd_Interrogate response, as appropriate, is sent to FE5; − in the case of successful activation or deactivation, a rc_Activated request or rc_Deactivated request, as appropriate, is sent to FE4.

303

In addition to the basic call actions resulting from the processing of the SETUP_indication: − an rb_DND_invoked_request (together with an r2_RELEASE_request to the preceding CC) shall be sent to FE2; − if the served user is to receive an indication that SS-DND has been invoked, then an rc_DND_invoked_request shall be sent to FE4.

8.3.4

8.3.5

Functional entity actions of FE4 401

The rc_DND_invoked_indication is processed. An rc_DND_invoked_indication primitive is sent to the called PISN user.

402

The rc_Activated indication or rc_Deactivated indication is processed and an appropriate primitive is sent to the served user.

Functional entity actions of FE5 501

The re_Activate indication, re_Deactivate indication or re_Interrogate indication is processed and the authority of the (de)activating/interrogating user is checked. − if the (de)activating/interrogating user is not authorized, then a re_Activate response, re_Deactivate response or re_Interrogate response, as appropriate, with result "not_allowed" is sent to FE6;

- 33 -

− If the (de)activating/interrogating user is authorized, then a rd_Activate request, rd_Deactivate request or rd_Interrogate request, as appropriate, is sent to FE3. 502

8.3.6

8.4

The rd_Activate confirmation, rd_Deactivate confirmation or rd_Interrogate confirmation is processed and an rd_Activate response, rd_Deactivate response or rd_Interrogate response, as appropriate, is sent to FE6.

Functional entity actions of FE6 601

The activate/deactivate/interrogate request from the (de)activating/interrogating user is processed and a re_Activate request, re_Deactivate request or re_Interrogate request, as appropriate, is sent to FE5.

602

The rd_Activate confirmation, rd_Deactivate confirmation or rd_Interrogate confirmation is processed and an appropriate primitive is sent to the (de)activating/interrogating user.

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 (1993).

8.4.1

Behaviour of FE1 Figure 9 shows the normal behaviour of FE1. Output signals to the left represent primitives to calling user. Input signals from the right represent information flows from FE2.

Process DND_FE1

ds2p2(1) idle

ra_DND_ invoked req/ind

101

DND_ invoked

idle

Figure 9 - SS-DND, SDL for functional entity FE1

- 34 -

8.4.2

Behaviour of FE2 Figure 10 shows the normal behaviour of FE2. Input signals from the right represent information flows from FE3. Output signals to the left represent information flows to FE1.

Process DND_FE2

ds2p3(1) idle

201

rb_DND_ invoked req/ind

202,203

ra_DND_ invoked req/ind

and r2_RELEASE_ request/indication

Is an in band tone or announcement to be given yes

and r1_ DISCONNECT_ request/indication

idle

ra_DND_ invoked req/ind

idle

Instruct basic call to apply source

ra_DND_ invoked req/ind

idle

Figure 10 - SS-DND, SDL for functional entity FE2

- 35 -

8.4.3

Behaviour of FE3 Figure 11 shows the normal behaviour of FE3. Input signals from the right represent input signals from the collocated CC. Output signals to the right represent information flows to FE4. Input signals from the left and output signals to the left represent information flows from and to FE2 or FE5 as appropriate.

- 36 -

Figure 11 (part 1) - SS-DND, SDL for functional entity FE3

- 37 -

Process DND_FE3

ds2p8(2)

idle

rd_Activate req/ind

302

rd_ Deactivate req/ind

Process activation request

accepted

rd_ Interrogate req/ind

process deactivation request

accepted

yes rd_Activate con/res

302

Process interrogation request

yes rd_Activate con/res

rd_ Deactivate con/res

rc_Activated req/ind

rc_ Deactivated req/ind

idle

rd_ Deactivate con/res

rd_ Interrogate con/res

idle

Figure 11 (part 2) - SS-DND, SDL for functional entity FE3

302

- 38 -

8.4.4

Behaviour of FE4 Figure 12 shows the normal behaviour of FE4. Output signals to the right represent primitives to the called user. Input signals from the left represent information flows from FE3.

Process DND_FE4

ds2p5(1) 402

idle

rc_DND_ invoked req/ind

401

rc_ Activated req/ind

DND_ activated

DND_invoked

rc_ Deactivated req/ind

DND_ deactivated

idle

Figure 12 - SS-DND, SDL for functional entity FE4

- 39 -

8.4.5

Behaviour of FE5 Figure 13 shows the normal behaviour of FE5. Input signals from the left and output signals to the left represent information flows from and to FE6. Input signals from the right and output signals to the right represent information flows from and to FE3.

Process DND_FE5

ds2p6(1)

idle

501

re_Activate req/ind

Authorised

re_ Deactivate req/ind

Authorised

501

re_ Interrogate req/ind

Authorised

yes

rd_Activate req/ind

rd_Deactivate req/ind

rd_ Interrogate req/ind

wait act

wait deact

wait int

rd_Activate con/res

rd_Deactivate con/res

rd_ Interrogate con/res

re_Activate con/res

idle

re_Activate con/res

re_ Deactivate con/res

idle

re_ Deactivate con/res

re_ Interrogate con/res

idle

Figure 13 - SS-DND, SDL for functional entity FE5

501

502

re_ Interrogate con/res

- 40 -

8.4.6

Behaviour of FE6 Figure 14 shows the normal behaviour of FE6. Input signals from the left and output signals to the left represent primitives from and to the (de)activating/interrogating user. Input signals from the right and output signals to the right represent information flows from and to FE5.

Process DND_FE6

ds2p7(1)

601

idle

request for activation of SS-DND

request for deactivation of SS-DND

re_ Deactivate req/ind

re_Activate req/ind

wait act

wait int

re_ Deactivate con/res

activation result

idle

re_ Interrogate req/ind

wait deact

re_Activate con/res

request for interrogation of SS-DND

re_ Interrogate con/res

deactivation result

idle

602

interrogation result

idle

Figure 14 - SS-DND, SDL for functional entity FE6

- 41 -

8.5

Allocation of functional entities to physical equipment The allocation of FEs to physical locations as shown in tables 12 and 13 shall apply. Where a terminal involved is stimulus with respect to SS-DND, any FE shown as residing in the corresponding user's TE shall reside in that user's PINX. Table 12 - Scenarios for the allocation of FEs to physical equipment for normal operation

Scenario 1

FE1

FE2

FE3

FE4

Originating TE

Originating PINX

Terminating PINX

Terminating TE

Table 13 - Scenarios for the allocation of FEs to physical equipment for activation/deactivation/interrogation

8.6

FE6

FE5

FE3

FE4

Scenario 2

Served User TE

Served User PINX

Served User TE

Scenario 3

(De)activating/ interrogating User TE

(De)activating/ interrogating User PINX

Served User PINX

Served User TE

Interworking considerations On an incoming call from another network: 1. If the other network supports SS-DND, then FE1 and FE2 shall be in the other network (see table 14, scenario 4). 2. If the other network does not support SS-DND, then FE2 is in the gateway PINX. The behaviour of FE2 towards the other network may be implementation dependent and may depend on the requirements of the other network (see table 14, scenario 5). Table 14 - Scenarios for the allocation of FEs to physical equipment for normal operation in the case of interworking with another network

Scenario 4 Scenario 5

FE1

FE2

FE3

FE4

Other network

Terminating PINX

Terminating TE

Gateway PINX

Terminating PINX

Terminating TE

- 42 -

SS-DNDO stage 2 specification The stage 2 specification provides for two different methods for the operation of SS-DNDO within the network. With the path retention method, if a called user with SS-DND active is encountered the network connection between the Originating CC and the Destination CC is not released in accordance with the procedures of SS-DND but instead is retained awaiting a possible request for SS-DNDO. With the non-retention method, if a called user with SS-DND active is encountered and the basic call SETUP request/indication was not accompanied by a request for SS-DNDO, the network connection is released in accordance with the procedures of SS-DND. Therefore, with the non-retention method, if SS-DNDO is requested after encountering a called user with SS-DND active a new network connection has to be established. Either of the methods can be used to support any of the three methods of invoking SS-DNDO described in 7.2.2.2. − Network invocation and immediate invocation can be supported by the non-retention method by accompanying the SETUP request/indication with a request for SS-DNDO. − Network invocation and immediate invocation can be supported by the path retention method by accompanying the SETUP request/indication with a request for path retention and then, when the path is retained because the called user has SS-DND active, requesting SS-DNDO. − Consultation can be supported by the non-retention method by not accompanying the SETUP request/ indication with a request for SS-DNDO and then, when the connection is released because the called user has SS-DND active, consulting the calling user. SS-DNDO can be requested if necessary by repeating the SETUP request/indication, this time accompanied by a request for SS-DNDO. − Consultation can be supported by the path retention method by accompanying the SETUP request/indication with a request for path retention and then, when the path is retained because the called user has SS-DND active, consulting the calling user. SS-DNDO can be requested if necessary using the retained connection. If it is determined that SS-DNDO is not required the connection is released. The stage 3 standard for SS-DNDO at the Q reference point shall support both options, shall permit a PINX supporting FE2 functionality (see clause 9.1) to support either path retention or non-retention or both, and shall require a PINX supporting FE3 functionality to support both path retention and non-retention.

9.1

Functional model

9.1.1

Functional model description The functional model shall comprise the following functional entities: FE1 FE2 FE3

Calling user's service agent; Calling user's service control agent; SS-DND and SS-DNDO detection and control entity.

The following functional relationships shall exist between these FEs: ra rb

between FE1 and FE2; between FE2 and FE3

Figure 15 shows these FEs and relationships.

ra FE 1

rb FE 2

FE 3

Figure 15 - Functional model for SS-DNDO 9.1.2 9.1.2.1

Description of functional entities Calling user's service agent, FE1 This functional entity is responsible for accepting requests for SS-DNDO from the calling user and passing these to FE2. It also receives the information from FE2 that SS-DND has been invoked and that SS-DNDO may be invoked, and is responsible for passing this on to the calling user.

- 43 -

9.1.2.2

Calling user's service control agent, FE2 This functional entity: − at the time of the original basic call r1_SETUP_request/indication: • receives and validates request from FE1 for immediate invocation of SS-DNDO; • determines if immediate invocation, network invocation or consultation is applicable to the call; • if SS-DNDO is applicable to the call, determines if the path retention method or the non-retention method is to be used and, as appropriate, sends a path retention request or immediate invocation request to FE3 at the time of the original basic call r2_SETUP_request/indication, or retains the call setup information; − if consultation applies to the call and the conditions for performing consultation are met: • informs FE1 that SS-DND is active and SS-DNDO may be requested, and, if appropriate, applies an in band tone or announcement to the information channel; • limits the length of the consultation by clearing the call if the calling user has not responded (by requesting SS-DNDO or clearing the call) within the consultation time; • receives request (during consultation) from FE1 for invocation of SS-DNDO, sends an appropriate SSDNDO invocation request (depending on the method used) to FE3, and sends the result of the invocation request to FE1; − if immediate invocation or network invocation applies and the path retention method is used, on receipt of the information from FE3 that SS-DND is active and SS-DNDO is allowed, sends a SS-DNDO invocation request to FE3.

9.1.2.3

SS-DND and SS-DNDO detection and control entity, FE3 This functional entity: − on an incoming call with DNDO request to the called user who has SS-DND active, checks if SS-DNDO is allowed; if so, SS-DND is overridden and the call proceeds normally; if not, no action is taken (the procedures of SS-DND apply); − on an incoming call without DNDO request but with path retention request, if SS-DND is active and SSDNDO is allowed, retains the path to FE2 and offers FE2 the possibility of invoking SS-DNDO. If required, applies an in band tone or announcement. On receipt of an SS-DNDO request from FE2, checks if SS-DNDO is still allowed and, if so, overrides SS-DND, informing FE2 of the result.

9.1.3

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

CCA

r2 CC

FE 2

CCA

ra FE 1

FE 3

Figure 16 - Example relationship between models for SS-DNDO and basic call

9.2 9.2.1

Information flows Definition of information flows In the tables listing the service elements in information flows, the column headed "Request" indicates which of these service elements are mandatory (M) and which are optional (O) in a request/indication information flow, and the column headed "Confirm" indicates which of these service elements are mandatory (M) and which are optional (O) in a response/confirmation information flow.

- 44 -

9.2.1.1

ra_DNDO ra_DNDO is an unconfirmed information flow across ra from FE1 to FE2 which is used to invoke SS-DNDO as part of the original call setup. There are no service elements within the ra_DNDO information flow.

9.2.1.2

ra_DNDO_INV ra_DNDO_INV is a confirmed information flow across ra from FE1 to FE2 which is used to invoke SS-DNDO. The response indicates one of the following: − short term denial, e.g. because of congestion; − long term denial, e.g. because of insufficient DNDOCL; − success. Table 15 list the service elements within the ra_DNDO_INV information flow. Table 15 - Content of ra_DNDO_INV Element

Request

DNDO_INV_result

Confirm M (Note 49)

NOTE 49 DNDO_INV_result takes one of the values: short-term-denial, long-term-denial, success. 9.2.1.3

ra_INFORM ra_INFORM is an unconfirmed information flow across ra from FE2 to FE1 which is used to inform the calling user that SS-DND has been invoked and that the calling user may request invocation of SS-DNDO. There are no service elements within the ra_INFORM information flow.

9.2.1.4

rb_DNDO rb_DNDO is an unconfirmed information flow across rb from FE2 to FE3 which is used to invoke SS-DNDO. Table 16 lists the service elements within the rb_DNDO information flow. Table 16 - Content of rb_DNDO Element

Request

DNDO Capability Level

9.2.1.5

rb_DNDO_ACT rb_DNDO_ACT is an unconfirmed information flow across rb from FE2 to FE3 which is used to indicate that, if the called user has SS-DND active and SS-DNDO is allowed, the network connection is to be retained. Table 17 lists the service elements within the rb_DNDO_ACT information flow. Table 17 - Content of rb_DNDO_ACT Element DNDO Capability Level

Request M

- 45 -

9.2.1.6

rb_DNDO_available rb_DNDO_available is an unconfirmed information flow across rb from FE3 to FE2 which is used (following receipt of rb_DNDO_ACT) to indicate that the called user has SS-DND active, SS-DNDO is allowed and the path is retained. There are no service elements within the rb_DNDO_available information flow.

9.2.1.7

rb_DNDO_INV rb_DNDO_INV is a confirmed information flow across rb from FE2 to FE3 which is used to invoke SS-DNDO when, after encountering SS-DND active, the path between FE2 and FE3 has been retained. The response indicates one of the following: − short term denial, e.g. because of congestion; − long term denial, e.g. because of insufficient DNDOCL; − success. Table 18 lists the service elements within the rb_DNDO_INV information flow. Table 18 - Content of rb_DNDO_INV Element

Request

Confirm

DNDO_INV_result

M (Note 50)

NOTE 50 DNDO_INV_result takes one of the values: short-term-denial, long-term-denial, success. 9.2.2

Relationship of information flows to basic call information flows ra_DNDO request/indication shall be sent in conjunction with basic call information flow r1_SETUP. ra_DNDO_INV request/indication shall be sent independently of a basic call information flow. ra_DNDO_INV response/confirmation shall be sent: − together with r1_DISCONNECT_request/indication if this is sent at the same time; − otherwise independently of a basic call information flow. ra_INFORM request/indication shall be sent: − with r1_REPORT request/indication (specifying Report Type = "call rejection" and Call History = "In-band information") if a tone or announcement is to be given to the calling user and no r1_REPORT request/indication has previously been sent; − independently of any basic call information flow if a tone or announcement is to be given to the calling user and r1_REPORT request/indication has previously been sent; − independently of any basic call information flow if no tone or announcement is to be given to the calling user. rb_DNDO_request/indication shall r2_SETUP_request/indication.

sent

conjunction

with

basic

call

information

flow

rb_DNDO_ACT request/indication shall be sent in conjunction with basic call information flow r2_SETUP_request/indication. rb_DNDO request/indication and DNDO_ACT request/indication shall not be sent in conjunction with the same basic call information flow r2_SETUP_request/indication. rb_DNDO_available request/indication shall be sent: − independently of any basic call information flow if no tone or announcement is to be given by FE3 to the calling user;

- 46 -

− with r2_REPORT request/indication (specifying Report Type = "call rejection" and Call History = "In-band information") if a tone or announcement is to be given by FE3 to the calling user and no r2_REPORT request/indication has previously been sent; − independently of any basic call information flow if a tone or announcement is to be given by FE3 to the calling user and r2_REPORT request/indication has previously been sent. rb_DNDO_INV request/indication shall be sent independently of a basic call information flow. rb_DNDO_INV response/confirmation shall be sent: − together with r2_RELEASE request/indication if this is sent at the same time; − otherwise independently of a basic call information flow. Table 19 summarizes the relationship of the SS-DNDO information flows with those of the basic call. Table 19 - Relationship of the SS-DNDO information flow with the basic call Information flow

9.2.3

Independent of basic call flow

With basic flow

Basic call flows

ra_DNDO

request

yes

r1_SETUP_request/indication

ra_DNDO_INV

request

yes

ra_DNDO_INV

confirm

yes

r1_DISCONNECT_request/indication

ra_INFORM

request

yes

r1_REPORT_request/indication

rb_DNDO

request

yes

r2_SETUP_request/indication

rb_DNDO_ACT

request

yes

r2_SETUP_request/indication

rb_DNDO_available

request

yes

r2_REPORT_request/indication

rb_DNDO_INV

request

yes

rb_DNDO_INV

confirm

yes

r2_RELEASE_request/indication

Examples of information flow sequences A stage 3 standard for SS-DNDO shall provide signalling procedures in support of the information flow sequences specified below. In addition, signalling procedures should be provided to cover other sequences arising from error situations, interactions with basic call, interactions with other supplementary services, different topologies, etc.. In the figures, SS-DNDO 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-DNDO functional entity, the numbers refer to functional entity actions listed in 9.3. The following abbreviations are used: req

request

ind

indication

resp

response

cfm

confirmation

- 47 -

9.2.3.1

Normal operation of SS-DNDO, immediate invocation, non-retention method Figure 17 shows the information flow sequence for normal operation of SS-DNDO for the case of immediate invocation by the calling user with the use of the non-retention method by the network.

FE1 CCA

101

FE2

r1_SETUP req/ind ra_DNDO req/ind r1_CHAN ACK req/ind

FE3 r2

201 r2_SETUP req/ind r2_SETUP req/ind rb_DNDO req/ind r2_CHAN ACK req/ind

301 r2_CHAN ACK req/ind

If SS-DND is not active, further processing as per basic call If SS-DNDO is allowed, further processing as per basic call If SS-DNDO is not allowed, further processing as per SS-DND Figure 17 - Information flow sequence - normal operation of SS-DNDO immediate invocation, non-retention method

- 48 -

9.2.3.2

Normal operation of SS-DNDO, immediate invocation, path retention method Figure 18 shows the information flow sequence for normal operation of SS-DNDO for the case of immediate invocation by the calling user with the use of the path retention method by the network, for the particular case that SS-DND is active and SS-DNDO is allowed at the time of the initial call request.

FE1

FE2

CCA

101

r1_SETUP req/ind ra_DNDO req/ind

rb r2

r2_SETUP req/ind 208

r1_CHAN ACK req/ind

rb_DNDO ACT req/ind r2_CHAN ACK req/ind r2_REPORT req/ind

FE3

r2_SETUP req/ind 302

r2_CHAN ACK req/ind r2_REPORT req/ind rb_DNDO_available req/ind

209

rb_DNDO_INV req/ind

211

303

rb_DNDO_INV con/res

If success, the call proceeds as per basic call. If short term or long term denial, the call fails following the procedures of SS-DND.

Figure 18 - Information flow sequence - normal operation of SS-DNDO immediate invocation, path retention method

- 49 -

9.2.3.3

Normal operation of SS-DNDO, network invocation, non-retention method Figure 19 shows the information flow sequence for normal operation of SS-DNDO for the case of invocation by the network with the use of the non-retention method by the network.

FE1 CCA

FE2

FE3 r2

r1_SETUP req/ind

205 r1_CHAN ACK req/ind

r2_SETUP req/ind r2_SETUP req/ind rb_DNDO req/ind r2_CHAN ACK req/ind

301 r2_CHAN ACK req/ind

If SS-DND is not active, further processing as per basic call If SS-DNDO is allowed, further processing as per basic call If SS-DNDO is not allowed, further processing as per SS-DND Figure 19 - Information flow sequence - normal operation of SS-DNDO network invocation, non-retention method

- 50 -

9.2.3.4

Normal operation of SS-DNDO, network invocation, path retention method Figure 20 shows the information flow sequence for normal operation of SS-DNDO for the case of invocation by the network with the use of the path retention method by the network.

Figure 20 - Information flow sequence - normal operation of SS-DNDO network invocation, path retention method

- 51 -

9.2.3.5

Normal operation of SS-DNDO, consultation, path retention method, SS-DNDO invoked Figure 21 shows the information flow sequence for normal operation of SS-DNDO for the case of consultation with the use of the path retention method by the network. In this particular information flow sequence, SS-DND is active at the called user and the calling user has sufficient DNDO Capability Level to override DND, and the calling user invokes SS-DNDO.

FE1

FE2

CCA

r1_SETUP req/ind

204

r1_CHAN ACK req/ind

rb r2

r2_SETUP req/ind rb_DNDO ACT req/ind r2_CHAN ACK req/ind r2_REPORT req/ind

102 103

104

r1_REPORT req/ind ra_INFORM req/ind ra_DNDO_INV req/ind

ra_DNDO_INV con/res

207

r2_SETUP req/ind 302

r2_CHAN ACK req/ind r2_REPORT req/ind rb_DNDO_available req/ind

202

203

FE3

rb_DNDO_INV req/ind

303

rb_DNDO_INV con/res

If success, the call proceeds as per basic call. If short term or long term denial, the call fails following the procedures of SS-DND.

Figure 21 - Information flow sequence - normal operation of SS-DNDO consultation, path retention method, calling user invokes SS-DNDO

- 52 -

9.2.3.6

Normal operation of SS-DNDO, consultation, non-retention method, in-band tone or announcement from FE3, SS-DNDO invoked Figure 22 shows the information flow sequence for normal operation of SS-DNDO for the case of consultation with the use of the non-retention method by the network. In this particular information flow sequence, SS-DND is active at the called user and the calling user has sufficient DNDO Capability Level to override DND, and the calling user requests invocation of SS-DNDO. During the consultation an in band tone or announcement is given by FE3, and FE2 releases the original call between the Originating CC and the Destination CC following the calling user request for invocation of SS-DNDO.

FE1

FE2

CCA

r1_SETUP req/ind

212

r1_CHAN ACK req/ind

rb r2

r2_SETUP req/ind

r2_CHAN ACK req/ind r2_REPORT req/ind

102 103

r1_REPORT req/ind ra_INFORM req/ind ra_DNDO_INV req/ind

213

214

r2_RELEASE req/ind r2_RELEASE con/res r2_SETUP req/ind rb_DNDO req/ind

FE3 r2

r2_SETUP req/ind

r2_CHAN ACK req/ind r2_REPORT req/ind rb_DND_invoked req/ind

r2_RELEASE req/ind r2_RELEASE con/res r2_SETUP req/ind 301

If SS-DND is not active, further processing as per basic call If SS-DNDO is allowed, further processing as per basic call If SS-DNDO is not allowed, further processing as per SS-DND 104

ra_DNDO_INV con/res

Figure 22 - Information flow sequence - normal operation of SS-DNDO consultation, non-retention method, in band tone from FE3, calling user invokes SS-DNDO

- 53 -

9.2.3.7

Normal operation of SS-DNDO, consultation, non-retention method, SS-DNDO invoked Figure 23 shows the information flow sequence for normal operation of SS-DNDO for the case of consultation with the use of the non-retention method by the network. In this particular information flow sequence, SS-DND is active at the called user and the calling user has sufficient DNDO Capability Level to override DND, and the calling user requests invocation of SS-DNDO. FE3 releases the original call on invocation of SS-DND and during the consultation an in band tone or announcement is given by FE2.

FE1

FE2

CCA

r1_SETUP req/ind

212

r1_CHAN ACK req/ind

rb r2

r2_SETUP req/ind

r2_CHAN ACK req/ind r2_RELEASE req/ind

102 103

r1_REPORT req/ind ra_INFORM req/ind ra_DNDO_INV req/ind

216

r2_RELEASE con/res

FE3 r2

r2_SETUP req/ind

r2_CHAN ACK req/ind r2_RELEASE req/ind rb_DND_invoked req/ind r2_RELEASE con/res

217

r2_SETUP req/ind rb_DNDO req/ind

r2_SETUP req/ind 301

If SS-DND is not active, further processing as per basic call If SS-DNDO is allowed, further processing as per basic call If SS-DNDO is not allowed, further processing as per SS-DND 104

ra_DNDO_INV con/res

Figure 23 - Information flow sequence - normal operation of SS-DNDO consultation, non-retention method, in band tone from FE2, calling user invokes SS-DNDO

- 54 -

9.2.3.8

Normal operation of SS-DNDO, consultation, path retention method, SS-DNDO not allowed Figure 24 shows the information flow sequence for normal operation of SS-DNDO for the case of consultation with the use of the path retention method by the network. In this particular information flow sequence, SS-DND is active at the called user and the calling user has too low a DNDO Capability Level to override DND, so the call fails following the procedures of SS-DND.

FE1

FE2

CCA

r1_SETUP req/ind

204

r1_CHAN ACK req/ind

rb r2

r2_SETUP req/ind rb_DNDO ACT req/ind r2_CHAN ACK req/ind

FE3 r2

r2_SETUP req/ind 302

r2_CHAN ACK req/ind

Further processing according to the procedures of SS-DND Figure 24 - Information flow sequence - normal operation of SS-DNDO consultation, path retention method, SS-DNDO not allowed

- 55 -

9.2.3.9

Normal operation of SS-DNDO, consultation, path retention method, calling user releases Figure 25 shows the information flow sequence for normal operation of SS-DNDO for the case of consultation with the use of the path retention method by the network. In this particular information flow sequence, SS-DND is active at the called user and the calling user has sufficient DNDO Capability Level to override DND, but the calling user chooses to release the call.

FE1

FE2

CCA

r1_SETUP req/ind

204

r1_CHAN ACK req/ind

rb r2

r2_SETUP req/ind rb_DNDO ACT req/ind r2_CHAN ACK req/ind r2_REPORT req/ind

102

r1_REPORT req/ind ra_INFORM req/ind

r2_SETUP req/ind 302

r2_CHAN ACK req/ind r2_REPORT req/ind rb_DNDO_available req/ind

202

r1_DISCONNECT req/ind 215 r1_RELEASE req/ind r1_RELEASE con/res

FE3

r2_RELEASE req/ind r2_RELEASE con/res Further as per basic call

Figure 25 - Information flow sequence - normal operation of SS-DNDO consultation, path retention method, SS-DNDO allowed, calling user releases call

- 56 -

9.2.3.10

Normal operation of SS-DNDO, consultation, non-retention method, calling user releases Figure 26 shows the information flow sequence for normal operation of SS-DNDO for the case of consultation with the use of the non-retention method by the network. In this particular information flow sequence, SS-DND is active at the called user and the calling user has sufficient DNDO Capability Level to override DND, but the calling user chooses to release the call. FE3 releases the original call on invocation of SS-DND and during the consultation an in band tone or announcement is given by FE2.

FE1

FE2

CCA

r1_SETUP req/ind

212

r1_CHAN ACK req/ind

rb r2

r2_SETUP req/ind

r2_CHAN ACK req/ind r2_RELEASE req/ind

102

r1_REPORT req/ind ra_INFORM req/ind r1_DISCONNECT req/ind r1_RELEASE req/ind r1_RELEASE con/res

216

r2_RELEASE con/res

FE3 r2

r2_SETUP req/ind

r2_CHAN ACK req/ind r2_RELEASE req/ind rb_DND_invoked req/ind r2_RELEASE con/res

215

Figure 26 - Information flow sequence - normal operation of SS-DNDO consultation, non-retention method, in band tone from FE2, calling user releases

- 57 -

9.2.3.11

Normal operation of SS-DNDO, consultation, path retention method, calling user does not respond within the consultation time Figure 27 shows the information flow sequence for normal operation of SS-DNDO for the case of consultation with the use of the path retention method by the network. In this particular information flow sequence, SS-DND is active at the called user and the calling user has sufficient DNDO Capability Level to override DND, but the calling user does not respond within the time limit.

FE1

FE2

CCA

r1_SETUP req/ind

204

r1_CHAN ACK req/ind

rb r2

r2_SETUP req/ind rb_DNDO ACT req/ind r2_CHAN ACK req/ind r2_REPORT req/ind

102

r1_REPORT req/ind ra_INFORM req/ind

FE3

r2_SETUP req/ind 302

r2_CHAN ACK req/ind r2_REPORT req/ind rb_DNDO_available req/ind

202

expiry of consultation timer r1_DISCONNECT 206 req/ind

r2_RELEASE req/ind

r1_RELEASE req/ind

r2_RELEASE con/res

r1_RELEASE con/res

Further as per basic call

Figure 27 - Information flow sequence - normal operation of SS-DNDO consultation, path retention method, SS-DNDO allowed, calling user does not respond

- 58 -

9.2.3.12

Normal operation of SS-DNDO, consultation, non-retention method, calling user does not respond within consultation time Figure 28 shows the information flow sequence for normal operation of SS-DNDO for the case of consultation with the use of the non-retention method by the network. In this particular information flow sequence, SS-DND is active at the called user and the calling user has sufficient DNDO Capability Level to override DND, but the calling user does not respond within the time limit. FE3 releases the original call on invocation of SS-DND and, during the consultation an in band tone or announcement is given by FE2.

FE1

FE2

CCA

r1_SETUP req/ind

212

r1_CHAN ACK req/ind

rb r2

r2_SETUP req/ind

r2_CHAN ACK req/ind r2_RELEASE req/ind

102

r1_REPORT req/ind ra_INFORM req/ind

216

r2_RELEASE con/res

FE3 r2

r2_SETUP req/ind

r2_CHAN ACK req/ind r2_RELEASE req/ind rb_DND_invoked req/ind r2_RELEASE con/res

expiry of consultation timer r1_DISCONNECT 218 req/ind r1_RELEASE req/ind r1_RELEASE con/res

Figure 28 - Information flow sequence - normal operation of SS-DNDO consultation, non-retention method, in band tone from FE2, calling user does not respond

- 59 -

9.3

Functional entity actions The following FE actions shall occur at the points indicated in the figures of 9.2.3.

9.3.1

9.3.2

Functional entity actions of FE1 101

The DNDO request primitive from the calling user is processed and, together with the basic call information flow r1_SETUP_request, a ra_DNDO_request shall be sent to FE2.

102

The ra_INFORM_indication is processed (in addition to the basic call actions resulting from the processing of the REPORT_indication, if received together with ra_INFORM indication). A primitive marked as "call has failed due to SS-DND, SS-DNDO possible" shall be sent to the calling user.

103

The DNDO request primitive from the calling user is processed and a ra_DNDO_INV_request shall be sent to FE2.

104

The ra_DNDO_INV confirmation is processed and an appropriate primitive shall be sent to the calling user.

Functional entity actions of FE2 201

The ra_DNDO_indication is processed and, together with the basic call information flow r2_SETUP_request, a rb_DNDO_request shall be sent to FE3.

202

The rb_DNDO_available_request/indication is processed. An ra_INFORM_request shall be sent to FE1 and the consultation timer shall be started.

203

The ra_DNDO_INV_indication is processed, and a rb_DNDO_INV_request shall be sent to FE3. The consultation timer shall be stopped.

204

A rb_DNDO_ACT request shall be sent, together with the basic call information flow r2_SETUP_request, to FE3.

205

A rb_DNDO_request shall be sent, together with the basic call information flow r2_SETUP_request, to FE3.

206

On expiry of the consultation timer, the call shall be released both towards the CCA and the next CC.

207

The rb_DNDO_INV_confirmation is processed and a ra_DNDO_INV_response shall be sent to FE1.

208

The ra_DNDO_indication is processed and, together with the basic call information flow r2_SETUP_request/indication, a rb_DNDO_ACT_request shall be sent to FE3.

209

The rb_DNDO_available request/indication is processed. An rb_DNDO_INV shall be sent to FE3.

210

An rb_DNDO_ACT_request shall be sent, together with the r2_SETUP_request, to FE3.

211

The rb_DNDO_INV indication is processed.

212

All the information in the basic call SETUP shall be retained.

213

Instruct collocated SS-DND process to suppress sending of ra_DND_invoked_request/indication to FE1. An ra_INFORM_request shall be sent to FE1 and the consultation timer shall be started.

214

The ra_DNDO_INV_indication is processed. The consultation timer shall be stopped. The original call shall be released in the direction of the next CC and the basic call process shall be stimulated to setup a new basic call with the information retained from the original call setup, and an rb_DNDO_request shall be sent, together with the basic call information flow r2_SETUP_request, to FE3. Then: − If the call fails because of SS-DND active and SS-DND is not allowed, then an ra_DNDO_INV_confirmation with result "long term denial" shall be sent to FE1; − If the call fails for some other temporary reason in the PISN (e.g. congestion), then an ra_DNDO_INV_confirmation with result "short term denial" shall be sent to FE1; − If SS-DND is successfully overridden then an ra_DNDO_INV_confirmation with result "success" shall be sent to FE1.

215

The consultation timer shall be stopped.

- 60 -

216

Instruct collocated SS-DND process to suppress sending of ra_DND_invoked_request/indication to FE1. An in band tone or announcement source shall be applied to the information channel and, unless an r1_REPORT request has already been sent in connection with some other supplementary service, an r1_REPORT_request shall be sent to the CCA. An ra_INFORM_request shall be sent to FE1 and the consultation timer shall be started.

217

The ra_DNDO_INV_indication is processed. The consultation timer shall be stopped. The basic call process shall be stimulated to setup a new basic call with the information retained from the original call setup, and an rb_DNDO_request shall be sent, together with the basic call information flow r2_SETUP_request, to FE3. Then: − If the call fails because of SS-DND active and SS-DND is not allowed, then an ra_DNDO_INV_confirmation with result "long term denial" shall be sent to FE1; − If the call fails for some other temporary reason in the PISN (e.g. congestion), then an ra_DNDO_INV_confirmation with result "short term denial" shall be sent to FE1; − If SS-DND is successfully overridden then an ra_DNDO_INV_confirmation with result "success" shall be sent to FE1.

218 9.3.3

On expiry of the consultation timer, the call shall be released towards the CCA.

Functional entity actions of FE3 301

The rb_DNDO_indication is processed. − If SS-DND is not active at the called user, then no action shall be taken (the call proceeds normally as a basic call); − If SS-DND is active at the called user, and SS-DNDO is allowed, then SS-DND shall be overridden and the call shall proceed normally as a basic call; − If SS-DND is active at the called user, and SS-DNDO is not allowed, then the call shall be rejected following the procedures of SS-DND.

302

The rb_DNDO_ACT_indication is processed. If SS-DND is active at the called user and DNDO is allowed, then an rb_DNDO_available request/indication shall be sent to FE2. For those basic services that require an in band tone or announcement, FE3 shall apply an in band tone or announcement and, unless an r2_REPORT_request has already been sent in conjunction with some other supplementary service, an r2_REPORT_request shall be sent to the preceding CC.

303

The rb_DNDO_INV_indication is processed. − If SS-DND is not active or is active and SS-DNDO is allowed, then the call shall proceed normally as a basic call and an rb_DNDO_INV_response (with result "success") shall be sent to FE2; − If SS-DND is active and SS-DNDO is not allowed the call shall fail following the procedures of SS-DND and an rb_DNDO_INV_response (with result "short term denial" or "long term denial" as appropriate) shall be sent to FE2.

9.4

9.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 the calling user. Input signals from the right and output signals to the right represent information flows from and to FE2 and input signals from the collocated CCA.

- 61 -

9.4.2

Behaviour of FE2 Figure 30 shows the normal behaviour of FE2. Input signals from the left and output signals to the left represent primitives from and to FE1. Input signals from the right and output signals to the right represent information flows from and to FE3 and input signals from the collocated CC or other internal process.

- 62 -

Figure 29 - SS-DNDO, SDL for functional entity FE1

- 63 -

Figure 30 (part 1) - SS-DNDO, SDL for functional entity FE2

- 64 -

Process DNDO_FE2 I_Wait_Act

209

os2p4(6) Immediate invocation or network invocation; Path retention method

rb_DNDO_ available req/ind

rb_DNDO_ INV req/ind

Immediate path retention invoking

rb_DNDO_ INV con/res

211

idle

Figure 30 (part 2) - SS-DNDO, SDL for functional entity FE2

- 65 -

Process DNDO_FE2 C_Wait_Act

ra_DNDO_ available req/ind

os2p9(6) Consultation; Path retention method

202

DNDO_consult

Inv.

timer

rb_DNDO_ INV_ req/ind

consultation path retention invoking

rb_DNDO_ INV_ res/con

Basic call to release call towards CCA and next CC

207

idle

ra_DNDO_ INV_ res/con

I_Wait_Act

Figure 30 (part 3) - SS-DNDO, SDL for functional entity FE2

- 66 -

Process DNDO_FE2

os2p10(6) Consultation; Non-retention method

C_Wait

Call released by FE3 due to SS-DND active (from co-located SS-DND process)

216

Instruct co-located SS-DND process to suppress sending of ra_DND_invoked req/ind

DNDO_consult

Inv.

timer

Stimulate basic call process to set up a new basic call with the information retained from the original call setup

rb_DNDO_ req/ind

and r2_SETUP

Basic call to release call towards CCA

idle

consultation non-retention invoking

Call answered or alerting

ra_DNDO_INV_ con/res (success)

Call failed not due to SS_DND (from basic call process)

ra_DNDO_INV_ con/res (short term denial)

Call failed due to SS-DND active (from co-located SS-DND process) ra_DNDO_INV_ con/res (long term denial)

idle

Figure 30 (part 4) - SS-DNDO, SDL for functional entity FE2

- 67 -

Figure 30 (part 5) - SS-DNDO, SDL for functional entity FE2

- 68 -

Process DNDO_FE2

os2p11(6) * consultation non-retention invoking

ie. any state except "consultation non-retention invoking"

from basic call process

Call answered

Call alerting

Call cleared

Stop consultation timer

215

The timer is not always running

idle

Figure 30 (part 6) - SS-DNDO, SDL for functional entity FE2

- 69 -

Macro DNDO_consult

os2p12(1)

ra_Inform_ req/ind

start consultation timer

Is an in band tone or announcement to be given yes

Apply source

consulting_ %MACROID

ra_DNDO_ INV_ req/ind

203,214, 217

Consultation timer

Is an in band tone or announcement being given

206,218

timer yes no Remove source

Stop consultation timer

Inv.

Figure 30 (part 7) - SS-DNDO, SDL for functional entity FE2

- 70 -

9.4.3

Behaviour of FE3 Figure 31 shows the normal behaviour of FE3. Input signals from the left and output signals to the left represent information flows from and to FE2. Input signals from the right represent input signals from the collocated CC or from an internal process.

Process DNDO_FE3

os2p6(3)

idle

rb_DNDO req/ind

301

wait_DNDO

destination identified, SS-DND not active

destination identified, SS-DND active

yes

SS-DNDO allowed no

call to fail following the procedures of SS-DND

basic call to proceed

idle

Figure 31 (part 1) - SS-DNDO, SDL for functional entity FE3

- 71 -

Process DNDO_FE3

os2p7(3)

idle

rb_DNDO_ ACT req/ind

302

wait_DNDO_ ACT

destination identified, SS-DND active

destination identified, SS-DND not active

Basic call to proceed

SS_DNDO allowed

idle

call to fail following the procedures of SS-DND

yes

idle

no yes

Is an in band tone or announcement to be supplied Supply in band tone or announcement

rb_DNDO_ available req/ind

Path retained

Figure 31 (part 2) - SS-DNDO, SDL for functional entity FE3

- 72 -

Figure 31 (part 3) - SS-DNDO, SDL for functional entity FE3

- 73 -

9.5

Allocation of functional entities to physical equipment The allocation of FEs to physical locations as shown in table 20 shall apply. Where a terminal involved is stimulus with respect to SS-DND, any FE shown as residing in the corresponding user's TE shall reside in that user's PINX. Table 20 - Scenarios for the allocation of FEs to physical equipment

Scenario 1

9.6

FE1

FE2

FE3

Originating TE

Originating PINX

Terminating PINX

Interworking considerations On an incoming call from another network: 1. If the other network supports SS-DNDO, then FE1 and FE2 shall be in the other network (see table 21, scenario 2). 2. If the other network does not support SS-DNDO then, depending on the requirements of the other network, FE2 may be in the gateway PINX and may be required to automatically invoke SS-DNDO (see table 21, scenario 3). On an outgoing call to another network: 1. If the other network fully supports SS-DNDO, then FE3 shall be in the other network (see table 21, scenario 4). 2. If the other network does not support SS-DNDO, then FE3 shall be in the gateway PINX (see table 21, scenario 5) and shall ignore a rb_DNDO request/indication, and shall ignore a rb_DNDO_ACT request/indication. 3. If the other network supports SS-DND and supports SS-DNDO only without path retention then FE3 shall be in the gateway PINX (see table 21, scenario 5) and shall: a) On receipt of rb_DNDO request/indication, send a request for call establishment with SS-DNDO request to the other network. The service element "DNDO Capability Level" shall be adapted to the requirements of the other network if necessary. b) On receipt of rb_DNDO_ACT request/indication, shall do one of the following: i) Send a request for call establishment with SS-DNDO request to the other network. The service element "DNDO Capability Level" shall be adapted to the requirements of the other network if necessary. ii) Send a request for call establishment without SS-DNDO request to the other network. If the call fails due to SS-DND active, then FE3 may retain all call setup information and send rb_DNDO_available request/indication to FE2. If subsequently rb_DNDO_INV request/ indication is received then a new request for call establishment (using the retained information) with SS-DNDO request shall be sent to the other network. The service element "DNDO Capability Level" shall be adapted to the requirements of the other network if necessary. Depending on the result, a rb_DNDO_INV response/confirmation specifying appropriate value for DNDO_INV_result shall be sent to FE2. The actions may depend on the requirements of the other network. Table 21 - Scenarios for the allocation of FEs to physical equipment for normal operation in the case of interworking with another network

Scenario 2

FE1

FE2

FE3

Other network

Terminating PINX

Gateway PINX

Terminating PINX

Scenario 3 Scenario 4

Originating TE

Originating PINX

Other network

Scenario 5

Originating TE

Originating PINX

Gateway PINX

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 E193-DOC.EXE) and as an Acrobat PDF file (file E193-PDF.PDF). File E193-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-193 is available free of charge in printed form and as a file. See inside cover page for instructions

ECMA-193 — Private Integrated Services Network (PISN) - Specification, functional model and information flows - Do not disturb and do not disturb override supplementary services (DND(O)SD) (June 1997)

Related documents