Conceptio › Archive › ECMA International

ECMA Internationalopen access

ECMA-142 — Private Integrated Services Network (PISN) - Circuit mode 64kbit/s bearer services - Service description, functional capabilities and information flows (BCSD) (December 2001)

ECMA International · ECMA International

ECMA International · Standards · License: Open Access

circuit ecma ecmainternational flows information integrated mode network

ecma, standard, ecma international, specification, ecma-142, ecma 142, 142, private, integrated, services, network, pisn, circuit, mode, 64kbit, bearer, service, description, functional, capabilities, and, information, flows, bcsd

S tandard ECMA-142

3rd Edition - December 2001

Standardizing Information

and

Communication

Systems

Private Integrated Services Network (PISN) Circuit Mode 64kbit/s Bearer Services Service Description, Functional Capabilities and Information Flows

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

S tandard ECMA-142

3rd Edition - December 2001

Standardizing

Information

and

Communication

Systems

Private Integrated Services Network (PISN) Circuit Mode 64kbit/s Bearer Services Service Description, Functional Capabilities and Information Flows (BCSD)

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

Ecma-142.doc

14-01-02 08,52

Brief History

This Standard is one of a series of ECMA Standards defining services and signalling protocols applicable to Private Integrated Services Networks (PISNs). The series uses ISDN concepts as developed by ITU-T and conforms to the framework of International Standards for Open Systems Interconnection as defined by ISO/IEC. This particular Standard contains specifications of basic 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. Compared to the 2nd Edition of Standard ECMA-142 (published by ECMA in June 1997), this 3rd Edition is completely aligned with International Standard ISO/IEC 11574:2000(E).

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

- i -

Table of contents Section 1: General

Scope

References (normative)

Definitions call in te r v e n in g n e tw o r k ( I V N ) mix e d p u b lic /p r iv a te I S D N n e t w o r k c a l l c o n tr o l e n t i t y Private Integrated Services Network (PISN) P r i v a t e I n t e g r a t e d S e r v i c e s N e tw o r k E x c h a n g e ( P I N X ) PISN user s e r v i c e [ T e l e c o mmu n i c a t i o n s e r v i c e s ] user

2 2 2 2 2 2 3 3 3 3

Symbols and abbreviations

P r o v is io n o f s e r v ic e s b y a P I S N Bearer services Teleservices Co n tr o l a n d s ig n a llin g I n te r w o r k in g c o n s id e r a tio n s S e r v i c e mo d e l

4 4 4 4 5 5

3 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9

5.1 5.2 5.3 5.4 5.5

Section 2: Service Description (stage 1 description)

6 6 6 6 7 7 7

Circuit-mode 64 kbit/s unrestricted 8 kHz structured bearer service category 6 . 1 D e f in itio n 6 . 2 D e s c r ip tio n 6.3 Procedures 6 . 4 N e t w o r k c a p a b i l i t y f o r c h a r g in g 6 . 5 I n te r w o r k in g c o n s id e r a tio n s 6.5.1 I n te r w o r k in g w ith a p u b lic I S D N a n d c e r ta in o th e r d ig ita l n e tw o r k s 6.5.2 I n te r w o r k in g w ith n e tw o r k s s u p p o r tin g o n ly a r e s tr ic te d d ig ita l in f o r ma tio n transfer capability 6.5.3 I n te r w o r k in g w ith a n a lo g u e n e tw o r k s 6 . 6 S t a t i c D e s c r i p t i o n : S e r v i c e A t t r i b u te s

7 7.1 7.2

7 7 7

C i r c u i t - m o d e 6 4 k b i t / s 8 k H z s t r u c t u r e d b ea r e r s e r v i c e c a t e g o r y u s a b l e f o r s p e e c h information transfer 8 D e f in itio n 8 D e s c r ip tio n 8

- ii -

7.3 Procedures 7 . 4 N e t w o r k c a p a b i l i t y f o r c h a r g in g 7 . 5 I n te r w o r k in g c o n s id e r a tio n s 7.5.1 I n te r w o r k in g w ith a p u b lic I S D N a n d c e r ta in o th e r d ig ita l n e tw o r k s 7.5.2 I n te r w o r k in g w ith a n a lo g u e n e tw o r k s 7.5.3 E n c o d in g la w c o n v e r s io n 7 . 6 S t a t i c D e s c r i p t i o n : S e r v i c e A t t r i b u te s

8 8 9 9 9 9 9

Circuit-mode 64 kbit/s 8 kHz structured bearer service category usable for 3 , 1 k H z a u d io in f o r m a t io n t r a n s f e r 10 8 . 1 D e f in itio n 10 8 . 2 D e s c r ip tio n 10 8.3 Procedures 10 8 . 4 N e t w o r k c a p a b i l i t y f o r c h a r g in g 10 8 . 5 I n te r w o r k in g c o n s id e r a tio n s 10 8.5.1 I n te r w o r k in g w ith a p u b lic I S D N a n d c e r ta in o th e r d ig ita l n e tw o r k s 10 8.5.2 I n te r w o r k in g w ith a n a lo g u e n e tw o r k s 10 8.5.3 E n c o d in g la w c o n v e r s io n 10 8 . 6 S t a t i c D e s c r i p t i o n : S e r v i c e A t t r i b u te s 11

Common procedures for services within a PISN 9 . 1 P r o v is io n o f s e r v ic e s 9 . 2 N o r ma l p r o c e d u r e s 9.2.1 C a l l e s t a b l i s h me n t a t t h e c a l l i n g P I S N u s e r 9.2.2 C a l l e s t a b l i s h me n t a t t h e c a l l e d P I S N u s e r 9.2.3 T e r mi n a t i n g t h e s e r v i c e ( c a l l r e l e a s e ) 9 . 3 E x c e p tio n a l p r o c e d u r e s / u n s u c c e s s f u l o u tc o me

11 11 11 11 13 14 14

10 Interworking 10.1 G e n e r a l I n te r w o r k in g c o n s id e r a tio n s 10.1.1 I n c o min g c a l l s 10.1.2 O u tg o in g c a lls 10.1.3 PISN transit calls 10.2 I n te r w o r k in g w ith p u b lic - I S D N 10.2.1 R e c e i p t o f s e r v i c e r e q u es t f r o m a p u b l i c I S D N 10.2.2 S e n d in g a s e r v ic e r e q u e s t to a p u b lic I S D N 10.2.3 Receipt of a service response from public ISDN 10.2.4 S e n d in g s e r v ic e r e s p o n s e to p u b lic I S D N

15 15 15 15 16 16 16 16 17 17

Dynamic Description

S e c t i o n 3 : F u n c t i o n a l c a p a b i l i t i e s a n d i n f o r m a t i o n f l o ws ( s t a g e 2 d e s c r i p t i o n )

12 Functional model 12.1 F u n c tio n a l mo d e l d e s c r ip tio n 12.2 Description of the functional entities 12.2.1 C a l l C o n tr o l A g e n t f u n c t i o n a l e n t i t y

20 20 20 21

- iii -

12.2.2

C a l l C o n tr o l f u n c t i o n a l e n t i t y

13 D e f i n i t i o n o f i n f o r m a t i o n f l o ws 13.1 Co n v e n tio n s u s e d w ith in th e d e s c r ip tio n o f in f o r ma tio n f lo w s 13.1.1 Co n v e n tio n f o r th e d e s c r ip tio n o f ma n d a to r y o r o p tio n a l in f o r ma tio n 13.1.2 Co n v e n tio n f o r th e n a min g o f in f o r ma tio n f lo w s 13.2 SETUP 13.3 REPORT 13.4 CHANNEL_ACKNOWLEDGE 13.5 CHANNEL_CONNECT 13.6 DISCONNECT 13.7 RELEASE 13.8 I N F O R MA T I O N 13.9 SETUP_REJECT 13.10 PROCEEDING

23 23 23 23 24 28 29 29 29 30 30 30 31

14 Information flow sequences 14.1 Functional entity actions 14.1.1 Originating CCA functional entity 14.1.2 Originating CC functional entity 14.1.3 Transit CC functional entity 14.1.4 Destination CC functional entity 14.1.5 Destination CCA functional entity 14.1.6 I n c o min g g a t e w a y C C f u n c t i o n a l e n t i t y 14.1.7 O u t g o in g g a t e w a y C C f u n c t i o n a l e n t i t y 14.2 N o r ma l c a l l e s t a b l i s h me n t 14.3 N o r ma l c a l l e s t a b l i s h me n t w i t h d ig i t - b y- d i g i t s e n d in g a n d a u t o ma t i c a n s w e r 14.4 U n s u c c e s s f u l c a lls w ith th e p r o v is io n o f to n e s a n d a n n o u n c e me n ts 14.5 U n s u c c e s s f u l c a lls w ith o u t th e p r o v is io n o f to n e s a n d a n n o u n c e me n ts 14.6 I n c o min g in te r w o r k in g w ith a n o n - I S D N 14.7 O u tg o in g in te r w o r k in g w ith a n o n - I S D N 14.8 O u tg o in g in te r w o r k in g w ith d ig it- b y- d ig it s e n d in g 14.9 Basic call clearing 1 4 . 1 0 I n c o min g in te r w o r k in g w ith a p u b lic I S D N 1 4 . 1 1 O u tg o in g in te r w o r k in g w ith a p u b lic I S D N

31 31 31 32 33 34 36 37 38 40 41 42 43 44 45 46 47 48 49

15 S D L d ia g r a m s f o r f u n c t io n a l e n t it ie s 15.1 O r i g i n a t i n g C C A f u n c t i o n a l e n t i t y S D L d ia g r a ms 15.1.1 O r i g i n a t i n g C C A s t a t e s u s e d i n S D L d i a g r a ms 15.1.2 O r ig in a tin g CCA S D L d ia g r a ms 15.2 O r i g i n a t i n g C C f u n c t i o n a l e n t i t y S D L d ia g r a ms 15.2.1 O r i g i n a t i n g C C s t a t e s u s e d i n S D L d i a g r a ms 15.2.2 O r ig in a tin g CC S D L d ia g r a ms 15.3 T r a n s i t C C f u n c t i o n a l e n t i t y S D L d ia g r a ms 15.3.1 T r a n s i t C C s t a t e s u s e d i n S D L d i a g r a ms 15.3.2 T r a n s i t C C S D L d i a g r a ms 15.4 D e s t i n a t i o n C C f u n c t i o n a l e n t i t y S D L d ia g r a ms

50 50 50 51 55 55 56 63 63 64 69

- iv -

15.4.1 D e s t i n a t i o n C C s t a t e s u s e d i n S D L d i a g r a ms 15.4.2 D e s tin a tio n CC S D L d ia g r a ms 15.5 D e s t i n a t i o n C C A f u n c t i o n a l e n t i t y S D L d ia g r a ms 15.5.1 D e s t i n a t i o n C C A s t a t e s u s e d i n S D L d i a g r a ms 15.5.2 D e s tin a tio n CCA S D L d ia g r a ms

69 70 77 77 77

A llo c a t io n o f f u n c t io n a l e n t it i e s t o p h y s i c a l e n t i t i e s

Annex A - Service attributes

Annex B - Teleservices

Annex C - Bibliography

A n n e x D - Er r o r s in I S O /I EC 1 1 5 7 4 1 s t e d it io n

Section 1: General 1

Scope This Standard specifies the service description and control aspects, including functional capabilities and information flows, of standardised circuit-mode bearer services which may be supported by a Private Integrated Services Network (PISN). This Standard includes the following basic services: • Circuit-mode 64 kbit/s unrestricted 8 kHz structured bearer service category; • Circuit-mode 64 kbit/s 8 kHz structured bearer service category usable for speech information transfer; • Circuit-mode 64 kbit/s 8 kHz structured bearer service category usable for 3,1 kHz audio information transfer. A PISN shall support at least one of the above three bearer services to conform with this Standard. The scope of this Standard does not include: • the negotiation of service at call establishment time, • the change of service during a call, and • unidirectional services. This Standard includes optional procedures for the provision of functions equivalent to the following public ISDN supplementary services: Subaddress and Multiple Subscriber Number. NOTE 1 Supplementary services and other bearer services which can be used in conjunction with 64 kbit/s circuit switched bearer services specified in this Standard are dealt with in other standards. NOTE 2 Service specifications are based on information concerning the corresponding public ISDN service available at the time of publication of this Standard. NOTE 3 ITU-T treat Subaddressing and Multiple Subscriber Number as supplementary services. NOTE 4 The use of the Direct Dial In supplementary service of a public ISDN for calls incoming to a PISN from a public ISDN is regarded as part of the basic services in a PISN. NOTE 5 The use of the Calling Line Identification Presentation and Connected Line Identification Presentation supplementary services of a public ISDN for obtaining the Originating Number or the Connected Number of a call from or to a public ISDN is regarded as part of the basic services in a PISN. NOTE 6 The provision (either explicitly or implicitly) by the user to the network, of its own number (Originating Number or Connected Number), and the provision of an Originating Number or a Connected Number by a PISN to another network is a part of the basic services in a PISN and not a part of the Calling Line Identification Presentation and Connected Line Identification Presentation supplementary services. Those supplementary services are concerned only with the presentation of the number from the network to the served PISN user.

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.

- 2 -

In the case of references to ECMA Standards that are aligned with ISO/IEC International Standards, the number of the appropriate ISO/IEC International Standard is given in brackets after the ECMA reference. ECMA-133

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

ECMA-155

Private Integrated ISO/IEC 11571)

ITU-T Rec. G.711

Pulse code modulation (PCM) of voice frequencies (1988)

ITU-T Rec. I.112

Vocabulary of terms for ISDNs (1993)

ITU-T Rec. I.140

Attribute technique for the characterization of telecommunications services supported by an ISDN and network capabilities of an ISDN (1993)

ITU-T Rec. I.210

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

ITU-T Rec. I.231

Circuit-mode bearer service categories (1988)

Services

Networks

Addressing

(International

Standard

ITU-T Rec. I.251.1 Number identification supplementary services – Direct Dialling-In (1992) ITU-T Rec. I.251.3 Number identification supplementary services – Calling Line Identification Presentation (1992) ITU-T Rec. I.251.5 Number identification supplementary services – Connected Line Identification Presentation (COLP) (1995)

ITU-T Rec. I.520

General arrangements for network interworking between ISDNs (1993)

ITU-T Rec. X.31

Support of packet-mode terminal equipment by an ISDN (1995)

Definitions For the purpose of this Standard, the following definitions apply. For other terms used in this Standard, the definitions in ECMA-133 and ITU-T Rec. I.112 apply.

3.1

call The instance of the use of a service.

3.2

intervening network (IVN) The generic term for any real type of network which is employed for the provision of inter-PINX connections.

3.3

mixed public/private ISDN An overall ISDN which consists of any concatenation of public/private networks. NOTE 7 Services are transparent to the users across public and private network components of a mixed public/private network.

3.4

network call control entity The collection of network functions concerned with the control of services, as opposed to functions concerned with the transfer of user information.

3.5

Private Integrated Services Network (PISN) A private network providing services to a specific set of users. NOTE 8 Contrary to a Public ISDN which provides services to the general public. NOTE 9 The term PISN covers more than a private ISDN.

- 3 -

3.6

Private Integrated Services Network Exchange (PINX) A PISN nodal entity which provides automatic connection handling functions used for the provision of telecommunication services. A nodal entity may consist of one or more nodes.

3.7

PISN user An entity which uses telecommunication services offered by a PISN, and which therefore directly or indirectly uses the services of the Network Layer.

3.8

service [Telecommunication services] That which is offered by a PISN operator and/or owner to its customers in order to satisfy a specific telecommunication requirement. Unless otherwise stated, the term “service” shall mean “bearer [telecommunication] service".

3.9

user An entity which uses telecommunication services offered by a network, and which therefore directly or indirectly uses the services of the Network Layer.

Symbols and abbreviations CC

Clearing Cause

CC [FE]

Call Control generic functional entity

CCA

Call Control Agent generic functional entity

cfm | c

confirmation

Call History

Channel Identifier

Connected Number

Connected Subaddress

Connection Type

Destination Number

Destination Subaddress

Functional Entity

HLC

High Layer Compatibility

ind | i

indication

ISDN

Integrated Services Digital Network

ISO

International Organisation for Standardisation

LLC

Low Layer Compatibility

Number complete indication

Originating Number

Originating Subaddress

OSI

Open Systems Interconnection

PINX

Private Integrated services Network eXchange

PISN

Private Integrated Services Network

PSTN

Public Switched Telephone Network

Rec.

(ITU-T) Recommendation

- 4 -

req | rq

request

resp | rs

response

Report Type

SDL

Specification and Description Language

Terminal Equipment

Provision of services by a PISN Basic services within a PISN consist of bearer services and teleservices. A bearer service is defined only up to a certain layer, in any case no higher than Layer 3. The definition of a teleservice also encompasses the higher layers up to Layer 7 (although some of the layers can be empty or not specified, as with for example, Telephony). The basic services defined in this Standard correspond to the 64 kbit/s circuit-mode basic services defined in ITU-T Recommendation I.231.

5.1

Bearer services PISN circuit-mode bearer services provide a means of transferring information between users at the physical layer level. Service attributes above Layer 3 are not defined. Consequently, the provision of bearer services involves only low layer functions. A bearer service can support a variety of high layer protocols. A circuit-mode bearer service provides an end to end connection (at the physical layer) for the conveyance of user information. Each switching point intervenes only at the physical layer. This gives a constant bit rate and fixed delays which are very close to the inherent delays of the transmission media.

5.2

Teleservices The provision of a teleservice involves high layer functions, generally using the underlying low layer capabilities of a bearer service. A PISN can support a teleservice by supporting a bearer service having the same capabilities as those required by the teleservice and by satisfying any special control requirements of the teleservice. The provision of high layer functions in support of a teleservice is not a necessary part of a PISN and is beyond the scope of this Standard. When requesting a teleservice from a PISN, the user has to explicitly indicate the bearer capabilities required in the same way as when a bearer service is requested. In addition, an indication of the teleservice required is provided by the PISN user, primarily for passing the indication through the network to the called PISN user in order to allow compatibility checking. A PISN can optionally make use of this information for purposes such as barring certain teleservices to certain PISN users, or for the provision or activation of supplementary services on a per teleservice basis, e.g., call forwarding. Any use of this information by a PISN is outside the scope of, but is not precluded by, this Standard. Annex B provides guidelines for, and additional information about, teleservices.

5.3

Control and signalling In order for information transfer to take place, an information connection must exist between the PISN users concerned. A demand service involves the establishment and release of information connections according to the demands of users. From the point of view of users, calls have to be established and released, and this involves call control functions. Call control requires knowledge of the properties of the user information to be transferred in order to provide appropriate capabilities. In general, more than one network element (e.g., PINX, terminal) is involved in a call, and therefore call control is distributed. Consequently call control information needs to be conveyed between network elements. The conveyance of this information is a function of signalling. PISN services use message based signalling information, which means that signalling information is carried over a dedicated logical connection, separate from the connection established for conveying user information.

- 5 -

NOTE 10 The possible use of the signalling connection also to provide user-to-user information transfer is the function of the User-to-User Signalling supplementary service, and is outside the scope of this Standard.

5.4

Interworking considerations In general, interworking between a PISN bearer service and a bearer service provided by another network requires interworking functions, both for information transfer and for signalling. When interworking with the same service in a public ISDN, the interworking function for information transfer is null. However, interworking has an impact on signalling.

5.5

Service model This Standard uses the following service model in order to specify services. The PISN provides bearer capabilities between end users for the support of the bearer service requested by the user to support applications. The PISN user controls the bearer capabilities through the control plane. Coordination between the bearer capabilities and the control plane is maintained by each PINX involved in the connection. The user terminal interfaces are identified by an address, which in a PISN is defined by a PISN number or a concatenation of a number and a Subaddress. The control plane processes address information along with other parameters as necessary to effect the necessary routeing. This Standard views control functions as services being provided by a Network Call Control entity, which are accessible through control service access points. Coordination functions use the services of the Network Call Control entity when coordinating call control with the transfer of user information, thereby providing bearer capability to PISN users. Unless explicitly stated the terms “network” and “Network Call Control Entity” are used interchangeably. See figure 1. User

SAP

User

Network Call

SAP

Control Entity

SAP = Service Access Point

Figure 1 – Service model The primitives used across Network Call Control service access points are as follows. • SETUP_request / indication / response / confirmation; used for call establishment. • RELEASE_request / indication / response / confirmation; used for call rejection and release. • REPORT_request / indication; used for reporting to the calling user: − that the call is proceeding, − that the called PISN user is being alerted, − the presence of in-band tones or announcements, and − of interworking situations. • INFORMATION_request; used for providing additional destination addressing information not provided with the SETUP_request. In the Stage 1 description, the control aspects of services are specified in terms of the primitives listed above at the Network Call Control service access points. The entire Network Call Control is treated as a single entity.

- 6 -

In the Stage 2 description, the internal behaviour of Network Call Control is specified by breaking it down into a number of Functional Entities (FE) and specifying the information flows between them. The result is a model of the form shown in figure 2. The particular model used for the basic call is specified in section 3 of this Standard. Other models based on this generic model are used for specifying supplementary services. Supplementary services are not specified in this Standard. User

SAP

User

Network Call

SAP

Control Entity FE

SAP = Service Access Point

Figure 2 – Generic model for Stage 2

Section 2: Service Description (stage 1 description) 6 6.1

Circuit-mode 64 kbit/s unrestricted 8 kHz structured bearer service category Definition This bearer service category provides information transfer at 64 kbit/s without alteration between PISN users. The service can support various PISN user applications. Examples include: • speech (see Note 11); • 3,1 kHz audio (see Note 11); • multiple subrate information streams multiplexed into 64 kbit/s by the PISN user; • transparent access to a public or private X.25 network (ITU-T Rec. X.31 case A for access to a public X.25 network). NOTE 11 Whilst speech and 3,1 kHz audio have been given as applications for this bearer service, the PISN user should ensure that a compatible encoding scheme is in operation. In any case, no network provision can be made for the control of such items as echo and loss, as the network is unaware of the application in use. Furthermore, the quality of service attribute value for information transfer delay indicates the suitability of a particular version of this bearer service for speech communication.

6.2

Description This circuit-mode bearer service category allows: • two PISN users to communicate in a point to point configuration via the network using 64 kbit/s digital signals, in both directions continuously and simultaneously for the duration of a call; • in conjunction with a conference call supplementary service (the procedures of which are outside the scope of this Standard), three or more PISN users to communicate in a multi-point configuration. Once the information channel connection has been established according to the procedures described in clauses 9 to 11, it is available for the transmission of 64 kbit/s digital signals in both directions continuously and simultaneously, without alteration by the network. The network shall place no restrictions on the content of the digital signals.

6.3

Procedures These are common to all services in this Standard and are given in clause 9.

- 7 -

6.4

Network capability for charging This is outside the scope of this Standard.

6.5

Interworking considerations

6.5.1

I n t e r w o r k i n g w i t h a p u b l i c I SD N a n d c e r t a i n o t h e r d i g i t a l n e t w o r k s Services in this category are able to interwork with the same services in a public ISDN. The interworking function for user information transfer is null.

6.5.2

I n t e r w o r k i n g w i t h n e t w o rk s s u p p o r t i n g o n l y a r e s t r i c t e d d i g i t a l i n f o r m a t i o n t r a n s f e r capability During an interim period, some other networks may only support restricted 64 kbit/s digital information transfer capability, i.e., information transfer capability solely restricted by the requirement that the allzero octet is not allowed. Interworking can be achieved according to the rules given in Appendix I of ITU-T Rec. I.520 (the PISN being treated as an ISDN with unrestricted 64 kbit/s capability). The PISN shall assume that the interworking functions are provided in the other network. The PISN need not be affected by this interworking, other than by conveying the appropriate signalling indication to and from the user.

6.5.3

I n t e r wo r k in g wit h a n a lo g u e n e t wo r k s The PISN may support calls between data terminals and an analogue network. In this case the following procedures apply. A V–series terminal1 shall be connected to the PISN via a terminal adaptor. The PISN shall provide an interworking function (including a modem) for calls to or from a user of an analogue network (e.g., PSTNs or private analogue networks). To effect a connection, the PISN should use a 64 kbit/s unrestricted connection between its user and the interworking function, and a 3,1 kHz audio connection (or equivalent) from the interworking unit to the analogue network. NOTE 12 If additional information concerning layer 1 protocols is available, the PISN may provide the interworking function. In general, when a call originates in an analogue network, the analogue network is unable to indicate to the PISN the service required. If this is the case, the called PISN user is offered a 3,1 kHz audio bearer service with an indication of such interworking. NOTE 13 If at the called PISN user there is a terminal adaptor which is unable to accept an incoming 3,1 kHz audio call but is able to accept an incoming 64 kbit/s unrestricted call, the introduction of an interworking function in the PISN can be achieved only if there is service negotiation between the PISN and the called terminal adaptor. This capability is outside the scope of this Standard.

6.6

Static Description: Service Attributes For details concerning the structuring of service attributes, see annex A. •

Dominant information transfer attributes

The dominant information transfer attribute values for this service category shall be: 1)

Information transfer mode: circuit;

Information transfer rate: 64 kbit/s;

Information transfer capability: unrestricted;

Structure: 8 kHz integrity.

1 Terminals that support certain ITU-T Recommendations such as V.24, V.28, V.10 and V.11.

- 8 -

•

Secondary information transfer attributes

The secondary information transfer attribute values for this service category shall be: 5)

Establishment of communication: demand or reserved or permanent (see Note 14);

Symmetry: bidirectional symmetric or unidirectional (see Note 15);

Communication configuration: point-to-point or multi-point (see Note 16).

•

Access attributes

The access attribute values for this service category shall be (see Note 17): 8)

Access channel: B;

Access protocol: Not defined.

NOTE 14 Only demand services are specified in this Standard. NOTE 15 Only bidirectional symmetric services are specified in this Standard. NOTE 16 Only point-to-point services are specified in this Standard. Multi-point configurations can be achieved using conference call supplementary services. NOTE 17 The access attributes refer only to the user information not the signalling information.

7 7.1

Circuit-mode 64 kbit/s 8 kHz structured bearer service category usable for speech information transfer Definition This bearer service category is intended to support speech. User information shall conform to ITU-T Rec. G.711 (A–law or µ–law). The network may use processing techniques appropriate for speech such as analogue transmission, echo cancellation and low bit rate voice encoding. Hence, bit integrity is not assured. This bearer service category is not intended to support modem generated voice band data. All ITU-T recommendations for the transfer of speech information in a network apply to this service.

7.2

Description This circuit-mode bearer service category allows: • two PISN users in a point-to-point configuration to communicate in a point to point configuration via the network using speech encoded into 64 kbit/s digital signals, in both directions continuously and simultaneously for the duration of a call; • in conjunction with a conference call supplementary service, three or more PISN users to communicate in a multi-point configuration. Once the information channel connection has been established according to the procedures described in clauses 9 to 11, it is available for the transmission of speech encoded into 64 kbit/s digital signals in both directions continuously and simultaneously. Bit integrity is not assured. The network may use analogue transmission. The network shall provide tones and announcements to indicate the progress or otherwise of a call.

7.3

Procedures These are common to all services in this Standard and are given in clause 9.

7.4

Network capability for charging This is outside the scope of this Standard.

- 9 -

7.5

Interworking considerations

7.5.1

I n t e r w o r k i n g w i t h a p u b l i c I SD N a n d c e r t a i n o t h e r d i g i t a l n e t w o r k s Services specified in this Standard are able to interwork with the same services in a public ISDN. The interworking function for user information transfer is null.

7.5.2

I n t e r wo r k in g wit h a n a lo g u e n e t wo r k s This bearer service category is able to interwork with PSTNs and private analogue networks when calls originate in the PISN. For calls from an analogue network to the PISN, the analogue network is generally unable to indicate the service required, and in this case the PISN provides a 3,1 kHz audio bearer service rather than a speech bearer service, in order to allow for the possibility of voice band data. Calls from the PSTN shall always use 3,1 kHz audio.

7.5.3

Encoding law conversion The PISN may provide A–law/µ–law conversion (see ITU-T Rec. G.711) to permit interworking between terminals and interfaces to other networks which do not all conform to the same encoding law (A–law or µ–law). NOTE 18 Although in general a network which uses µ–law encoding should provide A–law/µ–law conversion when interworking with networks which use A–law, this may not apply in the case of a private network using A–law and a public network using µ–law. Therefore even if the PISN uses A–law and expects its terminals and other private networks to use A–law, it may need to provide A–law/µ–law conversion when interworking with public networks which use µ–law.

7.6

Static Description: Service Attributes For details concerning the structuring of service attributes, see annex A. •

Dominant information transfer attributes

The dominant information transfer attribute values for this service category shall be: 1)

Information transfer mode: circuit;

Information transfer rate: 64 kbit/s;

Information transfer capability: speech (encoded)

Structure: 8 kHz integrity.

•

Secondary information transfer attributes

The secondary information transfer attribute values for this service category shall be: 5)

Establishment of communication: demand or reserved or permanent (see Note 19);

Symmetry: bidirectional symmetric or unidirectional (see Note 20);

Communication configuration: point-to-point or multi-point (see Note 21).

•

Access attributes

The access attribute values for this service category shall be (see Note 22): 8)

Access channel: B;

Access protocol: According to ITU-T Rec. G.711 (A–law or µ–law).

NOTE 19 Only demand services are specified in this Standard. NOTE 20 Only bidirectional symmetric services are specified in this Standard. NOTE 21 Only point-to-point services are specified in this Standard. Multipoint configurations can be achieved using conference call supplementary services.

- 10 -

NOTE 22 The access attributes refer only to the user information not the signalling information.

Circuit-mode 64 kbit/s 8 kHz structured bearer service category usable for 3,1 kHz audio information transfer

8.1

Definition This bearer service category corresponds to the service which is currently offered in the PSTN. It provides for the transfer of speech and of 3,1 kHz bandwidth audio information such as voice band data via modems and facsimile groups 1, 2 and 3 information (see Note 23). User information shall conform to ITU-T Rec. G.711 (A–law or µ–law). The network may use processing techniques appropriate for speech, provided they are appropriately modified or functionally removed prior to non-speech information transfer. The control of echo control devices, speech processing devices, etc. is made by the use of disabling tones. All ITU-T recommendations for the transfer of speech information in a network shall apply to this service. NOTE 23 The maximum modem bit rate that can be used by PISN users in applications of this bearer service category depends on the modulation standard employed and on the transmission performance of the networks involved.

8.2

Description This circuit-mode bearer service category allows: • two PISN users in a point-to-point configuration to communicate via the network using 3,1 kHz audio information encoded into 64 kbit/s digital signals, in both directions continuously and simultaneously for the duration of a call; • three or more PISN users to communicate in a multi-point configuration in conjunction with a conference supplementary service. Once the information channel connection has been established according to the procedures described in clauses 9 to 11, it is available for the transmission of 3,1 kHz audio information encoded into 64 kbit/s digital signals in both directions continuously and simultaneously. Bit integrity is not assured. The network may use analogue transmission. The network shall provide tones and announcements to indicate the progress or otherwise of a call.

8.3

Procedures These are common to all services in this Standard and are given in clause 9.

8.4

Network capability for charging This is outside the scope of this Standard.

8.5

Interworking considerations

8.5.1

8.5.2

I n t e r wo r k in g wit h a n a lo g u e n e t wo r k s This bearer service category is able to interwork with PSTNs and private analogue networks. For calls from an analogue network to the PISN, the analogue network is generally unable to indicate the service required, and in this case the PISN shall always provide a 3,1 kHz audio bearer service.

8.5.3

- 11 -

NOTE 24 Although in general a network which uses µ–law encoding should provide A–law/µ–law conversion when interworking with networks which use A–law, this may not apply in the case of a private network using A–law and a public network using µ–law. Therefore even if the PISN uses A–law and expects its terminals and other private networks to use A–law, it may need to provide A–law/µ–law conversion when interworking with public networks which use µ–law.

8.6

Static Description: Service Attributes For details concerning the structuring of service attributes, see annex A. •

Dominant information transfer attributes

The dominant information transfer attribute values for this service category shall be: 1)

Information transfer mode: circuit;

Information transfer rate: 64 kbit/s;

Information transfer capability: 3,1 kHz audio (encoded);

Structure: 8 kHz integrity.

•

Secondary information transfer attributes

The secondary information transfer attribute possibilities for this service category shall be: 5)

Establishment of communication: demand or reserved or permanent (see Note 25);

Symmetry: bidirectional symmetric or unidirectional (see Note 26);

Communication configuration: point-to-point or multi-point (see Note 27).

•

Access attributes

The access attribute values for this service category shall be (see Note 28): 8)

Access channel: B;

Access protocol: According to ITU-T Rec. G.711 (A–law or µ–law).

NOTE 25 Only demand services are specified in this Standard. NOTE 26 Only bidirectional symmetric services are specified in this Standard. NOTE 27 Only point-to-point services are specified in this Standard. Multipoint configurations can be achieved using conference call supplementary services. NOTE 28 The access attributes refer only to the user information not the signalling information.

Common procedures for services within a PISN The procedures of this clause shall apply when the users concerned are users of a PISN.

9.1

Provision of services As a PISN option, a basic service available in a PISN can be generally available, or can be available by specific arrangement for an individual PISN user.

9.2 9.2.1

Normal procedures Call establishment at the calling PISN user The calling PISN user shall originate a call by transferring across a service access point a request for call establishment (SETUP_request). This request shall include the following information: a)

Bearer Capability information defining the bearer capabilities required of the network;

- 12 -

a number identifying the called PISN user (Destination Number);

NOTE 29 The number information may be complete (so called "en bloc sending" mode) or incomplete (so called "overlap sending" mode). c)

the Originating Number if multiple numbers have been assigned to the calling PISN user’s access;

and may include, d)

the called PISN user’s subaddress, to further identify the called PISN user (Destination Subaddress);

information describing user information transfer protocols for layers up to layer 3, Low Layer Compatibility (LLC) information;

information describing user information transfer protocols for layer 4 and above, High Layer Compatibility (HLC) information;

the PISN user’s own subaddress (Originating Subaddress) to identify itself to the called PISN user.

The Bearer Capability shall consist of a list of the low layer attributes for the bearer service required. It may include additional low layer protocol information which is not required in order to indicate the service but which can be of use to the PISN in potential interworking situations. The Destination Number shall consist of the number digits, the identification of the numbering plan and the type of number, in accordance with ECMA-155. The PISN user may provide the complete Destination Number to the PISN with the service request (SETUP_request), or by use of the overlap sending mode (e.g., digit-by-digit). In the latter case, any Destination Number information not supplied in the SETUP_request shall be supplied in one or more subsequent INFORMATION_requests. NOTE 30 In some countries, overlap sending is not used. The Destination Subaddress, if supplied consists of the “type of subaddress” indicator and the actual subaddress, in accordance with ECMA-155. The LLC information is additional to the Bearer Capability information. The PISN shall pass the LLC information to the called PISN user, where it can be used for compatibility checking. The network shall not use the LLC information. The PISN shall pass the HLC information to the called PISN user, where it can be used for compatibility checking. The Originating Subaddress consists of the “type of subaddress” indicator and the actual subaddress, in accordance with ECMA-155. For case (c) above, the PINX shall screen the provided Originating number. If the Originating Number is determined to be one of the numbers assigned to that access, the PISN shall use this Originating Number and classify it “USER PROVIDED, VERIFIED AND PASSED”. If no Originating Number is provided or it is determined not to be one of the set of multiple numbers assigned to that access, the PISN shall provide a pre-arranged default Originating Number classified as “NETWORK PROVIDED”. For the format and type of number see ECMA-155. For all other cases, even if the Originating number is provided by the user, the PINX shall always use the network determined number with the indication NETWORK PROVIDED. NOTE 31 The presentation of the Connected Number and Subaddress and the screening results to the calling PISN user is beyond the scope of this Standard. NOTE 32 The connected PISN user’s number may be different from the called PISN user’s number because of local functions at the destination PINX. Such actions are outside the scope of this Standard. Depending on the behaviour of the called PISN user, the PISN shall indicate to the calling PISN user that the called PISN user is being alerted (REPORT_indication).

- 13 -

When the called PISN user has answered, the PISN shall give confirmation (SETUP_confirmation) of the call establishment request to the calling PISN user. The confirmation shall contain: • the connected PISN user's subaddress, and/or • the Low Layer Compatibility information, if either were contained in the SETUP_response sent by the called PISN user. For certain service categories the network shall also provide in-band tones and announcements to the calling PISN user during call establishment, see clauses 7 and 8. The PISN user shall receive an indication of the presence of an in-band tone or announcement (REPORT_indication). 9.2.2

Call establishment at the called PISN user If the PISN is able to route the call to the requested destination, (taking account of other relevant information in the service request), it shall transfer an incoming call indication (SETUP_indication) across the service access point to the called PISN user. The incoming call indication shall include the following items of information: a) Bearer Capability information; b) Low Layer Compatibility information, if provided by the calling PISN user; c) High Layer Compatibility information, if provided by the calling PISN user; d) the Destination Subaddress, if provided by the calling PISN user; e) if multiple numbers have been arranged at the access, the network shall provide the Destination Number; f) the Originating Subaddress, if provided by the calling PISN user. If the called PISN user enters an alerting phase, the PISN user shall transfer a REPORT_request across the service access point to the PISN. In order to accept the call, the called PISN user shall transfer across the service access point, a response to the incoming call indication (SETUP_response). The network shall then complete the connection for user information between the calling and called PISN users, in accordance with the service requested. For case (e) above, the PISN user accepting the call shall provide its number (Connected Number) to the network with the SETUP_response. The PISN shall screen the provided Connected number. If the Connected Number is determined to be one of the numbers assigned to that access, the PISN shall use this Connected Number and classify it “USER PROVIDED, VERIFIED AND PASSED”. If no Connected Number is provided or it is determined not to be part of the set of multiple numbers assigned to that access, the PISN shall provide a pre-arranged default Connected Number classified as “NETWORK PROVIDED”. For the format and type of number see ECMA-155. NOTE 33 The presentation of the Originating Number and Subaddress and the screening results to the called PISN user is beyond the scope of this Standard. Where there is more than one destination service access point which is compatible with the requirements of the call (Bearer Capability, Destination Number and, if supplied, Destination Subaddress, Low Layer Compatibility, High Layer Compatibility), the PISN shall transfer the SETUP_indication across all compatible service access points. The first REPORT_request received shall result in a REPORT_indication being transferred to the calling PISN user. The PISN shall award the call to the first service access point across which a SETUP_response is received from the PISN user. The network shall send a RELEASE_request across any other service access points across which the SETUP_indication was sent. The SETUP_response may include, as a PISN user option, the connected PISN user’s own subaddress (i.e., Connected Subaddress), and/or low layer compatibility information.

- 14 -

9.2.3

Terminating the service (call release) The call can be released by either of the PISN users. A PISN user shall release a call by transferring a request for release (RELEASE_request) across its service access point. The network shall: • transfer back across the (RELEASE_confirmation),

same

service

access

point

confirmation

release

• transfer an indication of release (RELEASE_indication) with an appropriate cause across the other PISN user’s service access point, and • expect to receive a RELEASE_response from that PISN user. For certain services an in-band tone or announcement may accompany the RELEASE_indication.

9.3

Exceptional procedures / unsuccessful outcome In the event that the network is unable to establish a call, it shall give an indication of release (RELEASE_indication) with an appropriate cause to the calling PISN user and cease call establishment. The cause shall include an indication of the location at which the failure occurred, i.e., the network (PISN) or the remote PISN user’s terminal equipment. The network shall be prepared to receive a RELEASE_response from the calling PISN user. If the called PISN user cannot accept a call, the PISN user may transfer a RELEASE_request with an appropriate cause to the network. The network shall transfer a RELEASE_confirmation back across the same service access point. If no SETUP_response is received across any service access point across which the SETUP_request was transferred, the network shall transfer a RELEASE_indication with an appropriate cause across the calling PISN user’s service access point; and shall be prepared to receive a RELEASE_response. For certain services the network may also provide in-band tones and announcements in the event of failure. The PISN shall give an indication of the presence of an in-band tone or announcement (REPORT_indication) to the PISN user. The main categories of service failure are as listed below. • Failure situations due to calling PISN user error a) A PISN user inputs a network identifiable improper service request. b) A PISN user inputs a non-valid Destination Number (or fails to input a valid number in the time allowed). c) A PISN user requests a service in contradiction to the service profile of the service access point, e.g., particular basic service not allowed, outgoing calls barred. • Failure situations due to called PISN user state a) There is no destination service access point which is compatible with the requirements of the call, i.e., the Bearer Capability and Destination Number. b) The incoming call is barred according to the service profile of the called service access point(s), e.g., particular basic service not allowed, incoming calls barred, interconnection of the calling and called service access points barred. c) There is a lack of resources at all compatible destination service access points. • Failure situations due to network conditions a) The network is unable to comply with the call request because of temporary lack of resources, e.g., all information channels at the calling PISN user are busy, all suitable network paths are busy. b) The network is unable to comply with the call request because of medium term or long term conditions, e.g., no route to the required destination for the basic service concerned, equipment out of service.

- 15 -

• Rejection of the call by the called PISN user a) The called PISN user is unable to comply with the call request attributes. This decision can be based on any of the following: Destination Number, Destination Subaddress, Bearer Capability information, Low Layer Compatibility information, High Layer Compatibility information, or for any other reason. b) The called PISN user is unable to comply with the call request because of temporary lack of resources. • Absence of response from called PISN user a) The called PISN user fails to enter an alerting phase or answer within a defined period of time after being given an incoming call indication. b) The called PISN user fails to answer within a defined period of time after entering an alerting phase. NOTE 34 This results in an unsuccessful call.

Interworking Interworking occurs when the Network Layer spans across the PISN operator’s and other network operators’ domains.

10.1 10.1.1

General Interworking considerations I n c o m in g c a lls An incoming call to a PISN occurs when a PISN user is the called user. The other network can provide the originating number in the setup indication. The interpretation of any screening information may be considered as an implementation matter. The PISN shall include in the SETUP_indication to the called PISN user, an indication of interworking and the type of the other network (ISDN or non-ISDN). Certain information can be missing from the SETUP_indication on account of it not being provided by the other network. The details of this information and the default mechanism required to cope with their non-availability are beyond the scope of this Standard. NOTE 35 In some countries interworking indications can be mandatory for regulatory reasons.

10.1.2

O u t g o in g c a lls An outgoing call from a PISN occurs when a PISN user is the calling user. The PISN may provide (either in a REPORT_indication or in the SETUP_confirmation) to the calling PISN user, an indication of interworking and the type of the other network (ISDN or non-ISDN). NOTE 36 In some countries interworking indications can be mandatory for regulatory reasons. NOTE 37 In some situations, the PISN may discard information provided by the calling user for delivery to the called user, if the capability of the other network is limited. When a call is rejected by the other network, then depending on the capabilities of this network, the PISN may send a special cause indication (i.e., other than those normally used within a PISN) to the calling user. The cause shall as a minimum indicate that the location of the failure is beyond the PISN. Some other networks can provide in-band tones and announcements during call establishment for certain services. Unless the PISN can provide alternative indications to the calling user, it shall establish at least a backward connection of information channels so that tones and announcements are conveyed to the calling PISN user. The default mechanism required to cope with the non-availability of detailed information to the other network is beyond the scope of this Standard.

- 16 -

10.1.3

P I S N t r a n s it c a lls A transit call occurs when neither user is a PISN user and the call is routed through the PISN in order to get from the calling user’s network to the called user’s network. NOTE 38 There can be restrictions for this type of call because of, for example, regulatory or transmission requirements.

10.2 10.2.1

Interworking with public-ISDN Receipt of service request from a public ISDN Subclause 10.1.1 applies. The details of the information which an incoming call request can indicate to the PISN are beyond the scope of this Standard. It however depends on the interworking situations and on the capabilities available in the public ISDN. For an incoming call, the PISN shall be able to accept the following information: a) Bearer Capability information defining the bearer capabilities required by the public ISDN; b) Low Layer Compatibility and High Layer Compatibility information from the calling user; c) a number identifying the called PISN user (Destination Number), e.g., provided by the DDI supplementary service of a public ISDN; d) the called PISN user’s subaddress (Destination Subaddress), e.g., provided by the Subaddressing supplementary service of a public ISDN; e) the calling user’s number (Originating Number) provided by the Calling Line Identification Presentation supplementary service of a public ISDN; f) the calling user’s subaddress (Originating Subaddress), provided by the Calling Line Identification Presentation supplementary service of a public ISDN. The Bearer Capability consists of a list of the low layer attributes of the required bearer service. It can also include additional low layer protocol information which is not required in order to indicate the service, but which could be of use in certain interworking situations. Due to the prevailing interworking situation, the Bearer Capability indicated to the PISN can be a default value, and need not reflect the Bearer Capability originally requested by the calling user. In this case, the PISN shall forward the Bearer Capability and the default indication to the PISN user. The Destination Number consists of the number digits, the identification of the numbering plan and the type of number, in accordance with ITU-T Rec. I.251.1. If the DDI supplementary service does not apply, the Destination Number may not be provided. The further treatment of such an incoming call request is a PISN option and beyond the scope of this Standard. The PISN shall not screen the Originating Number received from a public ISDN. For the parameters received with the Originating Number see ITU-T Rec. I.251.3. NOTE 39 The presentation of the Originating Number and Originating Subaddress to the called PISN user is beyond the scope of this Standard. The PISN shall pass the Low Layer Compatibility information, High Layer Compatibility information, and the Destination Subaddress, if provided, to the called PISN user.

10.2.2

Sending a service request to a public ISDN Subclause 10.1.2 applies. NOTE 40 The specification of the calling PISN user’s identity that is sent to a public ISDN is beyond the scope of this Standard.

- 17 -

10.2.3

Receipt of a service response from public ISDN The details of the information which an outgoing call response can indicate to the PISN are beyond the scope of this Standard. They can depend on the interworking situations and/or on the availability of certain capabilities from a public ISDN. The information that the PISN shall be prepared to accept and pass on to the calling PISN user is listed below: a) the connected user’s number (Connected Number) provided by the Connected Line Identification Presentation supplementary service of a public ISDN; b) the connected user’s subaddress (Connected Subaddress), provided by the Connected Line Identification Presentation supplementary service of a public ISDN; c) Low Layer Compatibility information from the connected user. The PISN shall not screen the Connected Number received from a public ISDN. The parameters received with the Connected Number are specified in ITU-T Rec. I.251.5. NOTE 41 The presentation of the Connected Number and Connected Subaddress to the calling PISN user is beyond the scope of this Standard.

10.2.4

Sending service response to public ISDN The details of the information that the PISN can provide to the public ISDN are beyond the scope of this Standard. The PISN shall if permitted indicate the condition "interworking with a private ISDN" in the SETUP_response sent to the public ISDN. The PISN may if appropriate indicate the progress of the call to the public ISDN (e.g., "alerting") by sending a REPORT_indication.

Dynamic Description Figure 3 contains the overall dynamic description (using SDL conventions), of a basic call within a PISN. The SDL diagram shall be interpreted as follows: a) The SDL process represents the behaviour of the Network Call Control entity. b) Input signals from the left and output signals to the left represent primitives from and to the calling PISN user. c) Input signals from the right and output signals to the right represent primitives from and to the called PISN user. d) The offering of a call to more than one destination service access point is not shown. e) Interworking with other networks is not shown. f) The following states are used: • IDLE – no call in progress; • AWAIT DESTINATION NUMBER – the network is awaiting further Destination Number information from the calling PISN user; • AWAIT CALLED USER RESPONSE – an indication of the incoming call has been sent to the called PISN user but no response has been received; • AWAIT ANSWER – a report of alerting has been received from the called PISN user but answer has not occurred; • ACTIVE – the call has been answered; • AWAIT CALLING USER RELEASE – an indication of release has been sent to the calling PISN user and a response is awaited; • AWAIT CALLED USER RELEASE – an indication of release has been sent to the called PISN user and a response is awaited.

- 18 -

Idle

SETUP_ request A N

request valid? Y Destination Number complete?

Await Destination Number

Y Y

Able to establish call to destination? N

RELEASE_ request

SETUP_ indication

RELEASE_ indication

RELEASE_ confirmation

Await Called User Response

Await Calling User Release

Idle

Figure 3 - Stage 1 SDL diagram (sheet 1 of 2)

INFORMATION_ request

- 19 -

Await Called User Response

REPORT_ request

SETUP_ response

RELEASE_ request

REPORT_ indication

Await Answer

RELEASE_ request

SETUP_ response

RELEASE_ request

SETUP_ confirmation

Active

RELEASE_ request

RELEASE_ confirmation

RELEASE_ indication

Await Called User Release

Await Calling User Release

RELEASE_ response

Idle

Figure 3 - Stage 1 SDL diagram (sheet 2 of 2)

- 20 -

Section 3: Functional capabilities and information flows (stage 2 description) 12 12.1

Functional model Functional model description The internal behaviour of the Network Call Control is specified by dividing it into a number of functional entities, and by specifying the information flows between these functional entities. This has been described in general terms in clause 5.5. The particular functional entities used in the Functional Model for the Basic Call are specified below. The Basic Call model shall consist of two generic functional entities namely, • the Call Control Agent (CCA), and • the Call Control (CC); and three functional relationships, defined as: • r1 – the access relationship at the originating side between a Call Control Agent functional entity and a Call Control functional entity, and • r2 – the distributive relationship between a Call Control functional entity and another Call Control functional entity. • r3 – the access relationship at the destination side between a Call Control Agent functional entity and a Call Control functional entity.

User primitives

r2 relationship

relationship

Originating CCA

Originating CC

r2 relationship

r3 relationship

Destination CC

Transit CC

User primitives

Destination CCA

r2 relationship Gateway CC

Transit CC

r2 relationship

r2* relationship

Figure 4 – Stage 2 model An additional type of r2 relationship is used in clause 14; it is called r2*, and shall be the relationship between the Gateway CC functional entity of a PISN and the access CC functional entity of a public ISDN. The definition of the r2* relationship is beyond the scope of this Standard. The functional model is shown in figure 4. The arrows between the PISN users and the CCA represent PISN user primitives, the arrows between the CC functional entities and either CC functional entities or CCA functional entities represent information flows.

12.2

Description of the functional entities The allocation of the functional entities (that are described in this clause) to physical entities, is given in clause 16. The allocation is done on a per call basis. NOTE 42 Examples of the use of these functional entities, in conjunction with the Stage 2 model are shown in figures 6 to 15.

- 21 -

12.2.1

C a ll C o n t r o l A g e n t f u n c t io n a l e n t it y The Call Control Agent functional entity (CCA functional entity) is that part of the Network Call Control that serves the PISN user. It is responsible for: • formulating requests to, and • responding to indications from the network that is providing the Basic Services. Within this Standard the following types of CCA functional entity are described: • Originating CCA functional entity, and • Destination CCA functional entity.

12.2.1.1

Originating CCA functional entity An Originating CCA functional entity is the CCA functional entity that serves the PISN user that has initiated the Basic Service request. The Originating CCA functional entity shall have the following capabilities: • ability to access the service-providing capabilities of the CC functional entities, using service requests for the establishment and release of a single call, • ability to receive indications relating to the call from the CC functional entity and relay them to the PISN user, • ability to maintain call state information as perceived from this functional end-point of the call (i.e. a single ended view of the call). NOTE 43 Other capabilities that the Originating CCA functional entity can have are beyond the scope of this Standard and are therefore not specified.

12.2.1.2

Destination CCA functional entity A Destination CCA functional entity is the CCA functional entity that serves the PISN user at which the call terminates. The Destination CCA functional entity shall have the following capabilities: • ability to establish and release a single incoming call, • ability to receive indications relating to the call from the CC functional entity and relay them to the PISN user, • ability to maintain call state information as perceived from this functional end-point of the call (i.e., a single ended view of the call). NOTE 44 Other capabilities that the Destination CCA functional entity can have are beyond the scope of this Standard and are therefore not specified.

12.2.2

C a ll C o n t r o l f u n c t io n a l e n t it y The Call Control functional entity (CC functional entity) is the functional entity within the network that co-operates with other Call Control functional entities to provide the Basic Service requested by the CCA functional entity. There are different types of CC functional entities each with specific capabilities. Within this Standard the following types of CC functional entities are specified: • Originating CC functional entity, • Transit CC functional entity, • Destination CC functional entity, • Incoming Gateway CC functional entity, • Outgoing Gateway CC functional entity.

- 22 -

12.2.2.1

O r ig in a t in g C C f u n c t io n a l e n t it y An Originating CC functional entity is the functional entity within the network that has a direct relationship with the Originating CCA functional entity. The Originating CC functional entity shall have the following capabilities: • the ability to establish, and release a single call, upon request of the Originating CCA functional entity, • the ability to associate and mediate between the Originating CCA functional entity and the subsequent CC functional entity involved in a particular call. An Originating CC functional entity may also have the following capability: • the ability to provide tones and announcements. The ability to process the Basic Service request can include the ability to validate any Basic Service request against any relevant service profile appertaining to the PISN user. NOTE 45 Other capabilities that Originating CC functional entities can have are beyond the scope of this Standard and are therefore not specified.

12.2.2.2

D e s t in a t io n C C f u n c t io n a l e n t it y A Destination CC functional entity is the functional entity within the network that has a direct relationship with the Destination CCA functional entity. The Destination CC functional entity shall have the following capabilities: • the ability to establish, and release a single call to the Destination CCA functional entity, on behalf of the network, • the ability to associate and mediate between the Destination CCA functional entity and the preceding CC functional entity involved in a particular call. A Destination CC functional entity may also have the following capabilities: • the ability to mediate between more than one Destination CCA functional entities during the call setup phase. • the ability to provide tones and announcements. The ability to process the Basic Service request can include the ability to validate any Basic Service request against any relevant service profile appertaining to the PISN user. NOTE 46 Other capabilities that the Destination CC functional entity can have are beyond the scope of this Standard and are therefore not specified.

12.2.2.3

Tr a n s it C C f u n c t io n a l e n t it y A Transit CC functional entity is the CC functional entity within the network that has a direct relationship with other CC functional entities that are within the PISN. The Transit CC functional entity shall have the following capabilities: • the ability to establish, and release a single call between two CC functional entities, • the ability to associate and mediate between the CC functional entities involved in a particular call. A Transit CC functional entity may also have the following capability: • the ability to provide tones and announcements. NOTE 47 Other capabilities that the Transit CC functional entity can have are beyond the scope of this Standard and are therefore not specified.

- 23 -

12.2.2.4

I n c o m in g a n d O u t g o in g G a t e wa y C C f u n c t io n a l e n t it ie s A Gateway CC functional entity is the functional entity within the PISN that interworks with the access functional entity of another network. Depending on whether the call originates in the PISN or in the other network, the gateway CC functional entity may be either an Incoming Gateway CC functional entity or an Outgoing Gateway CC functional entity. A Gateway CC functional entity shall have the same capabilities as a Transit CC functional entity. NOTE 48 Gateway CC functional entities can have other capabilities depending upon the type of network that it is interworking with. The particular capabilities of the Gateway CC are determined by the level of signalling that is available for interworking to the other network. These additional capabilities are beyond the scope of this Standard. NOTE 49 In the scenario where the network that is being interworked with is a public ISDN, a high level of interworking of the information flows can take place. NOTE 50 Other capabilities, not related to interworking, that the Gateway CC functional entity can have are beyond the scope of this Standard and are therefore not specified.

Definition of information flows

13.1 13.1.1

Conventions used within the description of information flows C o n v e n t io n f o r t h e d e s c r ip t io n o f m a n d a t o r y o r o p t io n a l in f o r m a t io n In this document the information flows that support the Basic Call service have been divided into “service elements”. The service elements themselves have been divided where relevant into “service parameters”. The information content of each service parameter has been listed when necessary. In order to indicate the circumstances in which the various service elements and parameters are used, the following conventions are used. • M – the information flow shall contain the service element, (i.e., it is mandatory), • O – the information flow may contain the service element (i.e., it is optional). Unless stated otherwise, a service element shall be passed on at a Transit CC functional entity if the information flow is passed on. A similar convention is used for the parameters within the service elements. • m – the service element shall contain the service parameter, (i.e., it is mandatory), • o – the service element may contain the service parameter, (i.e., it is optional).

13.1.2

C o n v e n t io n f o r t h e n a m in g o f in f o r m a t io n f lo ws A sending FE shall regard an unconfirmed information flow as a “request”, and the receiving FE shall regard the same information flow as an “indication”. A sending FE shall regard the requesting half of a confirmed information flow as a “request”, and the receiving FE shall regard the same information flow as an “indication”. The sending FE shall regard the responding half of a confirmed information flow as a “response”, and the receiving FE shall regard the same information flow as a “confirmation”. An information flow of name “ABCD” is represented as “ABCD_request” or “ABCD_response” from the perspective of the sending FE. The information flow is represented as “ABCD_indication” or “ABCD_confirmation” from the perspective of the receiving FE. The information flow of name “ABCD” is represented as “ABCD_request/indication” or “ABCD_response/confirmation” when used in a context that is not from the perspective of a particular FE.

- 24 -

To show the use of an information flow across a particular relationship “rX” the name is preceded by “rX_” (e.g. r2_ABCD_request/indication). In clause 14 the primitive and information flows are shortened as follows: • “request” to “req”; • “indication” to “ind”; • “response” to “resp”; and • “confirmation” to “cfm”. Figure 5 shows information flows used in conjunction with the functional model, with the specific example shown of a confirmed information flow being initiated by the PISN user on the “left-hand side”. In clauses 14 and 15 the terms “Backward” and “Forward” are used. At a particular functional entity the direction towards the Originating PISN user is called the “Backward” direction. The direction towards the Destination PISN user is called the “Forward” direction.

User primitives

User primitives c

rq rq i

rq i CCA

CC c

r1 relationship

rq i CC

r2 relationship

rq i CC

CCA c

r2 relationship

r3 relationship

Legend – In the diagram the following abbreviations are used: – “rq” represents the “request information flow”, – “i” represents the “indication information flow”, – “rs” represents the “response information flow”, and – “c” represents the “confirmation information flow”. Figure 5 – Example of a confirmed information flow

13.2

SETUP A functional entity shall use the SETUP information flow to request the establishment of a connection. SETUP is a confirmed information flow. The responding part of SETUP shall confirm to the originating functional entity, that the requested connection has been established. In call failure situations other information flows (e.g. RELEASE) may replace the SETUP_response/confirmation. SETUP may be used within the relationships r1, r2 and r3. SETUP shall convey the service elements that are shown in table 1. The detailed contents of these service elements are shown in table 2.

- 25 -

Table 1 – Information content of SETUP Service element

Relationship

Request/Indication

Response/Confirmation

DN Destination Number

r1, r2, r3

M (note 1)

–

CN Connected Number

r2, r3

–

M (note 2)

ON Originating Number

r2, r1

M (note 3)

–

CT Connection Type

r1, r2, r3

M (note 4)

DS Destination Subaddress

r1, r2, r3

–

CS Connected Subaddress

r2, r3

–

OS Originating Subaddress

r2, r1

–

CI Channel Identifier

r1, r2, r3

M (note 5)

–

CH Call History

r1, r2, r3

O (note 6)

NOTE - The notes are same as those for table 2.

- 26 -

Table 2 – Detailed information content of SETUP Service element

Request/Indication

DN Destination Number

(note 1) –M Number – m Numbering plan identifier –m Type of number –m Number complete indicator (note 7) – o

CN Connected Number

–

ON Originating Number

(note 3) Number (note 8) Numbering plan identifier Type of number Presentation restriction Screening indicator

CT Connection Type (note 4) – – Circuit Mode Bearer: Information transfer capacity: 64 kbit/s unrestricted (note 10) 64 kbit/s unrestricted High layer compatibility Low layer compatibility Information transfer mode: circuit Information transfer rate: 64 kbit/s Establishment (note 9) Symmetry (note 9) Configuration (note 9) Low Layer Information layer 1 info layer 2 info layer 3 info CT Connection Type – Circuit Mode Bearer: Suitable for speech

(note 4) Information transfer capacity: speech High layer compatibility Low layer compatibility Information transfer mode: circuit Information transfer rate: 64 kbit/s Establishment (note 9) Symmetry (note 9) Configuration (note 9) Encoding (µ– or A–Law) continued...

Response/Confirmation

(note 2) Number (note 8) Numbering plan identifier Type of number Presentation restriction Screening indicator –M –m –m –m –m –m

–M –m –m –m –m –m

–

M Low layer compatibility

–O – o

Low layer compatibility

–O –o

–m –o –o –m –m –o –o –o –o –o –o –M –m –o –o –m –m –o –o –o –m

- 27 -

Table 2 – Detailed information content of SETUP (concluded) Service element

Request/Indication

CT Connection Type – Circuit Mode Bearer: Usable for 3,1 kHz audio

(note 4) Information transfer capacity: 3,1 kHz Audio High layer compatibility Low layer compatibility Information transfer mode: circuit Information transfer rate: 64 kbit/s Establishment (note 9) Symmetry (note 9) Configuration (note 9) Encoding (µ– or A–Law)

DS Destination Subaddress Subaddress Type of subaddress CS Connected Subaddress

Response/Confirmation –M Low layer compatibility –m –o –o –m –m –o –o –o –m –O –m –m

–

OS Originating Subaddress

–O –o

Subaddress Type of subaddress

–O –m –m

CI Channel Identifier

(note 5)

–M

CH Call History

–O Interworking with a public network (note 6) -o Signalling interworking: trunk release conditions (note 11) - o Signalling interworking: non-common channel signalling system (note 12) -o

Subaddress Type of subaddress –

–O –m –m

– –O Interworking with a public network (note 6) -o Signalling interworking: trunk release conditions (note 11) - o Signalling interworking: non-common channel signalling system (note 12) -o

- 28 -

NOTES to tables 1 and 2. 1. The SETUP request/indication across r3 shall contain DN where there is more than one PISN number associated with the called PISN user’s access, otherwise the use of DN is optional. 2. The SETUP response/confirmation across r3 shall contain CN, where there is more than one PISN number associated with the called user’s access, and the connected number differs from the destination number, otherwise the use of CN is optional. The SETUP response/confirmation across r2 shall contain CN except in the cases of interworking where it is not available. 3. The SETUP request/indication across r1 shall contain ON, where there is more than one PISN number associated with the calling PISN user’s access, otherwise the use of ON is optional. The SETUP request/indication across r2 shall contain ON, except in the cases of interworking where it is not available. 4. The support of individual Bearer Capabilities is a network option. 5. When used within SETUP_request/indication, the “Channel Identifier” service element may have the four values: “preferred channel”; “exclusive channel”; “no channel”, and “any free channel”. 6. The "Interworking with a public network" parameter is relevant in SETUP_request/indication across r2 and r3 and in SETUP_response/confirmation across r1 and r2. 7. This parameter may be present if the number is known to be complete. 8. The number may not be available due to interworking. 9. Only the default values specified in clauses 6.6, 7.6 and 8.6 of these service parameters are supported. 10. During an interim period, some other networks may only support restricted 64 kbit/s digital information transfer capability. It shall be possible to indicate a restricted 64 kbit/s digital information transfer capability for interworking with such a network. 11. There are 3 values for the "Signalling interworking - trunk release conditions" parameter: "no release"; "no release before answer"; and, "no release after answer". If this parameter is present but not supported, the call should be cleared. This parameter is relevant only across r2. 12. There are 4 values for the "Signalling interworking - non-common channel signalling system" parameter: "call is not end-to-end ISDN, further call progress information may be available in-band"; "destination address is non-ISDN"; "origination address is nonISDN"; and "call has returned to the ISDN". This parameter is relevant in SETUP_request/indication across r2 and r3 and in SETUP_response/confirmation across r1 and r2. Some values are relevant only in one direction, i.e., in SETUP_request/indication or in SETUP_response/confirmation.

13.3

REPORT A functional entity shall use the REPORT information flow to convey information relating to the progress of a call through the network. This information flow is not confirmed and may be used within relationships r1, r2 and r3. REPORT shall convey the service elements that are shown in table 3. The detailed contents of these service elements are shown in table 4. Table 3 – Information content of REPORT Service element

Relationship

Request/Indication

RT Report Type

r1, r2, r3

(note)

CH Call History

r2, r1

–M –O

CC Clearing Cause

r1, r2

(note)

–O

NOTE - Clearing Cause shall only be used in conjunction with the RT (Report Type) “Call Rejection”, and it is then mandatory.

- 29 -

Table 4 – Detailed information content of REPORT Service element

Request/Indication

RT Report Type

(note 1)

CH Call History

–O In-band information -o Interworking with a public network (note 2) -o Signalling interworking: trunk release conditions (note 4) -o Signalling interworking: non-common channel signalling system (note 5) -o (note 3) –O

CC Clearing Cause

–M

NOTES 1. RT may have three values: “User being alerted”; “interworking encountered”; and “call rejection”. 2. The "Interworking with a public network" parameter is relevant across r1 and r2. 3. The service element CC shall only be used in conjunction with “call rejection”. “Call rejection” shall only be used over r1 and r2. 4. There are 3 values for the "Signalling interworking - trunk release conditions" parameter: "no release"; "no release before answer"; and, "no release after answer". If this parameter is present but not supported, the call should be cleared. This parameter is relevant only across r2. 5. There are 3 values for the "Signalling interworking - non-common channel signalling system" parameter: "call is not end-to-end ISDN, further call progress information may be available in-band"; "destination address is non-ISDN"; and "call has returned to the ISDN". This parameter is relevant only across r1 and r2.

13.4

CHANNEL_ACKNOWLEDGE A functional entity shall use the CHANNEL_ACKNOWLEDGE information flow to confirm the channel allocation requested in the SETUP information flow. It may appear within relationships r1, r2 and r3. CHANNEL_ACKNOWLEDGE shall convey the service element that is shown in table 5. Table 5 – Information content of CHANNEL_ACKNOWLEDGE Service element

Relationship

Request/Indication

CI Channel Identifier

r1, r2, r3

(note)

–M

NOTE - The “Channel Identifier” service element when used within CHANNEL_ ACKNOWLEDGE_request/indication may have two values: “allocated channel” and “no channel”. The latter shall only be used over r3.

13.5

CHANNEL_CONNECT A functional entity shall use the CHANNEL_CONNECT information flow to indicate to a terminal competing for an incoming call, that it has been awarded the call, and that the terminal can connect to the agreed channel. CHANNEL_CONNECT shall be used over r3 only. The CHANNEL_CONNECTION information flow need not carry additional information.

13.6

DISCONNECT A functional entity shall use the DISCONNECT information flow to invite the release of a connection across relationships r1 and r3. DISCONNECT shall convey the service element that is shown in table 6.

- 30 -

Table 6 – Information content of DISCONNECT

13.7

Service element

Relationship

CC Clearing Cause

r1, r3

Request/Indication –M

RELEASE A functional entity shall use the RELEASE information flow for freeing the resources associated with the call/connection, (such as call references and channels). This is a confirmed information flow. The responding part of RELEASE shall confirm that all resources previously associated with the connection have been freed. It may be used within relationships r1, r2 and r3. RELEASE shall convey the service element that is shown in table 7. Table 7 – Information content of RELEASE Service element

Relationship

Request/Indication

CC Clearing Cause

r1, r2, r3

(note)

Response/Confirmatio n

–O

–

NOTE - Mandatory, if no previous DISCONNECT, otherwise optional.

13.8

INFORMATION A functional entity shall use the INFORMATION information flow to convey additional address information over r1 and r2 after SETUP has been sent. It is an unconfirmed information flow. INFORMATION shall convey the service elements that are shown in table 8. Table 8 – Information content of INFORMATION Service element

Relationship

DN Destination Number

r1, r2

NC Number complete indication

r1, r2

Request/Indication –M (note)

–O

NOTE - “Number complete” shall only be sent when the FE has determined that the last digit of DN has been received.

13.9

SETUP_REJECT A functional entity shall send a SETUP_REJECT information flow over a single r1, r2 or r3 relationship to reject a SETUP_indication that it has received, but for some reason it cannot successfully process. It is an unconfirmed information flow. SETUP_REJECT shall convey the service element that is shown in table 9. Ta b le 9 – I n f o r m a t io n c o n t e n t o f S ETU P _ R EJ EC T Service element

Relationship

CC Clearing Cause

r1, r2, r3

Request/indication –M

- 31 -

13.10 PROCEEDING A functional entity shall use the PROCEEDING information flow (when using digit-by-digit signalling) to indicate that all address information has been received, and that the call is being processed by the subsequent CCs. It is used in the relationships r1 and r2. For some calls other information flows (e.g., SETUP_response/confirmation) may convey the information included in PROCEEDING. PROCEEDING may convey the service element that is given in table 10. Table 10 – Information content of PROCEEDING

Service element

Relationship

CI Channel Identifier

r1, r2

Request/Indication –O

Information flow sequences Below are information flow sequences that shall be taken into account during the detailed specification of Stage 3. These sequences constrain the Stage 3 to the extent that is required in order to guarantee interoperability between different implementations. In particular the diagrams shown in clauses 14.2 to 14.11 are typical cases representing the most important information flow sequences. The information flows that are shown in the r2* relationship are informative. NOTE 51 In this clause, the terms “backward” and “forward” are used. At a particular functional entity the direction towards the Originating PISN user is called the “Backward” direction. The direction towards the Destination PISN user is called the “Forward” direction.

14.1

Functional entity actions The functional entities that are applicable to these particular information flow sequences shall have the capabilities described below. The particulars of the information in the primitives between the CCA functional entities and the PISN users is beyond the scope of this Standard.

14.1.1

Originating CCA functional entity

• Function 000 – The SETUP_request primitive from the Originating PISN user’s request for service is processed, and the r1_SETUP_request is formulated and sent to the Originating CC functional entity.

• Function 001 – The r1_CHANNEL_ACKNOWLEDGE_indication is processed and the allocated channel is connected and cut-through to the PISN user, at least in the backward direction.

• Function 002 – The r1_REPORT_indication is processed. Because the incoming RT (Report Type) is

“alerting”, a REPORT_indication primitive marked as alerting is sent to the Originating PISN user. The allocated channel should then be connected and cut-through to the PISN user at least in the backward direction, if not already done.

• Function 003 – The r1_SETUP_confirmation is processed and the allocated channel is connected and

cut through to the PISN user in both directions, if not already done. A SETUP_confirmation primitive is sent to the Originating PISN user.

• Function 006 – The r1_REPORT_indication is processed. As the incoming REPORT contains Report

Type “Call Rejection”, and Call History “In-Band Information”, a REPORT_indication primitive marked as “call rejection” is sent to the Originating PISN user. The allocated channel is then connected and cut-through to the PISN user in the backward direction, if not already done.

• Function 007 – The r1_REPORT_indication is processed. As the incoming REPORT contains Report Type “interworking encountered”, and Call History “In-Band Information”, a REPORT_indication primitive marked as “interworking” is sent to the Originating PISN user. The allocated channel is then connected and cut-through to the PISN user in the backward direction, if not already done.

- 32 -

• Function 010 – The r1_DISCONNECT_indication is processed; and a RELEASE_indication primitive is formulated and sent to the Originating PISN user.

• Function 011 – The RELEASE_response primitive from the Originating PISN user is processed, and a r1_RELEASE_request is formulated and sent to the Originating CC functional entity.

• Function 012 – The r1_RELEASE_confirmation is processed and the resources are released. • Function 015 – The INFORMATION_request primitive is processed and a r1_INFORMATION_request is sent to the Originating CC functional entity.

• Function 016 – The r1_PROCEEDING_indication is processed. A REPORT_indication primitive marked as "call proceeding" is sent to the Originating PISN user.

14.1.2

O r ig in a t in g C C f u n c t io n a l e n t it y

• Function 100 a) The r1_SETUP_indication is processed. b) The incoming information channel is reserved and a r1_CHANNEL_ACKNOWLEDGE_request is sent to the Originating CCA functional entity. c) An outgoing information channel is reserved, based on the Destination Number and Connection Type information in the r1_SETUP_indication. NOTE 52 The selection can also be dependant upon other information beyond the scope of this Standard. d) The r2_SETUP_request is generated and sent. The Originating Subaddress, the Destination Subaddress, or the Connection Type parameters, Low Layer Compatibility and High Layer Compatibility contained in the r1_SETUP_request, are carried in the r2_SETUP_request unchanged. The Originating Number in the r1_SETUP_request is screened at the CC functional entity. If the Originating Number is determined to be one of the numbers assigned to r1, the CC functional entity uses this Originating Number and classifies it “USER PROVIDED, VERIFIED AND PASSED”. If no Originating Number is provided or it is determined not to be part of the set of multiple numbers assigned to that access, the CC functional entity provides a pre-arranged default Originating Number classified as “NETWORK PROVIDED”. For the format and type of number see ECMA-155.

• Function 101 – The r2_CHANNEL_ACKNOWLEDGE_indication is processed and the allocated channel should be connected and cut-through in the backward direction. The information channel may also be cut-through in the forward direction.

• Function 102 – The r2_REPORT_indication from the subsequent CC functional entity is processed.

As the incoming REPORT contains Report Type “alerting”, a r1_REPORT_indication marked as alerting is sent to the Originating CCA functional entity. The allocated channel should then be connected and cut-through in the backward direction, if not already done.

• Function 103 – The r2_SETUP_confirmation is processed and the information channel shall be cutthrough in both directions, if not cut-through already. A r1_SETUP_response is generated and then sent to the Originating CCA functional entity. The Connection Type parameter, contained in the r2_SETUP_confirmation is carried in the r2_SETUP_response unchanged.

• Function 106 – The r2_REPORT_indication from the subsequent CC functional entity is processed.

As the incoming REPORT contains Report Type “call rejection”, and Call History “In-Band Information”, a r1_REPORT_indication marked as “Call Rejection” is sent to the Originating CCA functional entity. The information channel should then be connected and cut-through in the backward direction, if not already done.

• Function 107 – The r2_REPORT_indication is processed. As the incoming REPORT contains Report Type “interworking encountered”, and Call History “In-Band Information”, a r1_REPORT_request

- 33 -

marked as “interworking” is sent to the Originating CCA. The allocated channel should then be connected and cut-through to the PISN user in the backward direction, if not already done.

• Function 110 a) The r2_RELEASE_indication is processed. b) A r2_RELEASE_response is formulated and sent to the subsequent CC functional entity. c) A r1_DISCONNECT_request is formulated and sent to the Originating CCA functional entity, and the resources are disconnected. d) The resources are released in the direction of the subsequent CC functional entity. NOTE 53 This Standard does not exclude the possibility of additional implementation procedures that do not result in the call being released, e.g., alternate routeing.

• Function 111 – The r1_RELEASE_indication from the Originating CCA functional entity is

processed. A r1_RELEASE_response is sent to the Originating CCA functional entity, and the resources are released in the direction of the Originating CCA functional entity.

• Function 112 a) The r1_SETUP_indication is processed. b) The incoming information channel is reserved. c) A r1_CHANNEL_ACKNOWLEDGE_request is sent to the Originating CCA functional entity.

• Function 113 – The r1_INFORMATION_indication is received and analysed. Check whether an outgoing setup is possible.

• Function 115 – The r1_INFORMATION_indication is processed and a r2_INFORMATION_ request is sent to the Subsequent CC functional entity.

• Function 116 a) The r1_INFORMATION_indication is received and analysed. b) Check whether outgoing call setup is possible. c) The r2_SETUP_request is generated and sent. The Originating Subaddress, the Destination Subaddress, or the Connection Type parameters, Low Layer Compatibility and High Layer Compatibility contained in the r1_SETUP_request, are carried in the r2_SETUP_request unchanged. The Originating Number in the r1_SETUP_request is screened at the CC functional entity. If the Originating Number is determined to be one of the numbers assigned to r1, the CC functional entity uses this Originating Number and classifies it “USER PROVIDED, VERIFIED AND PASSED”. If no Originating Number is provided or it is determined not to be part of the set of multiple numbers assigned to that access, the CC functional entity provides a pre-arranged default Originating Number classified as “NETWORK PROVIDED”. For the format and type of number see ECMA-155. • Function 117 – The r2_PROCEEDING_indication is processed. A r1_PROCEEDING_request is sent to the Originating CCA. 14.1.3

Tr a n s it C C f u n c t io n a l e n t it y

• Function 200 a) The r2_SETUP_indication is processed. b) The incoming information channel is reserved and a r2_CHANNEL_ACKNOWLEDGE_request is sent. c) An outgoing information channel is reserved, based on the Destination Number (DN) and Connection Type (CT) information in the r2_SETUP_indication.

- 34 -

NOTE 54 The selection can also be dependant upon other information beyond the scope of this Standard. d) The r2_SETUP_request is generated and sent. The Originating Number, Originating Subaddress, Destination Subaddress, Call History information and the Connection Type parameters, Low Layer Compatibility and High Layer Compatibility, contained in the r2_SETUP_indication, are carried in the r2_SETUP_request.

• Function 201 – The r2_CHANNEL_ACKNOWLEDGE_indication is processed and the allocated channel is connected and cut-through in the backward direction; the information channel may also be cut-through in the forward direction.

• Function 202 – The r2_REPORT_indication is processed. As the incoming REPORT contains Report Type “alerting”, a r2_REPORT_request marked as “alerting”, is sent to the preceding CC functional entity. The allocated channel should then be connected and cut-through in the backward direction, if not already done.

• Function 203 – The r2_SETUP_confirmation is processed and the information channel is cut-through

in the forward direction, if not cut-through already. A r2_SETUP_response is generated and then sent to the preceding CC functional entity. The Connected Number, Connected Subaddress, or the Connection Type parameter, contained in the r2_SETUP_confirmation, are carried in the r2_SETUP_response.

• Function 206 – The r2_REPORT_indication is processed. As the incoming REPORT contains Report Type “call rejection”, and Call History “In-Band Information”, a r2_REPORT_request marked as “Call Rejection” is sent to the preceding CC functional entity. The information channel is then connected and cut-through in the backward direction, if not already done.

• Function 207 – The r2_REPORT_indication is processed. As the incoming REPORT contains Report Type “interworking encountered”, and Call History “In-Band Information”, a r2_REPORT_request marked as “interworking” is sent to the preceding CC. The allocated channel is then connected and cut-through to the PISN user in the backward direction, if not already done.

• Function 210 a) The r2_RELEASE_indication is processed. b) A r2_RELEASE_response is formulated and sent to the subsequent CC functional entity. c) A r2_RELEASE_request is formulated and sent to the preceding CC functional entity; and the resources are disconnected, and then released in the direction of the subsequent CC functional entity. NOTE 55 This Standard does not exclude possible implementation specific procedures that do not result in the call being released, e.g., alternate routeing.

• Function 211 – The r2_RELEASE_confirmation from the preceding CC functional entity is processed, and the resources are released in the direction of the preceding CC functional entity.

• Function 216 a) The r2_INFORMATION_indication is received and analysed. b) Formulate and send r2_INFORMATION_request with a “number complete” indication. c) Send r2_PROCEEDING_request to Originating CC functional entity. 14.1.4

D e s t in a t io n C C f u n c t io n a l e n t it y

• Function 300 a) The r2_SETUP_indication is processed. b) The incoming information channel is reserved and a r2_CHANNEL_ACKNOWLEDGE_request is sent.

- 35 -

c) An outgoing information channel is reserved, based on the Destination Number (DN) and Connection Type (CT) information in the r2_SETUP_indication. NOTE 56 The selection can also be dependant upon other information beyond the scope of this Standard. d) The r3_SETUP_request is generated and sent. The Destination Subaddress, Call History information or the Connection Type parameters, Low Layer Compatibility or High Layer Compatibility contained in the incoming r2_SETUP_indication are carried in the r3_SETUP_request.

• Function 301 – The r3_CHANNEL_ACKNOWLEDGE_indication is processed and the allocated channel is reserved.

• Function 302 – The r3_REPORT_indication from the Destination CCA functional entity is processed.

As the incoming REPORT contains Report Type “alerting”, a r2_REPORT_request marked as “alerting” is sent to the preceding CC functional entity. If the Bearer service requested was Speech, or 3,1 kHz, then Ring tone is applied towards the Originating CCA functional entity.

• Function 303 a) The r3_SETUP_confirmation is processed. If Ring Tone had been applied towards the Originating CCA functional entity it is removed. b) The information channel is connected and cut-through in both forward and backward directions. c) A r2_SETUP_response is generated and then sent to the preceding CC functional entity. The Connected Number, Connected Subaddress, and the Connection Type parameters, contained in the r3_SETUP_confirmation, are carried in the r2_SETUP_response. The Connected Number is screened by the CC functional entity. If the Connected Number is determined to be one of the numbers assigned to that access, the CC functional entity uses this Connected Number and classifies it “USER PROVIDED, VERIFIED AND PASSED”. If the Connected Number is provided and it is determined not to be part of the set of multiple numbers assigned to that access, the CC functional entity provides a pre-arranged default Connected Number classified as “NETWORK PROVIDED”. For the format and type of number see ECMA-155. d) Also a r3_CHANNEL_CONNECT_request is generated and sent to the Destination CCA functional entity. In the case where more than one CCA functional entity has responded, the CC functional entity shall release all the CCA functional entities other than the one that has been awarded the call.

• Function 310 a) The r3_DISCONNECT_indication is processed. b) A r3_RELEASE_request is formulated and sent to the Destination CCA functional entity. c) A r2_RELEASE_request is formulated and sent to the preceding CC functional entity. d) The resources are disconnected.

• Function 311 – The r3_RELEASE_confirmation from the Destination CCA functional entity is processed; and the resources are released in the direction of the Destination CCA functional entity.

• Function 312 – The r2_RELEASE_confirmation from the preceding CC functional entity is processed; and the resources are released in the direction of the preceding CC functional entity.

• Function 314 a) The r2_SETUP_indication is processed. b) The incoming information channel is reserved and a r2_CHANNEL_ACKNOWLEDGE_request is sent.

- 36 -

• Function 315 a) The r2_INFORMATION_indication is received and analysed. b) An outgoing information channel is reserved, based on the Destination Number (DN) and Connection Type (CT) information in the r2_SETUP_indication. c) The r3_SETUP_request is generated and sent. The Destination Subaddress, Call History information or the Connection Type parameters, Low Layer Compatibility or High Layer Compatibility contained in the incoming r2_SETUP_indication, are carried in the r3_SETUP_request.

• Function 320 – The r3_SETUP_REJECT_request is processed, and a r2_RELEASE_request is sent to the preceding CC functional entity. Resources are released in the direction of the Destination CCA.

• Function 321 – The r3_SETUP_REJECT_request is processed, and because the Destination CC wants to offer an in-band indication, a r2_REPORT_request is sent to the preceding CC. The in-band source is applied to the information channel.

14.1.5

Destination CCA functional entity

• Function 400 a) The r3_SETUP_indication is processed. b) A r3_CHANNEL_ACKNOWLEDGE_request is sent. c) The addressing and compatibility requirements contained within the r3_SETUP_indication are processed to ascertain if the call request should be passed to the PISN user. The information within the r3_SETUP_indication that shall be checked is the Connection Type, Destination Number, Low Layer Compatibility, and High Layer Compatibility. d) A SETUP_indication primitive is generated and sent to the PISN user.

• Function 401 – The REPORT_request primitive marked as alerting from the Destination PISN user is processed, and a r3_REPORT_request with a Report Type of “alerting” is sent to the Destination CC functional entity.

• Function 402 – The SETUP_response primitive from the Destination PISN user is processed, and a

r3_SETUP_response is sent to the Destination CC functional entity. In this example the Connected Number, the Connected Subaddress, and the Connection Type parameters are carried in the r3_SETUP_response. The information channel is cut-through in the forward direction, if not cutthrough already.

• Function 403 – The r3_CHANNEL_CONNECT_indication is processed and the information channel is cut-through in both the forward and backward directions.

• Function 410 a) The RELEASE_request primitive from the Destination PISN user is processed. b) A r3_DISCONNECT_request is formulated and sent to the Destination CC functional entity. c) The resources are disconnected.

• Function 411 a) The r3_RELEASE_indication from the Destination CC functional entity is processed. b) A r3_RELEASE_response is sent to the Destination CC functional entity; and the resources are released. c) A RELEASE_confirmation primitive is then sent to the Destination PISN user.

• Function 420 a) The RELEASE_request primitive from the Destination PISN user is processed.

- 37 -

b) A r3_SETUP_REJECT_request is sent to the Destination CC functional entity, and the resources are released in both directions. c) A RELEASE_confirmation primitive is returned to the PISN user. The r3_SETUP_REJECT_request/indication contains a CC service element. 14.1.6

I n c o m in g g a t e wa y C C f u n c t io n a l e n t it y The information flows at r2* are provided for information purposes only as they are outside the scope of this Standard.

• Function 130 – On receipt of an incoming call from the other network, an outgoing information

channel is reserved, based on the Destination Number and Connection Type information that is available from the other network. Then a r2_SETUP_request is sent to the subsequent CC functional entity. The r2_SETUP_request primitive contains an appropriate Call History parameter.

NOTE 57 The information flows between the CC functional entity and a non-ISDN are beyond the scope of this Standard.

• Function 131 – The r2_REPORT_indication marked as alerting from the subsequent CC functional

entity is processed. The information channel should then be connected and cut-through in the backward direction, if not already done.

NOTE 58 The information flows between the CC functional entity and a non-ISDN are beyond the scope of this Standard.

• Function 132 – The r2_SETUP_confirmation is processed and the information channel is cut-through in the forward direction, if not cut-through already.

NOTE 59 The information flows between the CC functional entity and a non-ISDN are beyond the scope of this Standard.

• Function 140 a) The r2*_SETUP_indication is processed. b) The incoming information channel is reserved and a r2*_CHANNEL_ACKNOWLEDGE_request is sent. c) An outgoing information channel is reserved, based on the Destination Number (DN) and Connection Type (CT) information in the r2*_SETUP_indication. The selection may also be dependant upon other information beyond the scope of this Standard. d) The r2_SETUP_request is generated and sent. If present, the Originating Number, Originating Subaddress, the Destination Subaddress, Call History information or the Connection Type parameters, Low Layer Compatibility and High Layer Compatibility contained in the incoming r2*_SETUP_indication are carried in the r2_SETUP_request. NOTE 60 The Originating Number can be obtained using the public ISDN supplementary service Calling Line Identification Presentation (CLIP), see ITU-T Rec. I.251.3. NOTE 61 The information flows between the CC functional entity and a public ISDN are beyond the scope of this Standard.

• Function 141 – The r2_CHANNEL_ACKNOWLEDGE_indication is processed and the allocated channel is connected and cut-through in the backward direction. The information channel may also be cut-through in the forward direction.

• Function 142 – The r2_REPORT_indication is processed. As the incoming REPORT contains Report Type “alerting”, a r2*_REPORT_indication marked as an “Alerting” primitive is sent to the public

- 38 -

ISDN. The allocated channel should then be connected and cut-through in the backward direction, if not already done. NOTE 62 The information flows between the CC functional entity and a public ISDN are beyond the scope of this Standard.

• Function 143 – The r2_SETUP_confirmation is processed and the information channel is cut-through in the forward direction, if not cut-through already. A r2*_SETUP_response is generated and then sent to the public ISDN functional entity. NOTE 63 The information flows between the CC functional entity and a public ISDN are beyond the scope of this Standard. 14.1.7

O u t g o in g g a t e wa y C C f u n c t io n a l e n t it y The information flows at r2* are provided for information purposes only as they are outside the scope of this Standard.

• Function 330 a) The r2_SETUP_indication is processed. b) The incoming information channel is reserved and a r2_CHANNEL_ACKNOWLEDGE_request is sent to the preceding CC functional entity. c) An outgoing information channel is reserved, based on the Destination Number (DN) and Connection Type (CT) information in the r2_SETUP_indication. NOTE 64 The selection can also be dependant upon other information beyond the scope of this Standard. NOTE 65 The information flows supported over the relationship with a non-ISDN are beyond the scope of this Standard.

• Function 331 – In this example when interworking with a non-ISDN Network a r2_REPORT is

normally sent to the preceding CC functional entity with appropriate parameter in the CH service element indicating interworking. The event that causes the CC functional entity to send this information flow is beyond the scope of this Standard.

• Function 332 – For the call to be completed successfully the Gateway CC functional entity shall send a r2_SETUP_response to the preceding CC functional entity. The event that causes the CC functional entity to send this information flow is beyond the scope of this Standard.

• Function 335 – The r2_INFORMATION_indication is processed. NOTE 66 The information flows supported over the relationship with a non-ISDN are beyond the scope of this Standard.

• Function 340 a) The r2_SETUP_indication is processed. b) The incoming information channel is reserved and a r2_CHANNEL_ACKNOWLEDGE_request is sent. c) An outgoing information channel is reserved based on the Destination Number (DN) and Connection Type (CT) information in the r2_SETUP_indication. The selection can also be dependant upon other information beyond the scope of this Standard. d) The r2*_SETUP_request is generated and sent.

- 39 -

NOTE 67 The information flows between the CC functional entity and a public ISDN are beyond the scope of this Standard.

• Function 341 – The r2*_CHANNEL_ACKNOWLEDGE_indication is processed and the allocated channel is connected and cut-through in the backward direction; the information channel may also be cut-through in the forward direction.

• Function 342 – The r2*_REPORT_indication is processed. As the incoming REPORT contains Report Type “Alerting”, a r2_REPORT_indication marked as “alerting” is sent to the preceding CC functional entity. The allocated channel should then be connected and cut-through in the backward direction, if not already done.

NOTE 68 The information flows between the CC functional entity and a public ISDN are beyond the scope of this Standard.

• Function 343 – The r2*_SETUP_confirmation is processed and the information channel is cutthrough in the forward direction, if not cut-through already. A r2_SETUP_response is generated and then sent to the preceding CC functional entity. In this example, the Connected Number, Connected Subaddress or the Connection Type parameter, contained in r2*_SETUP_confirmation are carried in the r2_SETUP_response.

NOTE 69 The Connected Number can be obtained using the public ISDN service Connected Line Identification Presentation (COLP) supplementary service. (See ITU-T Rec. 251.5). NOTE 70 The information flows between the CC functional entity and a public ISDN are beyond the scope of this Standard.

- 40 -

14.2

Normal call establishment The information flow sequence for a successful call setup with en-bloc sending and with delayed answer by the destination CCA is shown in figure 6.

Originating CCA SETUP rq

000

001

r1-SETUP rq i [DN,CT,DS, OS,ON,CI]

Originating CC

100

r2-SETUP rq i [DN,CT,DS, OS, ON,CI]

r1-CHAN ACK i rq [CI] 101

Transit CC

r2-CHAN ACK i rq [CI]

Destination CC

Destination CCA

r2-SETUP 200

r3-SETUP

[DN,CT,DS, 300 OS, ON,CI]

201

r2-CHAN ACK rq i [CI]

301

SETUP 400

[DN,CT,DS,CI]

r3-CHAN ACK i rq [CI]

REPORT i

002

r1-REPORT i rq

102

[RT]

SETUP c

003

r1-SETUP c rs [CT]

103

r2-REPORT i rq

202

r2-REPORT i rq

302

203

REPORT 401

r2-SETUP c rs [CN,CT,CS]

303

[RT]

[RT] r2-SETUP c rs [CN,CT,CS]

r3-REPORT rq i

r3-SETUP c rs [CN,CT,CS]

SETUP 402

r3-CHAN CONNECT 403

NOTE 1 The Report Type (RT) in this sequence is “User being alerted”. NOTE 2 This information flow sequence does not show interworking with non-ISDN terminals which are attached to the PISN.

Figure 6 – Normal call establishment with en-bloc signalling

- 41 -

14.3

Normal call establishment with digit-by-digit sending and automatic answer The information flow sequence for a successful call setup with digit-by-digit sending and when a call attempt encounters a Destination CCA that immediately enters the call established state is shown in figure 7.

Originating CCA SETUP rq

Originating CC

Transit CC

Destination CC

Destination CCA

r1-SETUP rq i 000 [DN,CT,DS,OS,ON,CI] r1-CHAN ACK 112 001

i rq [CI]

r1_INFORMATION INFORMATION rq rq 015 i 113 [DN] r2-SETUP INFORMATION r1_INFORMATION rq i 116 rq i rq r2-SETUP 015 [DN,CT,DS,OS,ON,CI] rq i [DN] 200 r2-CHAN ACK [DN,CT,DS,OS,ON,CI] i rq 101 r2-CHAN ACK 314 [CI] 201 INFORMATION r1_INFORMATION i rq r2_INFORMATION [CI] rq i rq 015 115 rq i [DN] [DN] 216 r2_INFORMATION NOTE 3 PROCEEDING PROCEEDING REPORT 117 i rq 016 rq i i rq r3-SETUP i rq 315 [DN] i NOTE 2 [DN,CT,DS,CI] 400 301

r3-CHAN ACK i rq

SETUP i

[CI] SETUP r2-SETUP

SETUP c

r1-SETUP 003

103

r2-SETUP c rs [CN,CT,CS]

203

rs 303

[CN,CT,CS]

[CT]

r3-SETUP c

402

[CN,CT,CS] r3-CHAN CONNECT 403

NOTE 1 This information flow sequence does not show interworking with non-ISDN terminals which are attached to the PISN. NOTE 2 The Report Type (RT) is "call proceeding". NOTE 3 The INFORMATION flow contains the indicator "number complete".

F i g u r e 7 – N o r m a l c a l l e s t a b l i s h m e n t w i t h d ig it - b y - d ig it s e n d in g a n d a u t o m a t ic a n s we r

- 42 -

14.4

Unsuccessful calls with the provision of tones and announcements The information flow sequence when a call attempt is unsuccessful and fails with the provision of in-band tones and announcements is shown in figure 8.

Originating CCA SETUP rq

000

001

r1-SETUP rq i [DN,CT,DS, OS,ON,CI]

Originating CC

100

r1-CHAN ACK i rq [CI]

Transit CC

r2-SETUP rq i [DN,CT,DS, OS, ON,CI]

101

r2-CHAN ACK i rq [CI]

200

r2-SETUP rq i [DN,CT,DS, OS, ON,CI]

201

Destination CC

r2-CHAN ACK i rq [CI]

300

r3-SETUP rq i

Destination CCA

SETUP 400

420

RELEASE rq

[DN,CT, DS, CI]

301

r3-CHAN ACK rq i [CI] r3-SETUP REJECT

REPORT i Note 3

r1-REPORT 006

i rq [RT,CC,CH]

106

r2-REPORT i rq [RT,CC,CH]

206

r2-REPORT i rq [RT,CC,CH]

321

i rq [CC]

RELEASE c

In-Band Tone or Announcement

NOTE 1 It is possible to clear the call from either end. NOTE 2 In this information flow sequence the source of the inband tone or announcement is collocated with a Destination CC functional entity. The particular location of the source of the inband tone or announcement depends on the network configuration, and is beyond the scope of this Standard. NOTE 3 The RT (Report Type) in this sequence is “Call Rejected”. NOTE 4 This information flow sequence does not show interworking with non-ISDN terminals which are attached to the PISN.

Figure 8 – Unsuccessful calls with the provision of tones and announcements

- 43 -

14.5

Unsuccessful calls without the provision of tones and announcements The information flow sequence when a call attempt is unsuccessful and fails without the provision of in-band tones and announcements is shown in figure 9.

Originating CCA SETUP rq

000

Originating CC

r1-SETUP rq i [DN,CT,DS, OS,ON,CI]

r1-CHAN ACK 001 i rq [CI]

100

Transit CC

r2-SETUP rq i [DN,CT,DS, OS, ON,CI]

101

r2-CHAN ACK i rq [CI]

200

Destination CC

r2-SETUP rq i [DN,CT,DS, OS, ON,CI]

201

r2-CHAN ACK i rq [CI]

300

Destination CCA

r3-SETUP i rq [DN,CT,DS CI]

SETUP 400

r3-CHAN ACK 301

[CI]

RELEASE i

r1-DISCONNECT 110 010

011

012

r1-RELEASE rq i

210

[CC]

[CC] RELEASE rs

r2-RELEASE i rq

r2-RELEASE rs c

r2-RELEASE i rq

320

[CC]

[CC] r2-RELEASE rs c

r3-SETUP REJECT 420 i rq

RELEASE rq RELEASE c

312

211

111

r1-RELEASE c rs

NOTE This information flow sequence does not show interworking with non-ISDN terminals which are attached to the PISN.

F i g u r e 9 – U n s u c c e s s f u l c a l l s w i t h o u t t he p r o v i s i o n o f t o n e s a n d a n n o u n c e m e n t s

- 44 -

14.6

Incoming interworking with a non-ISDN The information flow sequence when a call attempt from a non-ISDN interworks with the PISN is shown in figure 10.

Non ISDN

Incoming Gateway CC

Network

Transit CC

200

rq i [DN,CT, CI,CH]

Destination CC

Destination CCA

r2-SETUP 130

r2-SETUP

[DN,CT, CI,CH] 101 The information flows supported when interworking with Non-ISDN Networks are beyond the scope of this standard

r2-CHAN ACK i rq [CI]

300

i rq [CI]

400

SETUP i

401

REPORT rq

402

SETUP rs

[DN,CT, CH,CI] r3-CHAN ACK

r2-CHAN ACK 201

r3-SETUP rq i

301

i rq [CI] r3-REPORT

r2-REPORT 131

202

r2-REPORT i rq

302

[RT] r3-SETUP c rs

[RT]

132

r2-SETUP c rs

i rq [RT]

203

r2-SETUP c rs [CT,CN,CS]

303

[CN,CT,CS] r3-CHAN CONNECT 403

[CT,CN,CS]

NOTE 1 CH (Call History) in the SETUP_request/indication information flows contains the service parameter: "Signalling interworking: non-common channel signalling system". NOTE 2 The RT (Report Type) in this sequence is "User being alerted".

F ig u r e 1 0 – I n c o m in g in t e r wo r k in g wit h a n o n - I S D N

- 45 -

14.7

Outgoing interworking with a non-ISDN The information flow sequence when a call attempt from the PISN interworks with a non-ISDN is shown in figure 11.

Originating CCA

SETUP rq

000

001

Originating CC

r1-SETUP rq i [DN,CT,DS, OS,ON,CI]

100

r1-CHAN ACK i rq [CI]

007

r1-REPORT i rq [RT,CH]

107

Transit CC

r2-SETUP rq i [DN,CT,DS, OS, ON,CI]

101

REPORT

r2-CHAN ACK i rq [CI]

r2-REPORT i rq

200

201

207

Outgoing Gateway CC

r2-SETUP rq i [DN,CT,DS, OS, ON,CI]

330

r2-CHAN ACK i rq [CI]

r2-REPORT rq i

Non-ISDN Network

The information flows supported when interworking with Non-ISDN Networks are beyond the scope of this standard 331

[RT,CH]

[RT,CH] In-Band Tones /Announcements

SETUP c

003

r1-SETUP c rs

103

r2-SETUP c rs

203

r2-SETUP c rs

332

NOTE 1 CH (Call History) in the REPORT_request/indication information flows contains the service parameter: "Signalling interworking: non-common channel signalling system". NOTE 2 This sequence shows the scenario where the non-ISDN is unable to provide an indication of alerting or inband tones being applied. NOTE 3 The RT (Report Type) shown in this sequence is 'interworking encountered'. NOTE 4 This information flow sequence does not show interworking with non-ISDN terminals which are attached to the PISN.

F ig u r e 1 1 – O u t g o in g in t e r wo r k in g wit h a n o n - I S D N

- 46 -

14.8

Outgoing interworking with digit-by-digit sending The information flow sequence when a call attempt using overlap sending from the PISN interworks with a non-ISDN is shown in figure 12.

Originating CCA

SETUP rq

Originating CC

Transit CC

Outgoing Gateway CC

Non-ISDN Network

r1-SETUP

rq i [DN,CT,DS, OS,ON,CI]

000

112

r1-CHAN ACK 001

INFORMATION rq 015

i rq [CI] r1_INFORMATION

i [DN]

r2-SETUP 116

[DN,CT,DS, OS, ON,CI]

200

r2-CHAN ACK

101 i rq INFORMATION r1_INFORMATION [CI] rq 015 201 rq i 115 [DN] r2_INFORMATION

i [DN] 216

REPORT i rq NOTE 4 REPORT i NOTE 1

016

117

PROCEEDING i rq r2-REPORT

r1-REPORT i

002

102

330

r2-CHAN ACK i rq [CI]

r2_INFORMATION NOTE 5 rq i 335 [DN]

202

331

[RT,CH]

r1-SETUP 003

[DN,CT,DS, OS, ON,CI]

r2-REPORT

r2-SETUP

[RT,CH]

SETUP c

PROCEEDING i rq

r2-SETUP rq i

The Information flows supported when interworking with Non-ISDN Networks are beyond the scope of this standard.

103

r2-SETUP c rs

203

332

NOTE 1 The RT (Report Type) shown in this sequence is 'interworking encountered'. NOTE 2 This information flow sequence does not show interworking with non-ISDN terminals which are attached to the PISN. NOTE 3 The digits may be provided by the user with several INFORMATION flows. NOTE 4 The Report Type is "call proceeding". NOTE 5 The INFORMATION flow contains the indicator "number complete".

F ig u r e 1 2 – O u t g o in g in t e r wo r k in g u s in g d ig it - b y - d i g i t s e n d i n g a n d w i t h t h e l e n g t h unknown by the Originating CC, and with interworking to a non-ISDN

- 47 -

14.9

Basic call clearing The information flow sequence when a call is cleared is shown in figure 13.

Originating

CCA

Transit CC

Destination

CCA

r3-DISCONNECT i rq 410

RELEASE i

r1-DISCONNECT 110 010

012

r2-RELEASE rs

r1-RELEASE rq

r3-RELEASE r3-RELEASE rq i

[CC]

411

RELEASE c

r3-RELEASE

211 311

r1-RELEASE c rs

310

[CC]

r2-RELEASE 312 rs c

[CC]

[CC] RELEASE rs 011

r2-RELEASE 210 rq i

r2-RELEASE i rq

RELEASE

111

NOTE Three Stage Clearing is used on the r1/r3 that originates clearing as this allows for supplementary service information to be passed from the network to the extension ( e.g. call charging ). Three Stage Clearing is used on the r1/r3 that has not initiated clearing as this allows for symmetry to be maintained.

Figure 13 – Basic call clearing

- 48 -

14.10 Incoming interworking with a public ISDN The information flow sequence when a call attempt from a public ISDN interworks with the PISN is shown in figure 14. The information flows of the r2* relationship are shown for information purposes only as they are beyond the scope of this Standard.

Public ISDN

r2*

Incoming Gateway CC

Transit

Destination

CCA

r2*-SETUP

SETUP rq

rq i [DN,CT,OS,DS, CH,ON,CI]

r2-SETUP 140

r2*-CHAN ACK i rq [CI] 141

i rq r2-SETUP [DN,CT,DS,OS, 200 rq i CH,ON,CI] [DN,CT,DS,OS, 300 CH,ON,CI] r2-CHAN ACK i rq [CI]

r2-REPORT REPORT i

SETUP c

r2*-REPORT i rq [RT] r2*-SETUP c rs

142

201

202

r2-CHAN ACK i rq [CI]

r2-REPORT i rq

301

r3-CHAN ACK i rq [CI]

302

r3-REPORT i rq [RT]

[RT] r2-SETUP

143

r2-SETUP c rs

SETUP 400

[CN,CT,CS]

c 303

REPORT 401

402

SETUP rs

r3-SETUP

[RT] 203

r3-SETUP rq i [DN,CT,DS, CI,CH]

[CN,CT,CS]

r3-CHAN CONNECT 403

[CN,CT,CS]

NOTE 1 The CH (Call History) service element, if present, contains the "Interworking with a public network" service parameter, and/or "Signalling interworking: non-common channel signalling system" service parameter. NOTE 2 The r2* flows are informative.

F ig u r e 1 4 – I n c o m in g in t e r wo r k in g wit h a p u b lic I S D N

- 49 -

14.11 Outgoing interworking with a public ISDN The information flow sequence when a call attempt from the PISN interworks with a public ISDN is shown in figure 15. The information flows of the r2* relationship are shown for information purposes only as they are beyond the scope of this Standard.

Originating

CCA

SETUP rq

000

r1-SETUP i rq [DN,CT,DS, OS,ON,CI]

001

Originating CC

Transit CC

Outgoing Gateway CC

Public ISDN

r2*

r2-SETUP 100

[DN,CT,DS, OS, ON,CI]

r1-CHAN ACK i rq [CI] 101

r2-CHAN ACK i rq [CI]

200

201

r2-SETUP rq i [DN,CT,DS, OS, ON,CI] r2-CHAN ACK i rq [CI]

340

r2*-SETUP rq i [DN,CT,DS, OS,ON,CI]

341

r2*-CHAN ACK i rq [CI] r2*-REPORT

REPORT i

r1-REPORT 002

102

r2-REPORT i rq

202

003

r1-SETUP c rs

342

103

r2-SETUP c rs

203

r2-SETUP c rs

REPORT rq

[RT] r2*-SETUP c rs

[RT,CH]

[RT,CH] SETUP

r2-REPORT i rq [RT,CH]

SETUP i

343

SETUP rs

[CN,CT,CS]

[CT]

F ig u r e 1 5 – O u t g o in g in t e r wo r k in g wit h a p u b lic I S D N

- 50 -

SDL diagrams for functional entities The FE functions which are shown in SDL form in this clause are intended to illustrate typical FE behaviour in terms of information flows sent and received. The SDL diagrams are in five groups: •

Originating CCA functional entity SDL diagrams

•

Originating CC functional entity SDL diagrams

•

Transit CC functional entity SDL diagrams

•

Terminating CC functional entity SDL diagrams

•

Terminating CCA functional entity SDL diagrams

Only timers that can be considered as call control (i.e. not protocol timers) are shown. NOTE 71 In this clause the primitive and information flows are shortened: “request” to “req”; “indication” to “ind”; “response” to “resp”; and “confirmation” to “cfm”. NOTE 72 Also in this clause the terms “backward” and “forward” are used. At a particular functional entity the direction towards the Originating PISN user is called the “Backward” direction. The direction towards the Destination PISN user is called the “Forward” direction.

15.1

Originating CCA functional entity SDL diagrams Output signals to the left and input signals from the left represent primitives to and from the Originating PISN user. Output signals to the right and input signals from the right represent information flows across r1 to and from the Originating CC functional entity. The only exception to this rule is when the text within the signals explicitly identifies from what function the signal originates.

15.1.1

Originating CCA states used in SDL diagrams • Orig_CCA_Idle - No Call in progress • Orig_CCA_Forward_Release_Forward_r1_Disconnect - Originating PISN user has initiated clearing and the CCA is awaiting response from the originating CC to the request for clearing. • Orig_CCA_Backward_Release - Clearing of the CCA channel has been indicated to the PISN user, clearing across r1 complete, awaiting response from the PISN user. • Orig_CCA_Wait_for_Release_Channel - In-band tones/announcements being given to the PISN user, awaiting r1_release_cfm and PISN user or CCA originated clearing. • Orig_CCA_Call_Sent - Call has been initiated by the CCA, the channel has been reserved to the Originating CC, and an end to end response is awaited. • Orig_CCA_Call_Initiated - Call has been initiated by the CCA functional entity, and the CCA is awaiting a response from the Originating CC. • Orig_CCA_Call_Active - Call is in active phase. • Orig_CCA_Backward_Release_Backward_r1_Disconnect - Originating CC has initiated clearing and the CCA is awaiting response from the Originating PISN user to the request for clearing. • Orig_CCA_Forward_r1_Release - Clearing of the CCA to CC channel has been initiated, PISN user clearing complete, awaiting response from the Originating CC.

- 51 -

15.1.2

Originating CCA SDL diagrams

Orig_CCA_ Idle

SETUP_ req

r1_SETUP_ req

Orig_CCA_ Call_Initiated

Figure 16 – Stage 2 SDL diagram for Originating CCA functional entity (Sheet 1 of 9)

Orig_CCA_ Call_Initiated

INFORMATION_ req

r1_CHANNEL_ ACK_ind

r1_SETUP_ REJECT_ind

RELEASE_req

r1_INFORMATION_ req

Orig_CCA_ Call_Initiated

REPORT_ind (channel ack.)

r1_DISCONNECT_ req

Cut-through optional

Disconnect

Orig_CCA_ Call_Sent

Orig_CCA_ Forward_Release_ Forward_r1_Disconnect

RELEASE_ind

Tones Required

REPORT_ind (call rejection)

Orig_CCA_ Backward_Release

Orig_CCA_Wait_for Release_Channel

Figure 17 – Stage 2 SDL diagram for Originating CCA functional entity (Sheet 2 of 9)

- 52 -

Orig_CCA_ Call_Sent A

INFORMATION_

r1_REPORT_ind

req

(Interworking)

r1_INFORMATION_ req

Orig_CCA_ Call_Sent_

r1_PROCEEDING_ind (number complete)

(user being alerted)

REPORT_ind (call proceeding)

REPORT_ind (user being alerted)

Orig_CCA_ Call_Sent

REPORT_ind (Interworking)

Orig_CCA_ Call_Sent

r1_SETUP_cfm

r1_REPORT_ind

SETUP_cfm

Orig_CCA_ Active

Figure 18 – Stage 2 SDL diagram for Originating CCA functional entity (Sheet 3 of 9)

r1_REPORT_ind (call rejection)

RELEASE_req

r1_DISCONNECT_ind

REPORT_ind (call rejection)

Orig_CCA_ Call_Sent

Tones Required

r1_DISCONNECT_ req

RELEASE_ind

REPORT_ind (call rejection)

Disconnect

r1_RELEASE_req

Orig_CCA_ Forward_Release_

Orig_CCA_ Backward_Release_ Backward_r1_Disconnect

Orig_CCA_Wait_for Release_Channel

Forward_r1_Disconnect

Figure 19 – Stage 2 SDL diagram for Originating CCA functional entity (Sheet 4 of 9)

- 53 -

Orig_CCA_ Active

r1_DISCONNECT_ ind

RELEASE_ req

r1_DISCONNECT_ req

Tones Required?

RELEASE_ ind

REPORT_ind (call rejection)

Disconnect

r1_RELEASE_ req

Orig_CCA_ Forward_Release_ Forward_r1_DIsconnect

Orig_CCA_ Backward_Release_ Backward_r1_Disconnect

Orig_CCA_Wait_for Release_Channel

Figure 20 – Stage 2 SDL diagram for Originating CCA functional entity (Sheet 5 of 9)

Orig_CCA_ Forward_Release_ Forward_r1_Disconnect

r1_RELEASE_ ind

RELEASE_cfm

r1_RELEASE_ resp

Orig_CCA_ Idle

Figure 21 – Stage 2 SDL diagram for Originating CCA functional entity (Sheet 6 of 9)

- 54 -

Orig_CCA_ Backward_Release_ Backward_r1_Disconnect

RELEASE_resp

r1_RELEASE_ req Orig_CCA_ Forward_r1_Release

r1_RELEASE_ cfm

Orig_CCA_ Idle

Figure 22 – Stage 2 SDL diagram for Originating CCA functional entity (Sheet 7 of 9)

Orig_CCA_Wait_for_ Release_Channel

r1_RELEASE_cfm

Orig_CCA_wait_ for_ release channel

RELEASE_ req

Orig CCA Requirement to Release Resources

RELEASE_cfm

RELEASE_ ind

Orig_CCA_Idle

Orig_CCA_ Backwards_ Release

Figure 23 – Stage 2 SDL diagram for Originating CCA functional entity (Sheet 8 of 9)

- 55 -

Orig_CCA_ Backward_Release

RELEASE_resp

Orig_CCA_ Idle

Figure 24 – Stage 2 SDL diagram for Originating CCA functional entity (Sheet 9 of 9)

15.2

Originating CC functional entity SDL diagrams Output signals to the left and input signals from the left represent information flows across r1 to and from the Originating CCA functional entity. Output signals to the right and input signals from the right represent information flows across r2 to and from the Subsequent CC functional entity. The only exception to this rule is when the text within the signals explicitly identifies from what function the signal originates.

15.2.1

O r ig in a t in g C C s t a t e s u s e d in S D L d ia g r a m s • Orig_CC_Idle - No Call in progress • Orig_CC_Call_Sent - Call has been initiated by the CC, the channel has been reserved to the subsequent CC, and an end to end response is awaited. • Orig_CC_Wait_for_Release_Channel - In-band tones/announcements being given to the PISN user, PISN user or CC originated clearing awaited. • Orig_CC_Call_Initiated - Call has been initiated by the CC functional entity, and the CC is awaiting a response from the subsequent CC. • Orig_CC_Wait_for_Address_Info - The CC is awaiting additional information from the Originating CCA. • Orig_CC_Call_Active - Call is in active phase. • Orig_CC_Backward_r1_Release - Resources have been disconnected, and clearing of the resources in the backward direction has been initiated, CC awaiting response from the Originating CCA. • Orig_CC_Backward_r1_Release_Forward_r2_Release - Resources have been disconnected, and clearing has been initiated in both directions, awaiting responses from both the Originating CCA and the subsequent CC. • Orig_CC_Forward_r2_Release - Resources have been disconnected, and clearing of the resources in the forward direction has been initiated, CC awaiting response from the subsequent CC. • Orig_CC_Backward_r1_Disconnect - Disconnection of resources has been initiated, awaiting response from the Originating CCA. • Orig_CC_Backward_r1_Disconnect_forward_r2_Release - Resources have been disconnected and clearing of resources in the forward direction has been initiated. The CC is awaiting response from the originating CCA.

- 56 -

15.2.2

O r ig in a t in g C C S D L d ia g r a m s

Orig_CC_ Idle r1_SETUP_ ind Originating Node Screening Originating Node Routeing

Call Processing Successful?

Y r1_CHANNEL_ ACK_req

r2_SETUP_ req

Orig_CC_ Call_Initiated

Sufficient Digits to Route on? N r1_SETUP_ REJECT_req

Orig_CC_Wait_ for_Address_Info

Orig_CC_ Idle

Figure 25 – Stage 2 SDL diagram for Originating CC functional entity (Sheet 1 of 12)

- 57 -

Orig_CC_Wait_for_ Address_Info

r1_INFORMA-

r1_DISCONNECT_ ind

TION_ind

Orig_CC_Wait_ for_Address_Info

Sufficient Digits to Route on? Y r2_SETUP_ req

r1_RELEASE_ req

Orig_CC_ Call_Initiated

Orig_CC_ Backward_ r1_Release

Figure 26 – Stage 2 SDL diagram for Originating CC functional entity (Sheet 2 of 12)

Orig_CC_ Call_Initiated

Note 3

Note 1 r1_INFORMA-

r1_DISCONNECT_

r2_SETUP_

TION_ind

ind

REJECT_ind

r2_INFORMATION_req

r2_RELEASE _req

Tones Required

r2_CHANNEL_ ACK_ind

Start "Route Complete" Timer Note 2

Disconnect

Orig_CC_ Call_Initiated

r1_RELEASE_ req

r1_DISCONNECT_ req

r1_REPORT_req (call rejection)

Cut-though Backwards

Orig _CC_Backward_ r1_Release_Forward_ r2_Release

Orig_CC_ Backward_ r1_Disconnect

Orig_CC_Wait_for_ Release_Channel

Orig_CC_ Call_Sent

NOTE 1 - This information flow is not acted upon after the receipt of a SETUP or INFORMATION information flow with an 'number complete indicator' parameter. There is an interdigit timer that is active, on the expiry of this timer no more INFORMATION information flows are accepted. NOTE 2 - This is the earliest that the CC functional entity can cut through in the forward direction. NOTE 3 - This Standard does not exclude possible implementation specific procedures which do not result in the call being released, eg., alternate routeing.

Figure 27 – Stage 2 SDL diagram for Originating CC functional entity (Sheet 3 of 12)

- 58 -

Orig_CC_Call_Sent

Note 2 r2_REPORT_ind (user being alerted) r1_REPORT_req (user being alerted)

Optionally Start "Orig CC NoAnswer" Timer

r2_SETUP_ cfm

r1_SETUP_ resp

r2_PROCEEDING (number complete) r1_PROCEEDING (call proceeding)

"Orig CC No Answer" Timer Expiry

"Route Complete" Timer Expiry

r2_RELEASE_ req

Disconnect

Stop "Orig CC Answer" Note 1 Timer

Cut-Through Forwards

Tones Required?

N Stop "Route Complete" Timer

Stop "Route Complete" Timer

Orig_CC_ Call_Sent

Orig_CC_ Active

Orig_CC_ Call_Sent

r1_REPORT_req (Call rejection)

r1_DISCONNECT_ req

Orig_CC_Wait_for_ Release_Channel

Orig_CC_Backward_ r1_Disconnect Forward_r2_Release

NOTE 1 - This is the earliest that the CC functional entity can cut through in the backward direction. NOTE 2 - This Standard does not exclude possible implementation specific procedures which do not result in the call being released, eg., alternate routeing.

Figure 28 – Stage 2 SDL diagram for Originating CC functional entity (Sheet 4 of 12)

- 59 -

r1_DISCONNECT_ ind

r2_RELEASE_ ind

r2_REPORT_ind

(call rejection)

( Interworking)

Stop "Route Complete" Timer

Stop"Route Complete" timer

Stop "No Answer" timer

r1_REPORT_req (call rejection)

r1_REPORT_req (interworking)

r1_INFORMANote TION_ind

r2_RELEASE_ req

r2_INFORMATION_ req

r1_DISCONNECT_req

Tones Y Required? r1_REPORT_req (call rejection)

Disconnect

r1_RELEASE_ req

r2_RELEASE_ resp

Orig_CC_ Backward_ r1_Disconnect

Orig_CC_Wait _for_Release_ Channel

Orig_CC_Backward_ r1_Release_ Forward_r2_Release

Orig_CC_ Call_Sent

NOTE - This information flow is not acted upon after the receipt of an INFORMATION information flow with an 'number complete indicator' parameter. There is an interdigit timer that is active, on the expiry of this timer no more INFORMATION information flows are accepted.

Figure 29 – Stage 2 SDL diagram for Originating CC functional entity (Sheet 5 of 12)

- 60 -

Orig_CC_Wait_for_ Release_Channel

r1_DISCONNECT_ ind

Orig CC Requirement

r1_RELEASE_ req

r1_DISCONNECT_ req

to Release Channel

Disconnect

Orig_CC_ Backward_ r1_Release

Orig_CC_ Backward_ r1_Disconnect

Figure 30 – Stage 2 SDL diagram for Originating CC functional entity (Sheet 6 of 12)

Orig_CC_ Active

r1_DISCONNECT_ ind

r2_RELEASE_

r2_RELEASE_ req

r1_DISCONNECT_ req

Disconnect

Disconnect Release Resources Forwards

r1-RELEASE req

r2-RELEASE resp

Orig_CC_Backward_ r1_Release_Forward_ r2_Release

ind

Orig_CC_ Backward_ r1_Disconnect

Figure 31 – Stage 2 SDL diagram for Originating CC functional entity (Sheet 7 of 12)

- 61 -

Orig_CC_Backward_ r1_Release_Forward_ r2_Release

r1_RELEASE_ cfm

r2_RELEASE_ cfm

Release Resources Backwards

Release Resources Forwards

Orig_CC_ Forward_ r2_Release

Orig_CC_ Backward_ r1_Release

Figure 32 – Stage 2 SDL diagram for Originating CC functional entity (Sheet 8 of 12)

Orig_CC_ Backward_ r1_Release r1_RELEASE_ cfm

Release Resources Backwards Orig_CC_ Idle

Figure 33 – Stage 2 SDL diagram for Originating CC functional entity (Sheet 9 of 12)

- 62 -

Orig_CC_ Forward_ r2_Release r2_RELEASE_ cfm Release Resources Forwards

Orig_CC_ Idle

Figure 34 – Stage 2 SDL diagram for Originating CC functional entity (Sheet 10 of 12)

Orig_CC_Backward_ r1_Disconnect r1_RELEASE_ ind

r1_RELEASE_ resp

Disconnect

Release Resources Backward Orig_CC_ Idle

Figure 35 – Stage 2 SDL diagram for Originating CC functional entity (Sheet 11 of 12)

- 63 -

Orig_CC_Backward_ r1_disconnect Forward_r2_Release

r1_RELEASE_ ind

r2_RELEASE_ cfm

Release Resources Backwards

Release Resources Forwards

r1_RELEASE_ resp

Orig_CC_Forward_ r2_Release

Orig_CC_Backward r1_Disconnect

Figure 36 – Stage 2 SDL diagram for Originating CC functional entity (Sheet 12 of 12)

15.3

Transit CC functional entity SDL diagrams Output signals to the left and input signals from the left represent information flows across r2 to and from the preceding CC functional entity. Output signals to the right and input signals from the right represent information flows across r2 to and from the Subsequent CC functional entity. The only exception to this rule is when the text within the signals explicitly identifies from what function the signal originates.

15.3.1

Tr a n s it C C s t a t e s u s e d in S D L d ia g r a m s • Transit_CC_Idle - No Call in progress • Transit_CC_Call_Sent - Call has been initiated by the CC, the channel has been reserved to the subsequent CC, and an end to end response is awaited. • Transit_CC_Wait_for_Release_Channel - In-band tones/announcements being given to the PISN user, PISN user or CC originated clearing awaited. • Transit_CC_Call_Initiated - Call has been initiated by the CC functional entity, and the CC is awaiting a response from the subsequent CC. • Transit_CC_Wait_for_Address_Info - The CC is awaiting additional information from the preceding CC. • Transit_CC_Call_Active - Call is in active phase. • Transit_CC_Backward_r2_Release - Resources have been disconnected, and clearing of the resources in the backward direction has been initiated, CC awaiting response from the preceding CC. • Transit_CC_Forward_r2_Release - Resources have been disconnected, and clearing of the resources in the forward direction has been initiated, CC awaiting response from the subsequent CC.

- 64 -

15.3.2

Tr a n s it C C S D L d ia g r a m s

Transit_ CC_Idle r2_SETUP_ ind Transit Node Screening

Transit Node Routeing

Call Processing Successfull?

Y r2_CHANNEL_ ACK_req

r2_SETUP_ req Transit_CC_ Call_Initiated

Sufficient Digits to Route on? N

Transit_CC_ Wait _for_ Address_Info

r2_SETUP_ REJECT_req Transit_ CC_Idle

Figure 37 – Stage 2 SDL diagram for Transit CC functional entity (Sheet 1 of 8)

- 65 -

Transit_CC_ Wait _for_ Address_Info

r2_INFORMATION_ind

r2_RELEASE_ ind

Sufficient Digits to Route on? Y

Transit_CC_ Wait_for_ Address_Info

r2_SETUP_ req

r2_RELEASE_

Transit_CC_

Transit_ CC_Idle

Call_Initiated

resp

Figure 38 – Stage 2 SDL diagram for Transit CC functional entity (Sheet 2 of 8)

- 66 -

Transit_CC_ Call_Initiated

r2_RELEASE_ind

r2_CHANNEL_

r2_SETUP_ REJECT_ ind

ACK_id

Note 2

r2_INFORMATION _ind Note 1

r2_RELEASE_req

Disconnect Release Resources Backwards

Tones Required

Through Connect both directions

N r2_RELEASE_resp

r1_RELEASE_req

Transit_CC_ Forward_r2_ Release

Transit_CC_ Backward_ r2_Release

r2_REPORT_req

r2_INFORMATION_ ind

(Inband Tones) Transit_CC_ Wait_for_ Release_Channel

Transit_CC_ Call_Sent

Transit_CC_ Call_Initiated

NOTE 1 - This information flow is not acted upon after the receipt of a SETUP or INFORMATION information flow with an 'number complete indicator' parameter. There is an inter-digit timer that is active, on the expiry of this timer no more INFORMATION information flow are accepted. NOTE 2 - This Standard does not exclude possible implementation specific procedures which do not result in the call being released, e.g., alternate routeing. NOTE 3 - This is the earliest that the CC function entity can cut through.

Figure 39 – Stage 2 SDL diagram for Transit CC functional entity (Sheet 3 of 8)

- 67 -

Transit_CC_ Call_Sent

r2_SETUP_

r2_INFORMA-

r2_REPORT_

ind

cfm

TION_ind

ind

Note 3

Note 2

Note 1 r2_RELEASE_

r2_RELEASE_ ind

Number Complete?

Tones Required?

N r2_RELEASE_ req

r2_RELEASE_ req

Disconnect

Release Resources Backwards

Release Resources Forwards

r2_RELEASE_ resp

Transit_CC_ Forward_ r2_Release

r2_SETUP_ resp

Transit_CC_ Active

r2_REPORT_req (Inband Tones)

PROCEEDING (num. complete)

r2_INFORMA-

r2_REPORT_ req

r2_RELEASE_ resp

r2_RELEASE_

TION_req

Transit_CC_ Call_Sent

Transit_CC_ Backward_ r2_Release

Transit_CC_ Wait_for_ Release_Channel

resp

NOTE 1 - This information flow is not acted upon after the receipt of an INFORMATION information flow with an 'number complete indicator' parameter. There is an inter-digit timer that is active, on the expiry of this timer no more INFORMATION information flows are accepted. NOTE 2 - The REPORT information flow can have the parameters: 'interworking', or 'call rejection' NOTE 3 - This Standard does not exclude possible implementation specific procedures which do not result in the call being released, e.g., alternate routeing.

Figure 40 – Stage 2 SDL diagram for Transit CC functional entity (Sheet 4 of 8)

- 68 -

Transit_CC_ Wait_for_ Release_Channel

Transit CC Requirement to Release Channel

r2_RELEASE_ ind

Disconnect

Release Resources Backwards

r2_RELEASE_ resp

r2_RELEASE_ req

Transit_CC_ Idle

Transit_CC_ Backward_ r2_Release

Figure 41 – Stage 2 SDL diagram for Transit CC functional entity (Sheet 5 of 8)

Transit_CC_ Active

r2_RELEASE_ ind

r2_RELEASE_

r2_RELEASE_ ind

r2_RELEASE_

req

Disconnect

Release Resources

Release Resources Forwards

Backwards

r2_RELEASE_ resp

Transit_CC_ Forward_ r2_Release

r2_RELEASE_ resp

Transit_CC_ Backward_ r2_Release

Figure 42 – Stage 2 SDL diagram for Transit CC functional entity (Sheet 6 of 8)

- 69 -

Transit_CC_ Backward_ r2_Release

r2_RELEASE_ cfm

Release Resources Backwards

Transit_CC_ Idle

Figure 43 – Stage 2 SDL diagram for Transit CC functional entity (Sheet 7 of 8)

Transit_CC_ Forward_ r2_Release

r2_RELEASE_ cfm

Release Resources Forwards

Transit_CC_ Idle

Figure 44 – Stage 2 SDL diagram for Transit CC functional entity (Sheet 8 of 8)

15.4

Destination CC functional entity SDL diagrams Output signals to the left and input signals from the left represent information flows across r2 to and from the preceding CC functional entity. Output signals to the right and input signals from the right represent information flows across r3 to and from the Destination CCA functional entity. The only exception to this rule is when the text within the signals explicitly identifies from what function the signal originates.

15.4.1

D e s t in a t io n C C s t a t e s u s e d in S D L d ia g r a m s • Dest_CC_Idle - No Call in progress • Dest_CC_Await_Response - Call has been initiated by the CC, and the CC awaits responses from the CCAs. • Dest_CC_Wait_for_Release_Channel - In-band tones /announcements being given to the calling PISN user, PISN user or CC originated clearing awaited.

- 70 -

• Dest_CC_Wait_for_Address_Info - The CC is awaiting additional information from the preceding CC. • Dest_CC_Call_Active - Call is in active phase. • Dest_CC_Backward_r2_Release - Resources have been disconnected, and clearing of the resources in the backward direction has been initiated, CC awaiting response from the preceding CC. • Dest_CC_Forward_r3_Release_Backward_r2_Release - Resources have been disconnected, and clearing has been initiated in both directions, CC awaiting responses from both the Destination CCA and the preceding CC. • Dest_CC_Forward_r3_Release - Resources have been disconnected, and clearing of the resources in the forward direction has been initiated, CC awaiting response from the Destination CCA. • Dest_CC_Forward_r3_Disconnect - Disconnection has been initiated, CC awaiting Destination CCA response. 15.4.2

D e s t in a t io n C C S D L d ia g r a m s

Dest_CC_ Idle

r2_SETUP_ ind

Terminating Node Screening

Call Processing Successful?

Y r2_CHANNEL_ ACKNOWLEDGE_ req

r3_SETUP_ req

Number Complete ? N

r2_SETUP_ REJECT_req

Start "Dest CC No User Response" Timer

Dest_CC_ Await_Response

Dest_CC_ Wait_for_ Address_Info

Dest_CC_ Idle

Figure 45 – Stage 2 SDL diagram for Destination CC functional entity (Sheet 1 of 10)

- 71 -

Dest_CC_ Wait_for_ Address_Info

r2_INFORMATION_Ind

r2_RELEASE_ ind

Number complete ? Y r2_SETUP_

r2_RELEASE_

req

resp

Start "Dest CC No User Response" timer

Dest_CC_ Wait_for_ Address_Info

Dest_CC_ Await_Response

Dest_CC_ Idle

Figure 46 – Stage 2 SDL diagram for Destination CC functional entity (Sheet 2 of 10)

- 72 -

Dest_CC_ Await_Response D r2_RELEASE_ ind

r2_RELEASE_ resp

"Dest CC No User Response" Timer Expiry

r3_DISCONNECT_

Any CCA responded ?

Delete from list of responding CCAs

ind

Y r3_RELEASE_

r3_RELEASE_ req

req

Note 2

Any CCA responded?

Note 2

Any more CCAs?

"Dest CC No user response" timer still running?

r3_RELEASE_

req

Tones Required?

Note 2

Any CCA still alerting

Dest_CC_

Await_repsonse

Any more CCAs?

Tones Required?

N r2-RELEASE req

r2 - REPORT req

r2_RELEASE_

r2_REPORT_req

(call rejection)

req

(call rejection)

Dest_CC_ Backward r2_Release

Dest_CC_Wait_ for_Release_ Channel

Dest_CC_ Backward r2_Release

Dest_CC_Wait_ for_Release_ Channel

Note 3 Dest_CC_ Idle

NOTE 1 - The provision of Ring Tone depends on the Basic Service provided. NOTE 2 - A separate state machine is generated (not shown) for each CCA to which an r3_RELEASE_req is sent. The separate state machine is cleared on receipt of an r3_RELEASE_cfm. NOTE 3 - If any further CCAs respond prior to the expiry of the "Destination CC No User response" timer, they should be cleared by sending a r3_RELEASE_req and generating a new state machine to await confirmation.

Figure 47 – Stage 2 SDL diagram for Destination CC functional entity (Sheet 3 of 10)

- 73 -

D Dest CC Requirement to indicate Interworking

r3_REPORT_ind (user being alerted)

First CCA to report alerting?

r3_SETUP_ REJECT_ind

r3_SETUP_ cfm

Remove Ring Tone

r3_CHANNEL_ ACKNOWLEDGE_ ind

Delete from list of

Record each

responding CCA's

CCA's Response

Dest_CC_ Await_repsonse

Y Through Connect Forwards

Stop "Dest CC No User Response" Timer Note 1 r2_REPORT_req (Interworking)

r2_REPORT_req (user being alerted)

r2_SETUP_ resp

Apply Ring Tone

r3_CHANNEL_ CONNECT

Stop "Dest CC No User Response" Timer

Any CCA responded?

Y r3_RELEASE_ req (note 2)

Any other CCAs?

N Dest_CC_ Await_Repsonse

Dest_CC_

Await_Response

Active

Figure 48 – Stage 2 SDL diagram for Destination CC functional entity (Sheet 4 of 10)

- 74 -

Dest_CC_ Active

r2_RELEASE_

r3_DISCONNECT_

ind

r3_DISCONNECT_ req

r2_RELEASE_ req

Disconnect

Release Resources Backwards

r2_RELEASE_ resp

r3_RELEASE_

Dest_CC_ Forward_ r3_Disconnect

Dest_CC_Forward_ r3_Release_Backward r2_Release

req

Figure 49 – Stage 2 SDL diagram for Destination CC functional entity (Sheet 5 of 10)

Dest_CC_Forward_ r3_Release_Backward_ r2_Release

r2_RELEASE_ cfm

r3_RELEASE_ cfm

Release Resources Backward

Release Resources Forward

Dest_CC_ Forwards_ r3_Release

Dest_CC_ Backwards_ r2_Release

Figure 50 – Stage 2 SDL diagram for Destination CC functional entity (Sheet 6 of 10)

- 75 -

Dest_CC_ Wait_for_ Release_Channel_

Dest CC Requirement to Release Channel

r2_RELEASE_ ind

Release Resources Forwards

r2_RELEASE_ req

r2_RELEASE_ resp

Dest_CC_ Backward _ r2_Release

Dest_CC_ Idle

Figure 51 – Stage 2 SDL diagram for Destination CC functional entity (Sheet 7 of 10)

Dest_CC_ Backward_ r2_Release

r2_RELEASE_ cfm

Release Resources Backward

Dest_CC_ Idle

Figure 52 – Stage 2 SDL diagram for Destination CC functional entity (Sheet 8 of 10)

- 76 -

Dest_CC_ Forward_ r3_Release

r3-RELEASE cfm

Release Resources Forward

Dest_CC_ Idle

Figure 53 – Stage 2 SDL diagram for Destination CC functional entity (Sheet 9 of 10)

Dest_CC_ Forward_ r3_Disconnect

r3_RELEASE_ ind

r3_RELEASE_ resp

Release Resources Forward

Dest_CC_ Idle

Figure 54 – Stage 2 SDL diagram for Destination CC functional entity (Sheet 10 of 10)

- 77 -

15.5

Destination CCA functional entity SDL diagrams Output signals to the left and input signals from the left represent information flows across r3 to and from the Destination CC functional entity. Output signals to the right and input signals from the right represent primitives to and from the Destination PISN user. The only exception to this rule is when the text within the signals explicitly identifies from what function the signal originates.

15.5.1

Destination CCA states used in SDL diagrams • Dest_CCA_Idle - No Call in progress • Dest_CCA_Call_Sent - Call has been initiated by the CC, the channel has been reserved to the PISN user, and Destination PISN user response is awaited. • Dest_CCA_Call_Active - Call is in active phase. • Dest_CCA_Backward_r3_Release - Resources have been disconnected, and clearing of the resources in the backward direction has been initiated, CCA awaiting response from the preceding CC. • Dest_CCA_Backward_Release_Backward_r3_Disconnect - Disconnection has been initiated, CCA awaiting response from Destination PISN user. • Dest_CCA_Forward_Release_Forward_r3_Disconnect - Disconnection has been initiated, CCA awaiting response from Destination CC. • Dest_CCA_Pending_Channel_Confirmation - Call has been accepted, CCA awaiting to be awarded the call.

15.5.2

Destination CCA SDL diagrams

Dest_CCA_ IDLE r3_SETUP_ ind SETUP_ ind Dest_CCA_ Call_Sent

Figure 55 – Stage 2 SDL diagram for Destination CCA functional entity (Sheet 1 of 7)

- 78 -

Dest_CCA_ Call Sent

r3_DISCONNECT_ind

REPORT_req (user being alerted)

SETUP_ resp

RELEASE_ req

RELEASE_ ind

r3_REPORT_ req (user being alerted)

r3_SETUP_ resp

r3_DISCON-

Dest_CCA_Forward_ Release_Forward_ r3_Disconnect

Dest_CCA_ Call_Sent

Dest_CCA_ Pending_Channel_ Confirmation

Dest_CCA_Backward_ Release_Backward_ r3_Disconnect

NECT_req

Figure 56 – Stage 2 SDL diagram for Destination CCA functional entity (Sheet 2 of 7)

Dest_CCA_ Pending_Channel_ Confirmation

r3_DISCONNECT_ ind

r3_CHANNEL_

RELEASE_

CONNECT_ind

req

RELEASE_ ind

r3_DISCONNECT_

Cut-through Both Directions

Dest_CCA_Forward_ Release_Forward_ r3_Disconnect

Dest_CCA_ Active

Disconnect

Dest_CCA_Backward_ Release_Backward_ r3_Disconnect

Figure 57 – Stage 2 SDL diagram for Destination CCA functional entity (Sheet 3 of 7)

- 79 -

Dest_CCA_ Active

r3_DISCONNECT_

RELEASE_ req

ind

r3_DISCONNECT_

Disconnect

req

RELEASE_ ind

Disconnect

Dest_CCA_Forward_ Release_Forward_ r3_Disconnect

Dest_CCA_Backward_ Release_Backward_ r3_Disconnect

Figure 58 – Stage 2 SDL diagram for Destination CCA functional entity (Sheet 4 of 7)

Dest_CCA_Backward_ Release_Backward_ r3_Disconnect

r3_RELEASE_ ind

Release Resources in both directions

RELEASE_cfm

r3_RELEASE_ resp

Dest_CCA_Idle

Figure 59 – Stage 2 SDL diagram for Destination CCA functional entity (Sheet 5 of 7)

- 80 -

Dest_CCA_Forward_ Release_Forward_ r3_Disconnect

r3_RELEASE_ ind

RELEASE_ resp

Release Resources in both directions

r3_RELEASE_ resp

r3_RELEASE_ req

Dest_CCA_

Dest_CCA_Backward_

Idle

r3_Release

Figure 60 – Stage 2 SDL diagram for Destination CCA functional entity (Sheet 6 of 7)

Dest_CCA_Backward_ r3_Release

r3_RELEASE_ cfm

Dest_CCA_ Idle

Figure 61 – Stage 2 SDL diagram for Destination CCA functional entity (Sheet 7 of 7)

- 81 -

Allocation of functional entities to physical entities The allocations of the functional elements to physical locations are shown in table 10. Table 10 – Allocation of FEs to physical entities

r2*

Functional Entities

r2 r2 Originating CCA

Scenarios 1. Intra-PISN Call

Transit CC

O/G r2 Gateway CC

r2* r2

I/C Gateway CC r2

Originating CC PINX

1.2

PINX

1.3

PINX

(note 2)

1.4

PINX

2. Outgoing Call

2.1

PINX

to other network

2.2

PINX

(note 2)

2.3

PINX

3. Incoming Call

3.1

PINX

from other network

3.2

PINX

3.3

PINX

4. PISN Transit Call

(note 1)

Destination CC

Destination CCA

PINX

(note 1)

PINX

PINX PINX

PINX

(note 1)

4.1

PINX

4.2

PINX

(note 2)

4.3

PINX

(note 2)

4.4

PINX

Legend:

(note 1)

(note 2)

r2 Transit CC

1.1

(note 3)

PINX

PINX = Private Integrated services Network Exchange I/C Gateway CC = Incoming Gateway CC O/G Gateway CC = Outgoing Gateway CC TE = Terminal Equipment Type 1, Terminal Adaptor together with Terminal Equipment Type 2

NOTE 1 Entities connected by a dashed line are phyiscally collocated. NOTE 2 Transit CC can be allocated physically to either one or multiple, concatenated PINXs. NOTE 3 A tandem outgoing and incoming call is to be considered as two separate PISN calls and not an intra-PISN call ( see scenarios 2 and 3 above).

- 82 -

- 83 -

Annex A ( n o r ma tiv e )

Service attributes

For each specific service category described in clauses 6, 7 and 8 the attributes, as described in ITU-T Recommendations I.140 and I.210, are given. Bearer services are described by low layer attributes. Teleservices are described by both low layer attributes and high layer attributes. High layer attributes are outside the scope of this Standard. The low layer attributes described in ITU-T Recommendation I.210 consist of information transfer attributes, access attributes and general attributes. The information transfer attributes define the network capabilities for transferring information between PISN users of the service. The access attributes define the way in which PISN functions are accessed at the S reference point. Access attributes may differ for different PISN users in a call. General attributes are not used in this Standard. Information transfer attributes are sub-divided into dominant attributes, defining bearer service categories, and secondary attributes, defining individual bearer services within a category. The dominant information transfer attributes are: 1.

Information transfer mode,

Information transfer rate,

Information transfer capability,

Structure.

The secondary information transfer attributes are: 5.

Establishment of communication (note 73),

Symmetry (note 74),

Communication configuration (note 75).

The access attributes are: 8.

Access channel and rate (note 76),

Access protocols (note 76).

NOTE 73 Only demand services are specified in this Standard. Reserved and permanent services may be the subject of future standards. NOTE 74 Only bi-directional symmetric services are specified in this Standard. Unidirectional services may be the subject of future standards. NOTE 75 Only point-to-point services are specified in this Standard. Multi-point basic services may be the subject of future standards. Multi-point may, however, be provided in conjunction with some bearer service categories by means of conference call supplementary services. NOTE 76 The access attributes refer only to the user information, not the signalling information.

- 84 -

- 85 -

Annex B ( n o r ma tiv e )

Teleservices

B.1

General A PISN can support teleservices requiring the same bearer capabilities as the bearer services specified in this Standard. These teleservices include for example: • Telephony 3,1 kHz teleservice; • Telefax group 4 teleservice; and, • Circuit-mode syntax-based videotex teleservice. The support by a PISN of one or more of these teleservices is optional. However, if a PISN supports one or more of these teleservices then it shall comply with this annex. The bearer capabilities and other special requirements used to support these teleservices are specified below. Otherwise, the impact of these teleservices on the network is the same as for the corresponding bearer service. The PISN shall convey an indication of the teleservice being used as High Layer Compatibility information, from the calling PISN user to the called PISN user. Any use of this indication by the PISN is outside the scope of this Standard. A PISN may reject a request for a teleservice if the requested bearer capabilities are not those specified in this annex. NOTE 77 Additional information can be found in the following ITU-T Recommendations: I.241.1 (Telephony 3,1 kHz); I.241.3 (Telefax group 4); and, I.241.5 (Circuit-mode syntax-based videotex). High layer functions for interworking between these teleservices and non-ISDN networks are beyond the scope of this Standard.

- 86 -

B.2

Telephony 3,1 kHz teleservice When this teleservice is required, the bearer capability requested shall comply with the low layer attributes specified in table B.1 below. Table B.1 - Low layer attributes for telephony 3,1 kHz teleservice 1) 2) 3) 4) 5) 6) 7) 8) 9)

Low layer attribute Information transfer mode: Information transfer rate: Information transfer capability: Structure: Establishment of communication: Symmetry: Communication configuration: Access channel (note 2): Access protocol (note 2):

NOTE 1: NOTE 2:

B.3

Attribute value circuit 64 kbit/s speech (note 1) 8 kHz integrity demand bi-directional symmetric point-to-point B ITU-T Recommendation G.711 (A-law or µ-law). In interworking situations the information transfer capability can default to 3,1 kHz audio. Attribute refers only to the user information, and not to the signalling information.

Telefax group 4 teleservice When this teleservice is required, the bearer capability requested shall comply with the low layer attributes specified in table B.2 below. T a b l e B . 2 - L o w l a y e r a t t r i b u t e s f o r t e le f a x g r o u p 4 t e le s e r v ic e 1) 2) 3) 4) 5) 6) 7) 8) 9)

NOTE 1: NOTE 2: NOTE 3:

Attribute value circuit 64 kbit/s unrestricted unstructured (note 1) demand bi-directional symmetric point-to-point B ISO/IEC 7776 & ISO/IEC 8208 (note 3) Even if no structure is required, the network may provide 8 kHz integrity. Attribute refers only to the user information, and not to the signalling information. The use of a packet-mode bearer capability to support this teleservice is outside the scope of this edition of this Standard.

- 87 -

B.4

Circuit-mode syntax-based videotex teleservice When this teleservice is required, the bearer capability requested shall comply with the low layer attributes specified in table B.3 below. Table B.3 - Low layer attributes for circuit-mode syntax-based videotex teleservice 1) 2) 3) 4) 5) 6) 7) 8) 9)

NOTE 1: NOTE 2: NOTE 3:

- 88 -

- 89 -

Annex C ( in f o r ma tiv e )

Bibliography

The ITU-T Recommendations listed in this annex are informative and considered useful for the understanding of this Standard. Most of these recommendations refer to similar functions which are provided by public ISDNs. • ITU-Recommendation I.130

– Method for the characterisation of telecommunication services supported by an ISDN and network capabilities of an ISDN

• ITU-T Recommendation I.220

– Common dynamic description of basic telecommunication services

• ITU-T Recommendation I.230

– Definition of bearer services

• ITU-T Recommendation I.231

– Circuit mode bearer services categories

• ITU-T Recommendation I.240

– Definition of teleservices

• ITU-T Recommendation I.241.1 – Teleservices supported by an ISDN: Telephony • ITU-T Recommendation I.241.3 – Teleservices supported by an ISDN: Telefax 4 • ITU-T Recommendation I.241.5 – Teleservices supported by an ISDN: Videotex • ITU-T Recommendation Q.65

– Stage 2 of the method for the characterisation of services supported by an ISDN

• ITU-T Recommendation Q.71

– ISDN 64 kbit/s circuit mode switched bearer services

• ITU-T Recommendation X.25

– Packet mode

• ITU-T Recommendation X.75

– Packet-switched Signalling Systems between Public Networks providing Data Transmission services

- 90 -

- 91 -

Annex D ( in f o r ma tiv e )

Errors in ISO/IEC 11574 1st edition

D.1

Changes applied to this Standard This Standard contains changes relative to ISO/IEC 11574 1st edition which result from corrections of obvious errors in ISO/IEC 11574 1st edition. Annex D lists these changes. The majority of these changes are to correct minor editorial problems. However, where there is a technical change, this is indicated and the rationale is given. The changes are as follows:

D.1.1

Amendments to clause 1 • In Note 1, change "64 kbits/s" to "64 kbit/s". • In Note 2, add "the " before "time of publication".

D.1.2

Amendments to clause 2.2 Move references Rec. I.130 and Rec. Q.65 to annex C since they are not mentioned in other clauses.

D.1.3

Amendment to clause 3.5 Delete the dot after "network".

D.1.4

Amendments to clause 4 • Capitalize the first letters F and E in "functional entity". • Change "Network_Exchange" to "Network Exchange".

D.1.5

Amendment to clauses 5 and 5.1 Change "Services" to "services" in the title line of clauses 5 and 5.1.

D.1.6

Amendment to clause 5.2 In the penultimate line of the 2nd paragraph, insert the word "of" after the word "scope".

D.1.7

Amendment to clause 5.5 In the bullet list below the REPORT primitive, move " and" from the last bullet to the end of the last-butone bullet.

D.1.8

Amendment to clause 6.2 In the 2nd bulleted paragraph, move the comma to the end of the text in brackets and add a full stop at the end of the sentence.

D.1.9

Amendment to clause 6.5.1 In the title of clause 6.5.1, change the word "network" to "networks".

D.1.10 Amendment to clause 6.5.3 In the 2nd paragraph, replace the words "a analogue network" by "an analogue network".

D.1.11 Amendment to clause 6.6 In the first line, change the word "attribute" to "attributes".

D.1.12 Amendment to clause 7.5.1 In the title of clause 7.5.1, change the words "Digital Networks" to "digital networks".

- 92 -

D.1.13 Amendment to clause 7.6 In the first line, change the word "attribute" to "attributes".

D.1.14 Amendments to clause 8.1 • In the 2nd paragraph, insert the word "etc." after the words "speech processing devices, ". • In Note 23, delete the word "International" and change the word "Standard" to "standard".

D.1.15 Amendment to clause 8.5.1 In the title of clause 8.5.1, change the words "Digital Networks" to "digital networks".

D.1.16 Amendment to clause 8.5.2 In the last line, change the word "provides" to "provide".

D.1.17 Amendment to clause 8.6 In the first line, change the word "attribute" to "attributes".

D.1.18 Amendments to clause 9.2.1 • In item (g), change the ";" to a full stop; • in the paragraph preceding Note 31, change "alway" to "always". Technical change: The existing text is incorrect for a number of reasons: 1. the text states is optional for the Network Call Control (NCC) entity to convey the items of information listed in the bullet points to the calling PISN user. In fact, it is optional for the called user to supply them; if supplied to the NCC entity. they must be conveyed to the calling PISN user; 2. HLC information would not be available in the backward direction at this point in call establishment unless HLC selection procedures were being used - the scope of the International Standard specifically states that the negotiation of service at call establishment time is outside the scope; 3. The sentence: "The called user may use the LLC and HLC information for compatibility checking." is out of context here, as the paragraph is dealing with behaviour at the calling side. The changes proposed correct these 3 problems, as well as 2 editorial problems. In the last paragraph of clause 9.2.1, replace the text: "The confirmation may optionally contain: • the connected PISN user's subaddress, • the Lower (sic) Layer Compatibilty (sic) information, and • High Layer Compatibility information if they have been provided. The called user may use the LLC and HLC information for compatibility checking." by: "The confirmation shall contain: • the connected PISN user's subaddress, and/or • the Low Layer Compatibility information, if either were contained in the SETUP_response sent by the called PISN user." and insert a paragraph break before the sentence beginning "For certain service categories ....".

D.1.19 Amendment to clause 9.2.2 In item (d), change ".;" to ";" at the end of the line. Technical change: see 9.2.1 above (rationale item 2). In the last paragraph of clause 9.2.2, replace the text ", low layer compatibility information and high layer compatibility information." by "and/or low layer compatibility information.".

- 93 -

D.1.20 Amendment to clause 9.2.3 At the end of the first paragraph, the colon should not be underlined. Technical change: The word "may" is incorrect, implying that the ability to release the call using RELEASE_request is an implementation option The word "can" would be more correct, implying that either PISN user has the ability to release the call and that if this ability is exercised then RELEASE_request is used. Two sentences would be the best solution, however. Replace the sentence beginning "The call may be released ..." by "The call can be released by either of the PISN users. A PISN user shall release a call by transferring a request for release (RELEASE_request) across its service access point.".

D.1.21 Amendment to clause 10.1.2, Note 37 In note 37, insert the word "the" before the words "called user" and change the word "limitted" to "limited".

D.1.22 Amendments to clause 10.1.3 • Replace the words "user, and when the call" by "user and the call"; • in Note 38, insert commas before and after the words "for example".

D.1.23 Amendments to clause 10.2.1 • In item (a) of clause 10.2.1, replace the word "PISN" by "public ISDN". • In items (c) and (d) of clause 10.2.1, replace "e.g" by "e.g.,".

D.1.24 Amendments to clause 10.2.3 • In item (a) of clause 10.2.3, delete the words "and optionally pass on if provided". Rationale: The words appear to be superfluous. • In the last paragraph, change "I.251.1" to "I.251.5".

D.1.25 Amendment to clause 10.2.4 Replace the word "Report_indication" by "REPORT_indication".

D.1.26 Amendment to clause 12.2.2.4 Insert the word "the" before the words "access functional entity".

D.1.27 Amendment to clause 13.2 At the end of the first paragraph, insert a fullstop (period) after the words "Table 2".

D.1.28 Amendment to clause 13.2, Table 1 Technical change: The information content of SETUP_response/confirmation incorrectly shows the inclusion of the Connection Type Service Element as "not applicable"; it should be shown as "optional". In the response/confirmation column of Table 1, in the row for CT Connection Type, replace "-", by "O".

D.1.29 Amendments to clause 13.2, Table 2 In table 2, in the row for CT Connection Type: • in the 1st column, the words "3,1 kHz audio" are incorrectly spaced; • in the 2nd column, insert the words "Low layer compatibility transfer mode"; • in the 3rd column, the words "Low layer compatibility

D.1.30 Amendment to clause 13.6 Correct the spelling of the word "invite".

D.1.31 Amendment to clause 13.8 In the first sentence, change "r1, r2 and r3" to "r1 and r2".

- o" before the words "Information

- o" should all appear on the same line.

- 94 -

D.1.32 Amendment to clause 13.9, Table 9 In the middle column, change "r1, r2" to "r1, r2, r3".

D.1.33 Amendment to clause 13.10, Table 10 In the middle column, change "r1, r2, r3" to "r1, r2".

D.1.34 Amendment to clause 14.1.1 In "Function 016", change "PROCEEDING_indication" to "r1_PROCEEDING_indication" and "primative" to "primitive".

D.1.35 Amendments to clause 14.1.2 In "Function 103", change "shall cut-through" to "shall be cut-through". In "Function 115", delete the word "primitive". In "Function 117", change the text to "The r2_PROCEEDING_indication r1_PROCEEDING_request is sent to the Originating CCA."

processed.

D.1.36 Amendments to clause 14.1.3 In item (c) of "Function 200", insert a space before each of the 2 left bracket characters, "(". In item (d) of "Function 200", change "contained in the r2_SETUP, " to "contained in the r2_SETUP_indication, ". In the second sentence of "Function 202", change "r2_REPORT_indication" to "r2_REPORT_request". In the last sentence of "Function 203", change "Connect Number Subaddress" to "Connected Subaddress". In the second sentence of "Function 206" and "Function 207", change "r2_REPORT " to "r2_REPORT_request ". In "Function 216": • in item (a), replace the space character after the word "INFORMATION" by an underline character, "_"; • in item (b), change "r2_INFORMATION indication" to "r2_INFORMATION_request"; • make the bulleted paragraph below item (b) an item (c) and change "PROCEEDING_request" to "r2_PROCEEDING_request".

D.1.37 Amendments to clause 14.1.4 In clause 14.1.4: • in item (d) of "Function 300" and item (c) of "Function 315", delete "Originating Subaddress, "; Rationale: Transport of this element across relationship r3 is outside the scope of this Standard. • in item (c) of "Function 303", delete the word "Number" from "Connected Number Subaddress"; • in item (a) of "Function 310", delete the characters "ISO/IEC "; • in item (a) of "Function 315", replace the space character after the word "INFORMATION" by an underline character, "_".

D.1.38 Amendment to clause 14.1.5 In item (b) of "Function 410", delete the characters "ISO/IEC ".

D.1.39 Amendments to clause 14.1.6 • In "Function 131", delete the last sentence. Rationale: Contradicts the first sentence and does not belong here. • In "Function 140", Note 61, change "is" to "are".

D.1.40 Amendment to clause 14.2, figure 6 Remove the letters "rq" from rightmost column.

- 95 -

D.1.41 Amendments to clause 14.3 • Delete the word "with" from "and with when"; • in figure 7, add the list of elements to the SETUP_res/cfm flow across r1 and r2, and add a comma between "DS" and "CI" in the list of elements below r3_SETUP_req/ind.

D.1.42 Amendment to clause 14.4, figure 8 Complete the arrow on top representing relationship r1.

D.1.43 Amendment to clause 14.6, figure 10 Remove the letters "r1" from above the leftmost arrow on top. Rationale: The figure for outgoing interworking in 14.7 has a note to explain what the content of the CH service element should be; there is no similar note for the incoming interworking case. Replace the existing note after the figure with the following: "NOTES 1. CH (Call History) in the SETUP_request/indication information flows contains the service parameter: "Signalling interworking: non-common channel signalling system". 2. The RT (Report Type) in this sequence is "User being alerted"."

D.1.44 Amendments to clause 14.7 Technical change: The use of the phrase "interworking with non-ISDN marker", is technically incorrect and thus confusing. The proper name of the stage 2 service parameter should be used here. Replace note 1 by the following: 1 CH (Call History) in the REPORT_request/indication information flows contains the service parameter: "Signalling interworking: non-common channel signalling system".

D.1.45 Amendments to clause 14.9, figure 13 • Add the missing annotation "r3_RELEASE" in the rightmost column; • in the Note, change "r1" to "r1/r3" in both sentences.

D.1.46 Amendment to clause 14.10, figure 14 Technical change: Note 1 is wrong - see above. Replace note 1 by the following: 1. The CH (Call History) service element, if present, contains the "Interworking with a public network" service parameter, and/or "Signalling interworking: non-common channel signalling system" service parameter.

D.1.47 Amendments to clause 14.11, figure 15 • Delete ",CH" from the list of elements below flow r2*_REPORT_req/ind in the rightmost column; Technical change: Note 1 is wrong - see above. Replace note 1 by the following: 1. The CH (Call History) service element, if present, contains the "Interworking with a public network" service parameter, and/or "Signalling interworking: non-common channel signalling system" service parameter.

D.1.48 Amendments to clause 15.1.1 • In the third bullet item, add a comma after "PISN user"; • In the fourth bullet item, correct the spelling of "originated"; • In the fifth bullet item, add a comma after "CCA".

- 96 -

D.1.49 Amendment to clause 15.1.2, figure 23 Delete the third input symbol. Rationale: Is the same as the first input, which seems more correct. Alternatively, the leftmost branch could be removed, and the third input could connect to the rightmost branch.

D.1.50 Amendments to clause 15.2.1 • In the seventh bullet item, change "preceding CC" to "Originating CCA"; • in the last-but-one bullet item, change "responses" to "response".

D.1.51 Amendments to clause 15.2.2 • In figure 28, change "Proceeding" to all upper case (twice in the middle branch); • in figure 29, the correct state at the "Orig_CC_Backward_r1_Release_Forward_ r2_Release";

end

the

leftmost

branch

• in figure 36, the correct state at the end of the left branch is "Orig_CC_Forward_r2_Release".

D.1.52 Amendments to clause 15.3.2 • In figure 39, the correct state at the end of the leftmost branch is "Transit_CC_Forward_r2_Release"; • in figure 40, the 3rd state symbol on the bottom must say "Transit_CC_Call_Sent"; • in figure 42, the state symbol on top must say "Transit_CC_Active".

D.1.53 Amendment to clause 15.4.1 In the 2nd bullet item, delete "a " from "awaits a responses".

D.1.54 Amendments to annex A • In item 6., change "note 2" to "note 74"; • in item 7., change "note 74" to "note 75"; • in item 8., change "note 75" to "note 76".

D.1.55 Amendment to annex C Delete reference to ITU-T Rec. X.31, as it is already contained in clause 2.

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

+41 22 849.60.01 [email protected]

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

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

ECMA-142 — Private Integrated Services Network (PISN) - Circuit mode 64kbit/s bearer services - Service description, functional capabilities and information flows (BCSD) (December 2001)

Related documents