ConceptioArchiveECMA International
ECMA Internationalopen access

ECMA-175 — Private Integrated Services Network (PISN) - Specification, functional model and information flows - Path replacement additional network feature (ANF-PRSD) (December 1998)

ECMA International · ECMA International
ECMA International · Standards · License: Open Access
Open Source ↗Direct PDF ↓
additionalecmaecmainternationalfeatureflowsinformationintegratedmodel
ecma, standard, ecma international, specification, ecma-175, ecma 175, 175, private, integrated, services, network, pisn, functional, model, and, information, flows, path, replacement, additional, feature, anf-prsd

Standard ECMA-175 3rd E dition - De c e mber 1998

Standardizing

Information

and

Communication

Systems

Private Integrated Services Network (PISN) Specification, Functional Model and Information Flows Path Replacement Additional Network Feature

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-175 3rd E dition - De c e mber 1998

Standardizing

Information

and

Communication

Systems

Private Integrated Services Network (PISN) Specification, Functional Model and Information Flows Path Replacement Additional Network Feature (ANF-PRSD)

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-175.doc

06-01-99 14,20

.

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 ETSI work item DE/ECMA-00014. This particular Standard specifies the Path Replacement additional network feature. This Standard is based upon the practical experience of ECMA member companies and the results of their active and continuous participation in the work of ISO/IEC JTC1, ITU-T, ETSI and other international and national standardization bodies. It represents a pragmatic and widely based consensus. This ECMA Standard is technically aligned with the 2nd Edition International Standard ISO/IEC 13863:1998(E) published by ISO/IEC in December 1998.

Adopted as 3rd Edition of Standard ECMA-175 by the General Assembly of December 1998.

.

- i -

Table of contents 1 Scope

1

2 Conformance

1

3 References (normative)

1

4 Definitions

2

4.1 External definitions

2

4.2 Other definitions

2

4.2.1 Additional network feature

2

4.2.2 ANF-PR user

2

4.2.3 Call, basic call

2

4.2.4 Connection

2

4.2.5 New connection

3

4.2.6 Old connection

3

4.2.7 Trombone connection

3

5 List of acronyms

3

6 ANF-PR stage 1 specification

3

6.1 Description

3

6.1.1 General description

3

6.1.2 Qualifications on applicability to telecommunication services

3

6.2 Procedures

4

6.2.1 Provision/withdrawal

4

6.2.2 Normal procedures

4

6.2.3 Exceptional procedures

4

6.3 Interaction with other supplementary services and ANFs

4

6.3.1 Calling Line Identification Presentation (SS-CLIP)

4

6.3.2 Connected Line Identification Presentation (SS-COLP)

5

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

5

6.3.4 Calling Name Identification Presentation (SS-CNIP)

5

6.3.5 Connected Name Identification Presentation (SS-CONP)

5

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

5

6.3.7 Completion of Calls to Busy Subscriber (SS-CCBS)

5

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

5

6.3.9 Call Transfer (SS-CT)

5

6.3.10 Call Forwarding Unconditional (SS-CFU)

5

6.3.11 Call Forwarding Busy (SS-CFB)

5

6.3.12 Call Forwarding No Reply (SS-CFNR)

5

6.3.13 Call Deflection (SS-CD)

5

6.4 Interworking considerations

5

6.5 Overall SDL

6

- ii -

7 ANF-PR stage 2 specification - basic operation

7

7.1 Functional model

7

7.1.1 Functional model description

7

7.1.2 Description of the functional entities

7

7.1.3 Relationship of functional model to basic call functional model

7

7.2 Information flows

8

7.2.1 Definition of information flows

8

7.2.2 Relationship of information flows to basic call information flows

9

7.2.3 Examples of information flow sequences

9

7.3 Functional entity actions

12

7.3.1 Functional entity actions of FE1

12

7.3.2 Functional entity actions of FE2

12

7.4 Functional entity behaviour

12

7.4.1 Behaviour of FE1

13

7.4.2 Behaviour of FE2

14

7.5 Allocation of functional entities to physical equipment

15

7.6 Interworking considerations

15

8 ANF-PR stage 2 specification - re-use of connection elements

15

8.1 Functional model

15

8.1.1 Functional model description

15

8.1.2 Description of the functional entities

16

8.1.3 Relationship of functional model to basic call functional model

16

8.2 Information flows

17

8.2.1 Definition of information flows

17

8.2.2 Relationship of information flows to basic call information flows

17

8.2.3 Examples of information flow sequences

17

8.3 Functional entity actions

21

8.3.1 Functional entity actions of FE1

21

8.3.2 Functional entity actions of FE2

21

8.3.3 Functional entity actions of FE3

21

8.4 Functional entity behaviour

21

8.4.1 Behaviour of FE1

21

8.4.2 Enhanced behaviour of FE2

22

8.4.3 Behaviour of FE3

23

8.5 Allocation of functional entities to physical equipment

24

8.6 Interworking considerations

24

9 ANF-PR stage 2 specification - basic operation with inviting entity

24

9.1 Functional model

24

9.1.1 Functional model description

24

9.1.2 Description of the functional entities

24

9.1.3 Relationship of functional model to basic call functional model

24

9.2 Information flows

25

- iii -

9.2.1 Definition of information flows

25

9.2.2 Relationship of information flows to basic call information flows

26

9.2.3 Examples of information flow sequences

26

9.3 Functional entity actions

30

9.3.1 Functional entity actions of FE1´

30

9.3.2 Functional entity actions of FE2

30

9.3.3 Functional entity actions of FE4

30

9.4 Functional entity behaviour

30

9.4.1 Behaviour of FE1´

31

9.4.2 Behaviour of FE2

32

9.4.3 Behaviour of FE4

32

9.5 Allocation of functional entities to physical equipment

32

9.6 Interworking considerations

33

Annex A - Circumstances in which ANF-PR might be invoked

35

Annex B - Avoidance of unacceptable disruption to user information

37

- iv -

.

1

Scope This Standard specifies the Path Replacement additional network feature (ANF-PR), which is applicable to various basic services supported by Private Integrated Services Networks (PISN). Basic services are specified in ECMA-142. ANF-PR is a feature which applies to an established call, allowing that call's connection between Private Integrated Services Network Exchanges (PINXs) to be replaced by a new connection. If the new connection is required to satisfy certain criteria, ANF-PR should be used in conjunction with other supplementary services and/or ANFs. Annex A gives examples of the circumstances under which ANF-PR can be used and criteria which can govern the selection of the new connection. Additional network feature specifications are produced in three stages, according to the method described in ETS 300 387 for supplementary services. This Standard contains the stage 1 and stage 2 specifications of ANF-PR. The stage 1 specification (clause 6) specifies the feature as seen by an entity which initiates path replacement, the ANF-PR user. The stage 2 specification (clauses 7, 8 and 9) identifies the functional entities involved in the feature and the information flows between them. Clause 7 contains the stage 2 specification for basic operation of the feature. Clause 8 contains the stage 2 specification for an enhanced mode of working which can be employed when supported by all the equipment involved. It allows some of the elements of the old connection to be re-used. Clause 9 contains the stage 2 specification for an optional enhancement of the basic operation of the feature. It allows the ANF-PR user to be located in any PINX in the old connection and to decide the direction of the new connection.

2

Conformance In order to conform to this Standard, a stage 3 standard shall specify signalling protocols and equipment behaviour that are capable of being used in a PISN which supports the feature specified in this Standard. This means that, to claim conformance, a stage 3 standard is required to be adequate for the support of those aspects of clause 6 (stage 1) and clauses 7, 8 and 9 (stage 2) which are relevant to the interface or equipment to which the stage 3 standard applies.

3

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

Private Integrated Services Network - Reference Configuration for PISN Exchanges (PINX) (International Standard ISO/IEC 11579-1)

ECMA-142

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

ISO/IEC 11571

Information Technology - Telecommunication and information exchange between systems Numbering and sub addressing in Private Integrated Services Network

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)

- 2 -

4

Definitions For the purposes of this Standard, the following definitions apply.

4.1

External definitions Definitions This Standard uses the following terms defined in other documents:

 Basic service

(ITU-T Rec. I.210)

 Private Integrated Services Network (PISN)

(ECMA-133)

 Private Integrated Services Network Exchange (PINX)

(ECMA-133)

 Service

(ITU-T Rec. I.112)

 Signalling

(ITU-T Rec. I.112)

 Supplementary Service

(ITU-T Rec. I.210)

 User (except in the context of ANF-PR user)

(ECMA-142)

This Standard refers to the following basic call functional entities (FEs) defined in ECMA-142:

 Call Control (CC)  Call Control Agent (CCA) This Standard refers to the following basic call inter-FE relationships defined in ECMA-142:

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

 CHANNEL_ACKNOWLEDGE request/indication  RELEASE request/indication  RELEASE response/confirmation  SETUP request/indication  SETUP response/confirmation. This Standard refers to the following basic call information flow service element defined in ECMA-142:

 Destination Number. 4.2 4.2.1

Other definitions Additional network feature An additional network feature (ANF) is a capability, over and above that of a basic service, provided by a PISN, but not directly to a PISN user.

4.2.2

ANF-PR user An entity, within a PISN, that requests ANF-PR.

4.2.3

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

4.2.4

Connection As defined in ITU-T Rec. I.112, but limited to the case of providing for the transfer of signals between two PINXs.

- 3 -

NOTE 1 A connection between two PINXs can pass through zero or more Transit PINXs. 4.2.5

New connection The connection established by ANF-PR and used to replace all or part of the old connection.

4.2.6

Old connection The connection existing before ANF-PR is invoked.

4.2.7

Trombone connection A connection which has both its ends in the same PINX but which involves at least one Transit PINX.

5

List of acronyms

6

ANF

Additional Network Feature

ANF-PR

ANF Path Replacement

CC

Call Control (functional entity)

CCA

Call Control Agent (functional entity)

CID

Call Identity (information flow service element)

FE

Functional Entity

ISDN

Integrated Services Digital Network

PINX

Private Integrated Services Network Exchange

PISN

Private Integrated Services Network

PRE

Path Replacement Error (information flow)

PRI

Path Replacement Invite (information flow)

PRP

Path Replacement Propose (information flow)

PRR

Path Replacement Re-use (information flow)

PRRR

PRR Result (information flow service element)

PRS

Path Replacement Setup (information flow)

PRSR

PRS Result (information flow service element)

RN

Rerouteing Number (information flow service element)

SDL

Specification and Description Language

ANF-PR stage 1 specification

6.1 6.1.1

Description General description ANF-PR is invoked by an ANF-PR user for an established call, allowing that call's connection through the PISN to be replaced by a new connection. The direction of the new connection may be decided by the ANF-PR user. If the new connection is required to satisfy certain criteria, ANF-PR should be used in conjunction with other supplementary services and/or ANFs. Annex A gives examples of the circumstances under which ANF-PR can be used and criteria which can govern the selection of the new connection.

6.1.2

Qualifications on applicability to telecommunication services This additional network feature is applicable to all basic services defined in ECMA-142.

- 4 -

NOTE 2 For certain teleservices or certain applications of certain basic bearer services the changeover from the old connection to the new connection can cause unacceptable disruption. See annex B.

6.2

Procedures

6.2.1

Provision/withdrawal This ANF shall be PISN instigated. NOTE 3 Means can be provided for preventing the use of ANF-PR for applications where the changeover from the old connection to the new connection is likely to cause unacceptable disruption. See annex B.

6.2.2

Normal procedures

6.2.2.1

Activation/deactivation/registration/interrogation The feature shall be permanently activated.

6.2.2.2

Invocation and operation Invocation shall be on request from an ANF-PR user and shall be permitted only after a call has reached the active state. As an implementation option, the ANF-PR user may indicate the direction of the new connection. On invocation an attempt shall be made to establish a new connection between the users. In the absence of specific criteria, the new connection shall be established using the routeing rules which apply to basic call establishment. If the new connection is successfully established it shall be used to replace the old connection, which shall be released. Changeover from the old connection to the new connection should be done in a manner which minimises disruption to user information. NOTE 4 The means of specifying criteria and ensuring that the new connection satisfies those criteria can involve the use of another ANF or supplementary service, which can be either standardized or manufacturer specific. In some circumstances it may be possible to re-use some elements of the old connection, so that only part of the old connection has to be replaced by a new connection, subject to the given criteria being achievable in that way.

6.2.3

Exceptional procedures

6.2.3.1

Activation/deactivation/registration/interrogation Not applicable.

6.2.3.2

Invocation and operation If it is not possible to establish a new connection, the call shall continue to use the old connection and any resources reserved for the new connection shall be released. There shall be no disruption to user information. In the event of two ANF-users (at opposite ends of the connection) requesting the feature simultaneously, both requests shall be rejected. NOTE 5 An ANF-PR user can request the feature again later in the event of failure. In the case of failure due to simultaneous requests, care should be taken to avoid a repeat occurrence, e.g., by use of a random delay.

6.3

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

6.3.1

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

- 5 -

6.3.2

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

6.3.3

Calling/connected Line Identification Restriction (SS-CLIR) No interaction.

6.3.4

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

6.3.5

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

6.3.6

Calling/connected Name Identification Restriction (SS-CNIR) No interaction.

6.3.7

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

6.3.8

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

6.3.9

Call Transfer (SS-CT) If call transfer occurs while ANF-PR is in progress, ANF-PR shall be aborted. ANF-PR can apply to a call which has been transferred. The fact that transfer has occurred can be a reason for invoking ANF-PR (see annex A).

6.3.10

Call Forwarding Unconditional (SS-CFU) ANF-PR can apply to a call which has been forwarded.

6.3.11

Call Forwarding Busy (SS-CFB) ANF-PR can apply to a call which has been forwarded.

6.3.12

Call Forwarding No Reply (SS-CFNR) ANF-PR can apply to a call which has been forwarded.

6.3.13

Call Deflection (SS-CD) ANF-PR can apply to a call which has been deflected.

6.4

Interworking considerations The requirements below apply to both incoming calls and outgoing calls. It shall be possible to use ANF-PR on the PISN part of the connection. The new connection through the PISN shall replace the old connection through the PISN. When interworking with another network which supports an equivalent feature, it may be possible to cooperate with the other network in order to replace the entire connection.

- 6 -

6.5

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

ID L E

I n it i a t e A N F -P R

E s t a b lis h new c o n n e c t io n

S u c c e s f u l?

N

Y S w it c h t o new c o n n e c ti o n

R e le a s e o l d c o n n e c ti o n

R e le a s e a n y re s o u rc e s fo r n e w c o n n e c t io n

A N F -P R U n s u c c e s s fu l

A N F -P R s u c c e s s fu l

ID L E

Figure 1 - ANF-PR, overall SDL

- 7 -

7

ANF-PR stage 2 specification - basic operation Clause 7 contains the stage 2 for ANF-PR restricted to supporting the request for ANF-PR from end PINXs in a call. An optional extension to ANF-PR is documented in clause 9 which contains the stage 2 for ANF-PR whereby the request for ANF-PR can be done by any PINX in the connection.

7.1

Functional model

7.1.1

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

Path Replacement Destination;

FE2

Path Replacement Source.

The following functional relationship shall exist between these FEs: rx

between FE1 and FE2

Figure 2 shows these FEs and this relationship.

PR DESTINATION

PR SOURCE rx

FE1

FE2

Figure 2 - Functional model for ANF-PR 7.1.2 7.1.2.1

Description of the functional entities Path replacement destination functional entity, FE1 This functional entity receives a request from ANF-PR user to initiate ANF-PR and instructs FE2 to attempt to establish a new connection back towards FE1 If the new connection is successfully established, FE1 switches to the new connection and awaits the release of the old connection.

7.1.2.2

Path replacement source functional entity, FE2 On receipt of instruction from FE1 and if able to proceed with ANF-PR, this functional entity initiates the establishment of a new connection back towards FE1. If the new connection is successfully established, FE2 switches to the new connection and initiates release of the old connection.

7.1.3

Relationship of functional model to basic call functional model During successful invocation of ANF-PR, the Transit CCs, if any, involved in the old connection shall be replaced by the Transit CCs, if any, involved in the new connection. The Originating and Terminating CCs shall remain. For the case of a call originating and terminating within the PISN, ANF-PR functional entities shall be related to basic call functional entities as follows:

 FE1 shall be collocated with the Originating CC or the Terminating CC, depending on the location of the ANF-PR user;

 FE2 shall be collocated with the Terminating CC if FE1 is collocated with the Originating CC, or with the Originating CC if FE1 is collocated with the Terminating CC. Figure 3 shows an example of the relationship between the model for ANF-PR and the model for the basic call. This example is used as the basis of the information flow sequences in 7.2.3. NOTE 6 The number of Transit CCs on the new connection can differ from the number on the old connection.

- 8 -

CC r2 r1

CCA

CC

r2

r2 Old Connection

r2

CC

CC r2

CC

r2

New Connection

CC

r3

CCA

FE2

FE1 rx

Figure 3 - Example relationship between models for ANF-PR and basic call

7.2

Information flows

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

7.2.1.1

PRP (Path Replacement Propose) PRP is an unconfirmed information flow across rx from FE1 to FE2 which proposes path replacement to FE2. PRP request/indication is sent using the signalling path of the old connection. Table 1 lists the service elements within the PRP information flow. Table 1 - Content of PRP Service element

Request

Rerouteing Number (RN)

M

Call Identity (CID)

M

Service element RN shall always be included in the PRP request/indication information flow at rx. It shall contain a number from one of the native numbering plans of the PISN (see ISO/IEC 11571). The number shall be suitable for use for routeing the new connection to the physical location where FE1 resides. Service element CID shall always be included in the PRP request/indication information flow at rx. It shall contain a number which, in conjunction with the number in service element RN, identifies the particular FE1, and therefore the call on which ANF-PR is being invoked. This number need not have significance outside the physical location where FE1 resides. 7.2.1.2

PRS (Path Replacement Setup) PRS is a confirmed information flow across rx from FE2 to FE1 which indicates to FE1 that the new connection being established is for the purpose of path replacement. The response indicates whether FE1 has successfully correlated the new connection with the old connection and is prepared to switch to the new connection. PRS request/indication and PRS response/confirmation are sent using the signalling path of the new connection at the time of establishment of that connection. Table 2 lists the service elements within the PRS information flow.

- 9 -

Table 2 - Content of PRS Service element

Request

Confirm

Call Identity (CID)

M

-

PRS Result (PRSR)

-

M

Service element CID shall always be included in the PRS request/indication information flow at rx. It shall contain the value received in the corresponding service element of the PRP request/indication information flow. Service element PRSR shall always be included in the PRS response/confirmation information flow at rx. It indicates whether the request was successful, and if not the reason for failure. 7.2.1.3

PRE (Path Replacement Error) PRE is an unconfirmed information flow across rx from FE2 to FE1 which indicates to FE1 that path replacement has failed. Table 3 lists the service element within the PRE information flow. Table 3 - Content of PRE

7.2.2

Service element

Request

Reason for failure

M

Relationship of information flows to basic call information flows The PRS request/indication information flow shall be sent in conjunction with the basic call information flow Setup request/indication for the new connection sent across basic call relationship r2. Service element Destination Number of information flow Setup request/indication shall contain the number provided in service element RN of information flow PRP request/indication. The PRS response/confirmation information flow shall be sent in conjunction with the basic call information flow Setup response/confirmation for the new connection across basic call relationship r2. Failure to establish the new connection shall result in the initiation of its release using basic call information flow Release request/indication across relationship r2. Successful switch over to the new connection shall result in the initiation of the release of the old connection using basic call information flow Release request/indication across relationship r2.

7.2.3

Examples of information flow sequences A stage 3 standard for ANF-PR 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, ANF-PR information flows are represented by solid arrows and basic call information flows are represented by broken arrows. An ellipse embracing two information flows indicates that the two information flows occur simultaneously. Within a column representing an ANF-PR functional entity, the numbers refer to functional entity actions listed in 7.3. The following abbreviations are used: req

request

ind

indication

res

response

con

confirmation

- 10 -

7.2.3.1

Normal operation of ANF-PR Figure 4 shows the information flow sequence for normal operation of ANF-PR.

rx

FE2

FE1 r2

CC

CC

r2

CC

CC

O ld C onn ectio n

O ld C onn ectio n

O ld C onn ectio n

r2

PRP req/ind

101

r2

r2

CC N ew C onn ection

N ew C onn ection

SET UP

SET UP

req/ind

req/ind

CC

r2 N ew C onn ection

SET U P 201 req/ind

PRS req/ind

102

SET UP

S ET UP

SE T UP

res/con

res/con

SET U P

PRS res/con

r2 O ld C onn ectio n

103

202

r2

r2

CC

CC O ld C onn ectio n

O ld C onn ectio n

R EL E AS E

R EL E AS E

R EL E AS E

req/ind

req/ind

req/ind

NOTE For simplicity, basic call information flows Channel_Acknowledge request/indication and Release response/confirmation are not shown. Figure 4 - Information flow sequence - normal operation of ANF-PR

- 11 -

7.2.3.2

Failure to establish new connection Figure 5 shows the information flow sequence when establishment of the new connection fails. rx

FE1

FE2 r2

CC

r2 CC

r2 CC

O ld C o n n e ctio n

O ld C o n n e c tio n

CC O ld C o n n e ctio n

PRP re q /in d

101

r2

CC

N e w C o n n e c tio n

SET UP re q /in d

201

PRS re q /in d (n o te ) R ELE AS E re q /in d R ELE AS E

re s/co n

r2 O ld C o n n e c tio n

CC

r2 O ld C o n n e ctio n

CC

r2 O ld C o n n e ctio n

PRE

203 104

re q /in d

NOTE Because of failure to establish the new connection, the PRS request/-indication will not reach FE1. Figure 5 - Information flow sequence - failure to establish new connection

- 12 -

7.3

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

7.3.1

Functional entity actions of FE1 101

On receipt of a request from ANF-PR user, obtain Rerouteing Number and Call Identity, and include in PRP request/indication to FE2.

102

On receipt of PRS request/indication (in conjunction with basic call Setup request/indication): correlate new connection with old connection; switch over to the user information channel of the new connection; terminate the user information channel of the old connection in a suitable manner (pending its release); stimulate the sending of a basic call Setup response/confirmation; and return with it a PRS response/confirmation.

NOTE 7 The method of terminating the old connection's user information channel is an implementation matter. See also annex B.

7.3.2

103

On receipt of an indication from the local CC that the old connection has been released, indicate successful completion of ANF-PR to the ANF-PR user.

104

On receipt of PRE request/indication, terminate ANF-PR and retain the old connection. Depending on the reason for failure, indicate to the ANF-PR user whether it is worthwhile invoking again later.

Functional entity actions of FE2 201

On receipt of PRP request/indication, check that ANF-PR is allowed and stimulate the establishment of a new connection. In conjunction with basic call SETUP request/indication, send PRS request/indication to FE1. Terminate the new connection's user information channel suitably.

NOTE 8 The method of terminating the new connection's user information channel is an implementation matter. See also annex B.

7.4

202

On receipt of PRS response/confirmation indicating success (in conjunction with basic call Setup response/confirmation), switch over to the new connection. Disconnect the old user information channel and initiate release of the old connection. Terminate ANF-PR.

203

On inability to accept the PRP request/indication, failure to establish the new connection, or receipt of PRS response/confirmation indicating failure (in conjunction with basic call Release request/indication), send PRE request/indication to FE1 and terminate ANF-PR.

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

- 13 -

7.4.1

Behaviour of FE1 Figure 6 shows the normal behaviour of FE1. Input signals from the right and output signals to the right represent information flows from and to FE2 and from the local basic call CC. Input signals from the left and output signals to the left represent primitives from and to the ANF-PR user.

F E 1 - I d le

I n it ia t e A N F -P R

O b ta i n R N a n d C ID

P R P r e q / in d ( o ld c o n n e c t io n )

FE1P r o p o s in g

P R E r e q / in d ( o ld c o n n e c t io n )

P R S r e q / in d (n e w c o n n e c t io n )

A s s o c i a t e w it h o ld c o n n e c tio n

N OK?

Y S w it c h t o n e w u s e r in f o r m a t io n chann el

P R S re s /c o n R e s u lt = s u c c e s s fu l

R e le a s e n e w c o n n e c t io n s

P R S re s /c o n R e s u lt = F a ll e d

F E 1 - S w it c h e d

F E 1 - R e je c tin g

O ld c o n n e c t io n r e le a s e d ( fr o m l o c a l C C )

P R E r e q / in d ( o ld c o n n e c tio n )

A N F -P R S u c c e s s fu l

A N F -P R U n s u c c e s s fu l

F E 1 - i d le

Figure 6 - ANF-PR, SDL for functional entity FE1

B a s ic c a ll r e le a s e d

- 14 -

7.4.2

Behaviour of FE2 Figure 7 shows the normal behaviour of FE2. Input signals from the left and output signals to the left represent information flows from and to FE1. Input signals from the right represent indications from the local CC.

FE2-Idle

PRP req/ind (old connection)

N

Able to proceed?

e.g. because of collision of ANF-PR requests Y PRS req/ind (establish new connection)

FE2-Routeing

PRS res/con Result = successful

PRS res/con Result=failed

new connection established

Failure to establish new connection

Basic call released

new connection released Release new connection Switch to new user information channel

Release old connection

PRE req/ind

FE2-Idle

Figure 7 - ANF-PR, SDL for functional entity FE2

- 15 -

7.5

Allocation of functional entities to physical equipment The allocations of FEs to physical equipment shown in table 4 shall apply. FE1 shall be located at either End PINX, depending on where the need for invoking ANF-PR arises. This will depend on the application. In the case of a trombone connection, the Originating PINX or Incoming Gateway PINX will be the same PINX as the Terminating PINX or Outgoing Gateway PINX. Therefore FE1 and FE2 will be collocated and the new connection and those information flows sent using the signalling path of the new connection will be intra-PINX. Information flow PRP request/indication sent using the signalling path of the old connection will enable FE2 to determine that FE1 is collocated. Table 4 - Scenarios for the allocation of FEs to physical equipment FE1

FE2

Scenario 1

Originating PINX

Terminating PINX

Scenario 2

Originating PINX

Outgoing Gateway PINX (note)

Scenario 3

Incoming Gateway PINX (note)

Terminating PINX

Scenario 4

Incoming Gateway PINX (note)

Outgoing Gateway PINX (note)

Scenario 5

Terminating PINX

Originating PINX

Scenario 6

Terminating PINX

Incoming Gateway PINX (note)

Scenario 7

Outgoing Gateway PINX (note)

Originating PINX

Scenario 8

Outgoing Gateway PINX (note)

Incoming Gateway PINX (note)

NOTE - When interworking with another network which supports an equivalent feature, FE1 or FE2 may be located in that other network, thereby permitting replacement of the entire connection.

7.6

Interworking considerations When interworking with another network which does not support an equivalent feature, the FEs for ANF-PR shall be located within PINXs, in accordance with 7.5. All information flows will be internal to the PISN. When interworking with another network which supports an equivalent feature, the two networks may cooperate in the operation of ANF-PR. In this case, either FE1 or FE2 will be located in the other network and the information flows within the PISN will map on to equivalent information flows in the other network.

8

ANF-PR stage 2 specification - re-use of connection elements The enhanced functional breakdown of the feature as specified in this clause allows the possibility of re-using some elements of the old connection, so that only part of the old connection has to be replaced by a new connection.

8.1 8.1.1

Functional model Functional model description The functional model shall be as specified in 7.1.1 for basic operation, but with the addition of one or more instances of FE "Path Replacement Re-use" (FE3). The functionality of FE2 is enhanced. Additional relationship rz shall exist between FE1 and the adjacent instance of FE3. Additional relationship ry shall exist between adjacent instances of FE3 and between FE2 and the adjacent instance of FE3. See figure 8.

- 16 -

PR DESTINATION rz

FE1

PR SOURCE

PR RE-USE

PR RE-USE ry

FE3

ry

FE3

FE2

rx

Figure 8 - Functional model for enhanced operation of ANF-PR 8.1.2 8.1.2.1

Description of the functional entities Path replacement destination functional entity, FE1 7.1.2.1 shall apply.

8.1.2.2

Path replacement source functional entity, FE2 The functions of FE2 are as specified in 7.1.2.2 with the following enhancement. FE2 determines whether the existing element of the old connection as far as the next CC can be re-used, and if so instructs an instance of FE3 located at the next CC to establish and switch to the new connection.

8.1.2.3

Path replacement re-use functional entity, FE3 On receipt of instruction from FE2 or an intervening FE3, this functional entity initiates the establishment of a new connection back towards FE1. If the new connection is successfully established, FE3 connects the re-used connection element from FE2 to the new connection and initiates release of the unwanted parts of the old connection. FE3 determines whether the existing element of the old connection as far as the next CC can be re-used, and if so instructs a further instance of FE3 located at the next CC to establish and switch to the new connection.

8.1.3

Relationship of functional model to basic call functional model 7.1.3 shall apply with the following modifications. During successful invocation of ANF-PR with re-use of some or all of the elements of the old connection, the Transit CCs in that part of the old connection which is not re-used are replaced by the Transit CCs, if any, involved in the new connection. Other Transit CCs, including the one from which the new connection starts, are retained, and each has a collocated FE3. Figure 9 shows an example of the relationship between the model for ANF-PR and the model for the basic call. In this example elements of the old connection are re-used from FE2 as far as the first Transit CC. This example is used as the basis of the information flow sequences in 8.2.3. Old connection r2

r2 CC

New connection CCA

r1

CC

r2

CC

r2

CC

r2

CC

r3

CCA

ry

r2

FE3

FE1

FE2

rx

Figure 9 - Example relationship between models for ANF-PR and basic call - re-use of part of the old connection

- 17 -

8.2

Information flows

8.2.1 8.2.1.1

Definition of information flows PRP (Path Replacement Propose) 7.2.1.1 shall apply.

8.2.1.2

PRS (Path Replacement Setup) 7.2.1.2 shall apply, with the exception that information flow PRS shall occur across relationship rz instead of rx.

8.2.1.3

PRE (Path Replacement Error) 7.2.1.4 shall apply.

8.2.1.4

PRR (Path Replacement Re-use) PRR is a confirmed information flow across ry from FE2 or FE3 to the next FE3. It instructs the next FE3 to establish and switch to a new connection, elements of the old connection as far as that next FE3 being re-used. The response indicates whether a new connection has been successfully established and switched to. PRR request/indication and PRR response/confirmation are sent using the signalling path of the old connection. Table 5 lists the service elements within the PRR information flow. The column headed "Request" indicates which of these service elements are mandatory (M) and which are optional (O) in a PRR request/indication information flow. The column headed "Confirm" indicates which of these service elements are mandatory (M) and which are optional (O) in a PRR response/confirmation information flow. Table 5 - Content of PRR Request

Confirm

Rerouteing Number (RN)

M

-

Call Identity (CID)

M

-

PRR Result (PRRR)

-

M

Service element

Service element RN shall always be included in the PRR request/indication information flow at ry. It shall contain the number sent to FE2 in service element RN of the PRP request/indication information flow. Service element CID shall always be included in the PRR request/indication information flow at ry. It shall contain the value received in the corresponding service element of the PRP request/indication information flow. Service element PRRR shall always be included in the PRR response/confirmation information flow at ry. It indicates whether the request was successful, and if not the reason for failure. 8.2.2

Relationship of information flows to basic call information flows 7.2.2 shall apply.

8.2.3

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

- 18 -

8.2.3.1

Normal operation of ANF-PR with re-use of part of old connection Figure 10 shows the information flow sequence for normal operation of ANF-PR when that part of the old connection up to the first Transit CC is re-used. The new connection starts at the first Transit CC, at which an instance of FE3 is located.

rx rz

FE1 r2

CC

CC

FE3 r2

CC

ry

FE2

r2

CC

Old Connection

Old Connection

PRP req/ind

101

r2 New Connection

CC

r2 New Connection PRR req/ind

SET UP req/ind

SET UP req/ind

PRS req/ind

102

SET UP

SET UP

res/con

res/con

204

301

PRS res/con

r2 Old Connection

103

RELEASE req/ind

CC

r2 Old Connection

302

PRR res/con

205

RELEASE req/ind

NOTE For simplicity, basic call information flows Channel_Acknowledge request/indication and Release response/confirmation are not shown. Figure 10 - Information flow sequence - normal operation of ANF-PR with re-use of part of old connection

- 19 -

8.2.3.2

Failure to establish new connection to replace part of old connection Figure 11 shows the information flow sequence when establishment of a new connection to replace part of the old connection fails. The new connection attempt is from the first Transit CC, at which an instance of FE3 is located.

rx rz

FE1 r2

CC

CC

FE3 r2

CC

ry

FE2

r2

CC

Old Connection

Old Connection

PRP req/ind

101

r2 New Connection

CC

r2 New Connection

SET UP req/ind

PRR req/ind

204

301

PRS req/ind (note 1) R ELEASE req/ind R ELEASE res/con

r2 Old Connection

CC

303

PRR res/con

r2 Old Connection

PRE

206

req/ind (note 2)

104

NOTE 1 Because of failure to establish the new connection, the PRS request/indication will not reach FE1. NOTE 2 Because of failure to establish the new connection, PRE request/indication is sent . Alternatively FE2 may revert to basic operation and attempt to establish a new connection without re-use of part of the old connection. Figure 11 - Information flow sequence - failure to establish new connection to replace part of old connection

- 20 -

8.2.3.3

Retention of all of the old connection Figure 12 shows the information flow sequence for operation of ANF-PR when an attempt is made to re-use the old connection as far as the CC where FE1 is located. This can arise only if the old connection already meets the criteria for the new connection. The old connection is retained and ANF-PR is deemed to have terminated successfully. An FE3 occurs at each Transit CC and at the CC where FE1 is located.

rx

FE1

ry

FE3

FE3

r2

CC

CC

ry

r2

FE3 CC

ry

FE2

r2

CC

Old Connection

Old Connection

PRP 101

req/ind

PRR PRR

304

req/ind

PRR req/ind

204

304

req/ind 306 PRR res/con 305

PRR res/con 305

PRR res/con

Figure 12 - Information flow sequence - retention of all of the old connection

205

- 21 -

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 7.3.1 shall apply.

8.3.2

Functional entity actions of FE2 7.3.2 shall apply. In addition, the following actions shall apply.

8.3.3

204

On receipt of PRP request/indication, check that ANF-PR is allowed and discover that the old connection can be re-used as far as the next CC. Send PRR request/indication to FE3.

205

On receipt of PRR response/confirmation indicating success, terminate ANF-PR.

206

On inability to accept the PRP request/indication or receipt of PRR response/confirmation indicating failure, send PRE request/indication to FE1 and terminate ANF-PR. Alternatively, on receipt of PRR response/confirmation indicating failure, attempt path replacement without re-use of elements of the old connection (action 201).

Functional entity actions of FE3 301

On receipt of PRR request/indication from FE2 or the previous FE3, check that ANF-PR is allowed and initiate the establishment of a new connection. In conjunction with basic call SETUP request/indication, send PRS request/indication to FE1. Terminate the new connection's user information channel suitably.

NOTE 9 The method of terminating the new connection's user information channel is an implementation matter. See also annex B.

8.4

302

On receipt of PRS response/confirmation indicating success (in conjunction with basic call Setup response/confirmation), switch over to the new connection and send a PRR response/confirmation to FE2 or the previous FE3. Initiate release of the unwanted part of the old connection and terminate ANF-PR.

303

On inability to accept the PRR request/indication, failure to establish the new connection, or receipt of PRS response/confirmation indicating failure (in conjunction with basic call Release request/indication), send PRR response/confirmation indicating failure to FE2 or the previous FE3 and terminate ANF-PR.

304

On receipt of PRR request/indication from FE2 or the previous FE3, check that ANF-PR is allowed and discover that the old connection can be re-used as far as the next CC. Send PRR request/indication to the next FE3.

305

On receipt of PRR response/confirmation from the next FE3, send PRR response/confirmation indicating success to FE2 or the previous FE3

306

On receipt of a PRR request/indication from FE2 or a previous FE3, if this FE3 is collocated with FE1 (i.e., the old connection has been found to satisfy the given criteria) send a PRR response/confirmation indicating success to FE2 or the previous FE3 and terminate ANF-PR.

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 7.4.1 is applicable.

- 22 -

8.4.2

Enhanced behaviour of FE2 Figure 13 shows the enhanced behaviour of FE2. Input signals from the left and output signals to the left represent information flows from and to FE3 (where stated) and FE1 (otherwise). Input signals from the right represent indications from the local CC.

FE2-Idle

PRP req/ind (old connection)

Able to proceed?

N

Y

Y

Able to re-use old connection to next CC?

N

PRR res/con (from FE3) Result=success

PRR req/ind (to FE3)

PRS req/ind (establish new connection)

FE2 Re-Use Attempled

FE2-Routeing

PRS res/con Result = successful

PRR res/con from FE3 Result=failed

Able to establish new connection instead?

Failure to establish new connection

Y

Release new connection

N PRE req/ind

Basic call released

New connection established

New connection established Basic call released

PRS res/con Result=failed

Switch to new user information channel

PRE req/ind

Release old connection

FE2-Idle

Figure 13 - ANF-PR, SDL for enhanced functional entity FE2

- 23 -

8.4.3

Behaviour of FE3 Figure 14 shows the behaviour of FE3. Input signals from the left and output signals to the left represent information flows from and to the next FE3 (where stated) and FE1 (otherwise). Input signals from the right and output signals to the right represent information flows from and to FE2 or the previous FE3 and indications from the local CC.

FE3-Idle

PRR req/ind

Able to proceed?

N

Y

Y

Able to re-use old connection to next CC?

N

PRR res/con (from next FE3) Result=success

PRR res/con Result= successful

PRR req/ind (to next FE3)

PRS req/ind (establish new connection)

FE3 Re-Use Attempted

FE3-Routeing

PRR res/con (from FE3) Result=Failed

PRS res/con Result= successful new connection established

Able to establish new connection instead?

N Basic call released

PRR res/con Result= failed

Y

PRS res/con Result=failed

Failure to establish new connection

Basic call released

new connection established Release new connection

Switch to new user information channel

Release old connection

PRR res/con Result=failed

PRR res/con Result= successful

FE3-Idle

Figure 14 - ANF-PR, SDL for functional entity FE3

- 24 -

8.5

Allocation of functional entities to physical equipment 7.5 shall apply with the following enhancement. An instance of FE3 shall be located at the Transit PINX at which the new connection starts and at each Transit PINX between that PINX and FE2.

8.6

Interworking considerations 7.6 shall apply. If FE2 is located in another network which supports the re-use of elements of the old connection, an FE3 can be located at the Gateway PINX.

9

ANF-PR stage 2 specification - basic operation with inviting entity Clause 9 contains an optional extension of the stage 2 for ANF-PR in which the request for ANF-PR can be from any PINX in the connection.

9.1

Functional model

9.1.1

Functional model description The functional model shall comprise the following functional entities: FE1´ Path Replacement Destination; FE2

Path Replacement Source.

FE4

Path Replacement Invitation.

The following functional relationship shall exist between these FEs: rx

between FE1’ and FE2

rw

between FE4 and FE1´.

Figure 15 shows these FEs and this relationship.

PR INVITATION

PR DESTINATION rw

FE1 FE4

FE1’

PR SOURCE rx

FE2

Figure 2 Figure 15 - Functional model for ANF-PR 9.1.2 9.1.2.1

Description of the functional entities Path replacement destination functional entity, FE1´ 7.1.2.1 shall apply with the exception that FE1´ receives the request from FE4 instead of the ANF-PR user.

9.1.2.2

Path replacement source functional entity, FE2 7.1.2.2 shall apply.

9.1.2.3

Path replacement invitation functional entity, FE4 This functional entity receives a request from the ANF-PR user and invites FE1´ to initiate ANF-PR.

9.1.3

Relationship of functional model to basic call functional model During successful invocation of ANF-PR, the Transit CCs, if any, involved in the old connection shall be replaced by the Transit CCs, if any, involved in the new connection. The Originating and Terminating CCs shall remain.

- 25 -

For the case of a call originating and terminating within the PISN, ANF-PR functional entities shall be related to basic call functional entities as follows:

 FE1´ shall be collocated with the Originating CC or the Terminating CC.  FE2 shall be collocated with the Terminating CC if FE1´ is collocated with the Originating CC, or with the Originating CC if FE1´ is collocated with the Terminating CC.

 FE4 may be collocated with any CC in the connection. Figure 16 shows an example of the relationship between the model for ANF-PR and the model for the basic call. This example is used as the basis of the information flow sequences in 9.2.3. NOTE 10 The number of Transit CCs on the new connection can differ from the number on the old connection.

CC r2 r1

CCA

r2

CC

CC FE1’

r2 New Connection

r2 Old Connection

CC r2 r2

CC

CC

r3

CCA

rw

FE2

FE4 rx

Figure 3

Figure 16 - Example relationship between models for ANF-PR and basic call

9.2

Information flows

9.2.1

Definition of information flows 7.2.1 shall apply.

9.2.1.1

PRP (Path Replacement Propose) 7.2.1.1 shall apply.

9.2.1.2

PRS (Path Replacement Setup) 7.2.1.2 shall apply.

9.2.1.3

PRI (Path Replacement Invite) PRI request/indication is an unconfirmed information flow across rw from FE4 to FE1´ which indicates that ANF-PR shall be invoked at FE1´. PRI is sent towards FE1´ using the signalling path of the existing connection. Table 6 lists the service element within the PRI information flow. Table 6 - Content of PRI

9.2.1.4

Service element

Request

Call Identity (CID)

M

PRE (Path Replacement Error) 7.2.1.3 shall apply.

9.2.1.5

PRIF (Path Replacement Invite Failure) PRIF is an unconfirmed and optional information flow across rw from FE1´ to FE4 which indicates to FE4 that path replacement has failed.

- 26 -

Table 7 lists the service element within the PRIF information flow. Table 7 - Content of PRIF

9.2.2

Service element

Request

Reason for failure

M

Relationship of information flows to basic call information flows 7.2.2 shall apply. The PRI information flow is not related to any basic call information flow.

9.2.3

Examples of information flow sequences 7.2.3 shall apply.

- 27 -

9.2.3.1

Normal operation of ANF-PR Figure 17 shows the information flow sequence for normal operation of ANF-PR.

rx

rw

FE1’ CC

r2

CC

Old Connection

FE4 r2

FE2 r2

CC

Old Connection

PRI req/ind

Old Connection

r2

CC

Old Connection

CC

401

101

PRP req/ind r2

r2

CC

New Connection

r2

CC

New Connection

New Connection

SETUP req/ind

SETUP req/ind

SETUP req/ind

201

PRS req/ind

102

SET UP

SET UP

SET UP

res/con

res/con

SET UP

PRS res/con

202

FE4 r2 Old Connection

103

RELEASE req/ind

CC

r2 Old Connection

RELEASE req/ind

CC

403

r2 Old Connection

RELEASE req/ind

CC

r2 Old Connection

RELEASE req/ind

NOTE For simplicity, basic call information flows Channel_Acknowledge request/indication and Release response/confirmation are not shown. Figure 17 - Information flow sequence - normal operation of ANF-PR

- 28 -

9.2.3.2

Failure to establish new connection - immediate rejection Figure 18 shows the information flow sequence for immediate rejection of ANF-PR.

rx rw

FE1´ CC

r2

r2 Old Connection

105

FE2

FE4

PRIF req/ind

CC

Old Connection PRI req/ind

CC

r2 CC

Old Connection

Old Connection

401

402

Figure 18 - Information flow sequence - failure to establish new connection

CC

- 29 -

9.2.3.3

Failure to establish new connection - during ANF-PR execution Figure 19 shows the information flow sequence when establishment of the new connection fails.

rx rw

FE1´

r2

r2

CC

FE2

FE4

Old Connection

CC

Old Connection PRI req/ind

CC

Old Connection

r2 CC

Old Connection

CC

401

101 PRP req/ind

CC

r2 New Connection SETUP req/ind

201

PRS req/ind (NOTE) RELEASE req/ind RELEASE res/con

r2 Old Connection

CC

r2 Old Connection

Old Connection

CC

r2 Old Connection

PRE req/ind

104 PRIF req/ind

203

402

NOTE Because of failure to establish the new connection, the PRS request/-indication will not reach FE1´. Figure 19 - Information flow sequence - failure to establish new connection

- 30 -

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

Functional entity actions of FE1´ 101

On receipt of a PRI request/-indication from FE4, obtain Rerouteing Number and Call Identity, and include in PRP request/indication to FE2.

102

Procedure 102 in 7.3.1 and Note 7 shall apply.

103

On receipt of an indication from the local CC that the old connection has been released, treat ANF-PR as successfully completed.

104

On receipt of PRE request/indication, terminate ANF-PR and retain the old connection. Depending on the reason for failure optionally inform FE4 in a PRIF request/indication.

105

If FE1´ does not accept the invitation it may optionally inform FE4 about the reason by sending a PRIF request/-indication.

NOTE 11 One reason for rejection may be that ANF-PR is in progress already. 9.3.2

Functional entity actions of FE2 7.3.2 shall apply.

9.3.3

9.4

Functional entity actions of FE4 401

On receipt of a request from the ANF-PR user send the PRI request/-indication to FE1´.

402

On receipt of a PRIF request/indication, terminate ANF-PR. Depending on the reason for failure, indicate to the ANF-PR user whether it is worthwhile invoking again later.

403

On receipt of an indication from the local CC that the old connection has been released, indicate successful completion of ANF-PR to the ANF-PR 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).

- 31 -

9.4.1

Behaviour of FE1´ Figure 20 shows the normal behaviour of FE1´. Input signals from the right and output signals to the right represent information flows from and to FE2 and from the local basic call CC. Input signals from the left and output signals to the left represent information flows from and to FE4.

FE1’-Idle

PRI req/ind (old connection)

FE1’-Any except idle

N PR Possible ?

PRI req/ind (old connection)

Y Obtain RN and CID

PRIF req/ind (not possible)

PRIF req/ind (not possible)

PRP req/ind (old connection)

FE1’-Idle

FE1’ Any except idle

FE1’Proposing

PRE req/ind (old connection)

PRS req/ind (new connection)

Basic call released

Associate with old connection

N OK?

Y Switch to new user information channel

Release new connections

PRS res/con Result = successful

PRS res/con Result=Failed

FE1’-Switched

FE1’-Rejecting

Old connection released (from local CC)

PRE req/ind (old connection)

PRIF req/ind (old connection)

FE1’-idle

Figure 20 - ANF-PR, SDL for functional entity FE1´

- 32 -

9.4.2

Behaviour of FE2 7.4.2 shall apply with the exception that input signals from the left and output signals to the left represent information flows from and to FE1´.

9.4.3

Behaviour of FE4 Figure 21 shows the normal behaviour of FE4. Input signal from the left and output signals to the left represent primitives from and to the ANF-PR user. Input signals from the right and output signals to the right represent information flows from and to FE1´ and from and to the basic call CC.

FE4_Idle

PR_invite

PRIF req/ind

old connection released (from local CC)

ANF-PR unsuccessful

ANF-PR successful

PR req/ind

PRI req/ind (old connection)

To ANF-PR User

PR_invite

FE4_Idle

FE4_Idle

Figure 21 - ANF-PR, SDL for functional entity FE4

9.5

Allocation of functional entities to physical equipment The allocations of FEs to physical equipment shown in table 8 shall apply. FE1´ shall be located at either End PINX, depending on where the need for invoking ANF-PR arises. This will depend on the application. In the case of a trombone connection, the Originating PINX or Incoming Gateway PINX will be the same PINX as the Terminating PINX or Outgoing Gateway PINX. Therefore FE1´ and FE2 will be collocated and the new connection and those information flows sent using the signalling path of the new connection will be intra-PINX. Information flow PRP request/indication sent using the signalling path of the old connection will enable FE2 to determine that FE1´ is collocated. FE4 may be located in any PINX in the connection.

- 33 -

Table 8 - Scenarios for the allocation of FEs to physical equipment FE1´ (note 2)

FE2

FE4 (note 2)

Scenario 1

Originating PINX

Terminating PINX

any PINX in the connection

Scenario 2

Originating PINX

Outgoing Gateway PINX (note 1)

any PINX in the connection

Scenario 3

Incoming Gateway PINX (note 1)

Terminating PINX

any PINX in the connection

Scenario 4

Incoming Gateway PINX (note 1)

Outgoing Gateway PINX (note 1)

any PINX in the connection

Scenario 5

Terminating PINX

Originating PINX

any PINX in the connection

Scenario 6

Terminating PINX

Incoming Gateway PINX (note 1)

any PINX in the connection

Scenario 7

Outgoing Gateway PINX (note 1)

Originating PINX

any PINX in the connection

Scenario 8

Outgoing Gateway PINX (note 1)

Incoming Gateway PINX (note 1)

any PINX in the connection

NOTE 1 - When interworking with another network which supports an equivalent feature, FE1´, FE2 or FE4 may be located in that other network, thereby permitting replacement of the entire connection. NOTE 2 - When FE1´ and FE4 are collocated the functionality is equivalent with FE1 of clause 7.

9.6

Interworking considerations When interworking with another network which does not support an equivalent feature, the FEs for ANF-PR shall be located within PINXs, in accordance with 9.5. All information flows will be internal to the PISN. When interworking with another network which supports an equivalent feature, the two networks may cooperate in the operation of ANF-PR. One or more of FE1´,FE2 or FE4 may be located in the other network and the information flows within the PISN will map on to equivalent information flows in the other network.

- 34 -

- 35 -

Annex A (informative)

Circumstances in which ANF-PR might be invoked

ANF-PR can be used either to replace a connection which is no longer suitable or to obtain an improved connection. This annex describes some of the reasons why such situations can arise. In some cases a separate ANF is used to provide criteria governing the routeing of the new connection. In the absence of specific criteria, the new connection will be established using the routeing rules which apply to basic call establishment.

A.1

Cost reduction Even if there are no direct costs involved in a connection through a PISN, there are indirect costs through the use of inter-PINX connections and other resources which incur costs in some way, e.g., rental costs. Therefore the cost of a connection can be related to the resources used. By reducing the resources used, particularly the number of inter-PINX connections (and therefore the number of Transit PINXs), the cost can be reduced. The extreme case is the replacement of a trombone connection with an intra-PINX connection. A higher cost connection can arise as a result of a supplementary service, as a result of a change in the relative costs of different connections (e.g., at certain times of day) or because of lack of resources necessary to establish a least cost connection. Some examples of how supplementary services can lead to higher cost connections are:

 for a call created by means of the "transfer by join" option of supplementary service Explicit Call Transfer, the connection will pass through the transferring user's PINX, which will not necessarily lie along a path which a least cost connection between the transferred users would occupy;

 for a call created by termination of an add-on conference, the connection will pass through the PINX which supplied the conference bridge, which will not necessarily lie along a path which a least cost connection between the two remaining users would occupy;

 for a call which has undergone Call Forwarding by Forward Switching, the connection will be routed via the forwarding PINX, which will not necessarily lie along a path which a least cost connection between the calling user and the forwarded to user would occupy. Following a supplementary service which can lead to a higher cost connection, ANF-PR can be invoked immediately, provided the call has been answered. The decision to invoke ANF-PR can be based upon knowledge of whether the supplementary service has led to a connection which is not a least cost connection or, if that knowledge is not available, ANF-PR can be attempted anyway. Similar considerations apply to the use of ANF-PR following a change in the relative costs of different connections. Following normal call establishment, to avoid invoking ANF-PR on every call, it should be invoked only if it is known that a higher cost connection has been used. Invocation should wait until it is known that resources have become free or until sufficient time has elapsed for there to be a reasonable chance of resources having become free (e.g., 2 minutes). The way in which it is determined that a higher cost connection is in use and the means by which it is ensured that the new connection is of lower cost than the old connection are outside the scope of this Standard. It may involve the use of a separate ANF or manufacturer specific signalling protocols. A simplified means of ensuring that the new connection is not of higher cost than the old connection would be to switch to a new connection only if it is a least cost connection. Following failure of ANF-PR to establish a connection of lower cost, further invocations of ANF-PR can be made at intervals (e.g., 2 minutes) until successful or until the call is released.

- 36 -

A.2

Change of bearer capability If it is required to change basic service during a call, the bearer capabilities of the connection for the call can be inadequate for the support of the new basic service. ANF-PR can be invoked by the PISN while carrying out the change of basic service to obtain a new connection providing the bearer capabilities required. Failure to obtain a new path with the required bearer capabilities should result in abandonment of the attempt to change to the new basic service. Because the flow of user information is interrupted during a change of basic service, there is no need in this case for ANF-PR to take steps to minimise disruption.

A.3

Quality of service improvement ANF-PR can be used to obtain a new connection having better quality of service characteristics than the old connection. This need can arise when a connection has inadequate quality of service due to lack of availability of resources at the time of establishment or as a result of a supplementary service such as Call Transfer. Following a supplementary service such as Call Transfer, ANF-PR can be invoked immediately, provided the call has been answered. The decision to invoke ANF-PR can be based upon knowledge of whether the supplementary service has led to inadequate quality of service characteristics or, if that knowledge is not available, ANF-PR can be attempted anyway. Following normal call establishment, to avoid invoking ANF-PR on every call, it should be invoked only if it is known that the connection has inadequate quality of service characteristics. Invocation should wait until it is known that resources have become free to provide improved characteristics or until sufficient time has elapsed for there to be a reasonable chance of resources having become free (e.g., 2 minutes). The way in which it is determined that a connection has inadequate quality of service characteristics and the means by which it is ensured that the new connection has adequate or improved characteristics are outside the scope of this Standard. It may involve the use of a separate ANF or manufacturer specific signalling protocols. Following failure of ANF-PR to establish a connection with improved quality of service characteristics, further invocations of ANF-PR can be made at intervals (e.g., 2 minutes) until successful or until the call is released.

A.4

Maintenance actions ANF-PR can be used to change from a connection which involves failed equipment or equipment which is to be taken out of service. This is particularly useful for calls of long duration and permanent calls. The way in which it is determined that a equipment has failed or is to be taken out of service and the means by which the new connection avoids the use of such equipment falls within the scope of network management. It is outside the scope of this Standard.

- 37 -

Annex B (informative)

Avoidance of unacceptable disruption to user information

Disruption to the flow of user information will occur if there is a difference in transmission delay between the new connection and the old connection. This source of disruption, which is unavoidable, will result in a number of consecutive bits being lost or received twice. The effect will be similar in each direction. Disruption can also occur because FE1 (or FE1´) and FE2 switch over to the new connection at different times, owing to signalling delays. Whether this second source of disruption occurs and what its effect will be depend on the method of handling the user information channels at the two FEs.

B.1

Methods of handling user information channels Although the method of handling user information channels is an implementation matter, two basic approaches are foreseen: simultaneous switch over of both directions of transmission and separate switch over of each direction of transmission. Each has certain advantages and disadvantages, and choice can be influenced or dictated by PINX design.

B.1.1

Simultaneous switch over of both directions of transmission With this approach, switch over occurs at FE1 (or FE1´) (when sending PRS response/confirmation) followed by switch over at FE2 (on receipt of PRS response/confirmation). The effect is a loss of user information in each direction for the time taken for PRS response/confirmation to reach and be processed by FE2. This method can be enhanced for certain services, e.g., telephony, by using a conference bridge at FE1 (or FE1´) to connect the old user information channel in conference with the new user information channel until PRP response/confirmation is received. This enhancement avoids any loss of user information due to signalling delays. To avoid feeding unwanted information into the conference bridge, FE2 should ensure that a silence pattern is transmitted on the new user information channel prior to switch over and on the old user information channel after switch over.

B.1.2

Separate switch over of each direction of transmission With this approach, FE2 transmits on the new user information channel as soon as it has been agreed with the next CC, whilst continuing to transmit and receive on the old user information channel. When sending the PRS response/confirmation, FE1 (or FE1´) switches over to the new user information channel for transmission and reception, but also continues to transmit on the old user information channel. On receipt of the PRS response/confirmation, FE2 switches over to the new user information channel for reception as well as transmission. Effectively the two directions of transmission are switched over at different times, and any disruption in user information due to signalling delays is eliminated.

B.1.3

Mixed operation Because the method of handling the user information channels is an implementation matter, the situation can arise where FE1 (or FE1´) and FE2 adopt different approaches. This is likely to lead to loss of information in one or both directions for a period determined by signalling delays. In the case where FE1 (or FE1´) uses a conference bridge, it can also lead to a period of noise.

B.2

Preventing the use of ANF-PR Whichever, approach is taken, there will be some disruption to user information. For some applications this will not matter, e.g., because of recovery mechanisms at higher layers or because the transmission of user information has been interrupted anyway (as is the case during In-Call Modification). For other applications this disruption might be unacceptable, and therefore steps should be taken to prevent the use of ANF-PR on such calls. Possible means include:

 limiting ANF-PR to basic services where it is known that the disruption caused can be tolerated;

- 38 -

 service marking users which are known to use certain applications so that ANF-PR will not be invoked for certain basic services;

 allowing users to request, on a per call basis, that ANF-PR be prevented.

B.3

Replacement of trombone connections The special case of changing from a trombone connection to an intra-PINX connection is not subject to additional disruption due to signalling delays, and therefore ANF-PR might be possible even for applications which cannot tolerate ANF-PR under normal circumstances.

.

.

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]

A description of this Standard can be found on the ECMA Web site, www.ecma.ch. From there, files E175-DOC.EXE (MSWord, self-expanding) and E175-PDF.PDF (Acrobat PDF) can be freely downloaded. The ECMA web site 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-175 is available free of charge in printed form and as a file. See inside cover page for instructions

Related documents

Record · ID 600432 · SHA-256 ffcb1620987bbb4b
Conceptio Open Knowledge Archive — every document is proof-bundled with source, license, and retrieval metadata.