Standard ECMA-266 Sep te mb e r 1 9 9 7
Standardizing
Information
and
Communication
Systems
Broadband Private Integrated Services Network (B-PISN) Inter-Exchange Signalling Protocol Basic Call/Connection Control
P h o n e : + 4 1 2 2 8 4 9 . 6 0 . 0 0 - F a x : + 4 1 2 2 8 4 9 . 6 0 . 0 1 - U R L : h t t p : / / www. e c m a . c h - I n t e r n e t : h e l p d e s k @ e c m a . c h
.
Standard ECMA-266 Sep te mb e r 1 9 9 7
Standardizing
Information
and
Communication
Systems
Broadband Private Integrated Services Network (B-PISN) Inter-Exchange Signalling Protocol Basic Call/Connection Control (B-QSIG-BC)
P h o n e : + 4 1 2 2 8 4 9 . 6 0 . 0 0 - F a x : + 4 1 2 2 8 4 9 . 6 0 . 0 1 - U R L : h t t p : / / www. e c m a . c h - I n t e r n e t : h e l p d e s k @ e c m a . c h IW Ecma-266.doc
04-09-97 10,08
.
Brief History
This Standard is one of a series of ECMA Standards defining services and signalling protocols applicable to Broadband Private Integrated Services Networks (B-PISNs). The series uses B-ISDN concepts as developed by ITU-T and conforms to the framework of International Standards for Open Systems Interconnection as defined by ISO/IEC. It has been produced under ETSI work item DEN/ECMA-00131. This particular Standard specifies the signalling protocol for use at the Q reference point for basic call/connection control. 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, the ATM Forum, ETSI and other international and national standardization bodies. It represents a pragmatic and widely based consensus. This ECMA Standard is completely aligned with International Standard ISO/IEC 13247 to be published by ISO/IEC.
This ECMA Standard has been adopted by the General Assembly in September 1997.
.
- i -
Table of contents 1 Scope
1
2 Conformance
2
3 References (normative)
2
4 Definitions
3
4.1 Definitions in PNNI 1.0
3
4.2 Other external definitions
3
4.3 Other definitions
3
4.3.1 ATM endsystem address
3
4.3.2 Broadband private integrated services network (B-PISN)
3
4.3.3 Call
3
4.3.4 Call/connection
4
4.3.5 En bloc
4
4.3.6 Gateway PINX
4
4.3.7 Incoming call/connection
4
4.3.8 Incoming gateway PINX
4
4.3.9 Information element
4
4.3.10 Information element with invalid contents
4
4.3.11 Inter-PINX link (IPL)
4
4.3.12 Inter-PINX virtual channel (IPVC)
4
4.3.13 Inter-PINX virtual channel identifier (IPVCI)
4
4.3.14 Inter-PINX virtual path (IPVP)
4
4.3.15 Inter-PINX virtual path identifier (IPVPI)
4
4.3.16 Interworking PINX
4
4.3.17 Narrow-band private integrated services network (N-PISN)
4
4.3.18 Originating PINX
4
4.3.19 Outgoing call/connection
4
4.3.20 Outgoing gateway PINX
5
4.3.21 Overlap
5
4.3.22 Preceding PINX
5
4.3.23 Preceding side
5
4.3.24 Public broadband ISDN (public B-ISDN)
5
4.3.25 Public integrated services digital network (public ISDN)
5
4.3.26 Public narrow-band ISDN (public N-ISDN)
5
4.3.27 Side
5
4.3.28 Signalling AAL (SAAL)
5
4.3.29 Succeeding PINX
5
4.3.30 Succeeding side
5
4.3.31 Terminating PINX
5
4.3.32 Transit PINX
5
4.3.33 Unexpected message
5
- ii -
4.3.34 Unrecognised information element
5
4.3.35 Unrecognised message
6
4.3.36 Unspecified bit rate (UBR)
6
4.3.37 Virtual channel
6
4.3.38 Virtual channel connection
6
5 List of acronyms
6
6 General Principles
7
6.1 Protocol model
8
6.2 Services provided to CCH
9
6.3 Services required of the SAAL
10
6.4 Protocol Control states
10
6.4.1 Call/connection states
10
6.4.2 Additional call/connection states relating to the provision of N-PISN services
10
6.4.3 States for restart initiation
10
6.4.4 States for restart response
10
6.5 CCH states at a Transit PINX
11
6.5.1 TCC_Idle (0)
11
6.5.2 TCC_Incoming_Call_Proceeding (4)
11
6.5.3 TCC_Transit_Call_Proceeding (5)
11
6.5.4 TCC_Call_Alerting (6)
11
6.5.5 TCC_Call_Active (7)
11
6.5.6 TCC_Await_Incoming_Release (8)
11
6.5.7 TCC_Await_Outgoing_Release (9)
11
6.5.8 TCC_Await_Two-Way_Release (10)
11
6.6 Additional CCH states relating to the provision of N-PISN services at a Transit PINX
11
6.6.1 TCC_Await_Digits (1)
11
6.6.2 TCC_Await_Additional_Digits (2)
12
6.6.3 TCC_Overlap (3)
12
7 Message functional definitions and content
12
7.1 Messages for B-QSIG call/ connection control
12
7.1.1 ALERTING
12
7.1.2 CALL PROCEEDING
12
7.1.3 CONNECT
12
7.1.4 RELEASE
13
7.1.5 RELEASE COMPLETE
13
7.1.6 SETUP
13
7.1.7 NOTIFY
13
7.1.8 PROGRESS
13
7.2 Additional or modified messages related to the support of 64 kbit/s based PISN circuit-mode services
14
7.2.1 ALERTING
14
7.2.2 CONNECT
15
- iii -
7.2.3 PROGRESS
15
7.2.4 RELEASE
15
7.2.5 SETUP
15
7.2.6 INFORMATION
15
7.2.7 SETUP ACKNOWLEDGE
16
7.3 Messages for point-to-multipoint call/connection control
16
7.3.1 ADD PARTY
16
7.3.2 ADD PARTY ACKNOWLEDGE
17
7.3.3 PARTY ALERTING
17
7.3.4 ADD PARTY REJECT
17
7.3.5 DROP PARTY
17
7.3.6 DROP PARTY ACKNOWLEDGE
17
7.4 Messages used with the global call reference
17
8 General message format and information elements coding
17
8.1 Overview
17
8.2 Protocol discriminator
18
8.3 Call reference
18
8.4 Message type, and message length
18
8.4.1 Message type
18
8.4.2 Message length
18
8.5 Variable length information elements for B-ISDN environment
18
8.5.1 Coding rules
18
8.5.2 Extensions of codesets
18
8.5.3 Broadband-locking shift procedure
18
8.5.4 Broadband-non-locking shift procedure
19
8.5.5 ABR additional parameters
19
8.5.6 ABR setup parameters
19
8.5.7 Alternative ATM traffic descriptor
19
8.5.8 ATM adaptation layer parameters
19
8.5.9 ATM traffic descriptor
19
8.5.10 Broadband bearer capability
19
8.5.11 Broadband high layer information (B-HLI)
19
8.5.12 Broadband low layer information (B-LLI)
19
8.5.13 Broadband repeat indicator
19
8.5.14 Broadband sending complete
19
8.5.15 Call state
20
8.5.16 Called party number
20
8.5.17 Called party subaddress
21
8.5.18 Calling party number
21
8.5.19 Calling party subaddress
21
8.5.20 Cause
21
8.5.21 Connected number
22
8.5.22 Connected subaddress
22
- iv -
8.5.23 Connection identifier
22
8.5.24 Connection scope selection
22
8.5.25 End-to-end transit delay
22
8.5.26 Extended Quality of service (QOS) parameter
22
8.5.27 Minimum acceptable ATM traffic descriptor
22
8.5.28 Notification indicator
22
8.5.29 Quality of service (QOS) parameter
22
8.5.30 Restart indicator
22
8.5.31 Transit network selection
23
8.5.32 OAM traffic descriptor
23
8.5.33 Progress indicator
23
8.5.34 Calling party soft PVPC or PVCC
23
8.5.35 Called party soft PVPC or PVCC
23
8.6 Information Elements for the support of 64 kbit/s based ISDN circuit mode services
23
8.6.1 Narrow-band bearer capability
23
8.6.2 Narrow-band high layer compatibility
24
8.6.3 Narrow-band low layer compatibility
24
8.6.4 Progress indicator
24
8.7 Information Elements for Point-to-Multipoint Call/connection control
24
9 Protocol control procedures for B-QSIG point-to-point calls/connections
24
9.1 Establishment of a signalling AAL
24
9.2 Call/Connection establishment
24
9.2.1 Handling of a PROGRESS message
25
9.2.2 Call/connection failure
25
9.3 Call/Connection clearing
26
9.4 Call/connection collisions
26
9.5 Restart procedure
26
9.6 Handling of error conditions
26
9.6.1 Sending a STATUS message
26
9.6.2 Determination of protocol state compatibility on receipt of a STATUS message containing a call reference other than the global call reference 26 9.7 Error procedures with explicit action indication
27
9.8 Handling of messages with insufficient information
27
9.9 Notification procedures
27
9.10 Notification of interworking
27
9.11 List of Timers
27
10 Call/connection Control Procedures for Point-to-Multipoint Calls
28
11 Procedures for the support of 64kbit/s based circuit mode basic services in B-PISN and interworking between N-PISNs and B-PISNs
28
11.1 Introduction
28
11.2 Use of information elements for N-PISN services
29
11.2.1 General aspects
29
- v -
11.2.2 Bearer service related information
29
11.2.3 Low layer related information
32
11.2.4 Higher layer related information
34
11.2.5 Handling of inconsistent combination of service parameters
34
11.3 Interworking PINX procedures for the succeeding side
34
11.3.1 Mapping of service related information
34
11.3.2 Mapping of cause information
34
11.4 Interworking PINX procedures for the preceding side
35
11.4.1 General aspects
35
11.4.2 Mapping of service related information
35
11.4.3 Mapping of cause information
35
11.5 Overlap sending
35
11.5.1 Preceding side procedures
35
11.5.2 Succeeding side procedures
36
11.6 Notification of interworking
36
11.7 Tones and announcements
37
11.7.1 Tones and announcements during call establishment
37
11.7.2 Clearing when tones and announcements are provided
37
12 Call/connection handling requirements
37
12.1 Transit PINX call/connection handling requirements
37
12.1.1 Receipt of SETUP message
38
12.1.2 Channel through connection procedures
38
12.1.3 State TCC_Incoming_Call_Proceeding
39
12.1.4 State TCC_Transit_Call_Proceeding
39
12.1.5 State TCC_Call_Alerting
39
12.1.6 State TCC_Call_Active
40
12.1.7 Clearing at a Transit PINX
40
12.1.8 Additional procedures for N-PISN interworking
40
12.1.9 Handling of basic call information elements at a Transit PINX
43
12.1.10 Notifications
45
12.2 Originating PINX call/connection handling requirements
45
12.2.1 Transmission of the SETUP message
45
12.2.2 Connection to the user plane virtual channel
46
12.2.3 Receipt of an ALERTING message
46
12.2.4 Receipt of a CONNECT message
46
12.2.5 Receipt of PROGRESS message
46
12.2.6 Notifications
46
12.2.7 Call/connection clearing initiated by the Originating PINX
47
12.2.8 Receipt of an indication of call/connection clearing
47
12.3 Terminating PINX call/connection handling requirements
47
12.3.1 Receipt of the SETUP message
47
12.3.2 Transmission of an ALERTING message
47
12.3.3 Transmission of a CONNECT message
47
- vi -
12.3.4 Notifications
48
12.3.5 Call/connection clearing initiated by the Terminating PINX
48
12.3.6 Receipt of an indication of call/connection clearing
48
12.4 Incoming Gateway PINX call/connection handling requirements
48
12.4.1 Transmission of the SETUP message
48
12.4.2 Connection of the user plane virtual channel
49
12.4.3 Receipt of ALERTING message
49
12.4.4 Receipt of CONNECT message
49
12.4.5 Receipt of PROGRESS message
49
12.4.6 Notifications
49
12.4.7 Call/connection clearing initiated by the Gateway PINX
50
12.4.8 Receipt of an indication of call/connection clearing
50
12.5 Outgoing Gateway PINX call/connection handling requirements
50
12.5.1 Receipt of the SETUP message
50
12.5.2 Connection of the user plane virtual channel
50
12.5.3 Transmission of ALERTING message
51
12.5.4 Transmission of CONNECT message
51
12.5.5 Transmission of PROGRESS message
51
12.5.6 Notifications
51
12.5.7 Call/connection clearing initiated by the Gateway PINX
51
12.5.8 Receipt of an indication of call/connection clearing
51
12.6 Interworking PINX call/connection handling requirements for N-PISN -> B-PISN interworking
51
12.6.1 Transmission of the SETUP message
52
12.6.2 Connection of the user plane virtual channel
52
12.6.3 Receipt of progress indicators
52
12.6.4 Receipt of CONNECT message
52
12.6.5 Call/connection clearing initiated by the interworking PINX
52
12.7 Interworking PINX call/connection handling requirements for B-PISN -> N-PISN interworking
53
12.7.1 Receipt of the SETUP message
53
12.7.2 Transmission of progress indications
53
12.7.3 Transmission of CONNECT message
53
12.7.4 Call/connection clearing initiated by the Interworking PINX
53
Annex A - Protocol Implementation Conformance Statement (PICS) proforma
55
Annex B - Soft permanent virtual connection procedures
77
Annex C - Mapping functions to support 64 kbit/s based circuit-mode PISN services in B-PISNs and interworking between N-PISNs and B-PISNs (QSIG/B-QSIG)
79
Annex D - Specification and Description Language (SDL) representation of protocol control procedures
85
Annex E - Guidelines for the use of instruction indicators
125
Annex F - Description of the capabilities supported by the protocol defined in this Standard
127
- vii -
Annex G - Specification and Description Language (SDL) representation of CCH at a Transit PINX and at an Interworking PINX
131
Annex H - Manufacturer specific information
145
Annex I - Possible strategies for avoidance of IPVCI collisions
147
Annex J - Differences between this Standard and PNNI 1.0
149
Annex K - Specification and Description Language (SDL) representation of point-to-multipoint procedures
151
Annex L - Guidelines for interworking with ATM Forum PNNI 1.0
153
- viii -
.
1
Scope This Standard defines the signalling protocol for the purpose of basic call/connection control at the Q-reference point between Private Integrated Services Network Exchanges (PINXs) connected together within a Broadband Private Integrated Services Network (B-PISN) employing Asynchronous Transfer Mode (ATM). This Standard is part of the B-QSIG signalling system. The Q reference point is defined in ISO/IEC 11579-1. This Standard is an application of the signalling protocol that forms part of the ATM Forum's PNNI 1.0 specification, which in turn is based on ITU-T Recommendation Q.2931, including the provisions for symmetrical operation described in annex H of recommendation Q.2931. Technical differences compared with the signalling protocol specified in PNNI 1.0 are summarised in annex J. Guidelines for interworking between a network employing the signalling protocol specified in this Standard and a network employing the ATM Forum’s PNNI 1.0 specification are given in annex L. This Standard is applicable to PINXs which interconnect to form a B-PISN using static hop-by-hop routeing. It therefore complements the ATM Forum's PNNI 1.0 specification, which is applicable to networks that employ dynamic source routeing. The basic capabilities supported by the protocol specified in this Standard are listed below and described in more detail in annex F: − demand (switched) virtual channel and virtual path connections; − point-to-point switched virtual channel and virtual path connections; − point-to-multipoint virtual channel connections; − connections with symmetric or asymmetric bandwidth requirements; − single-connection (point-to-point) calls; − basic signalling functions via protocol messages, information elements, and procedures; − CBR, VBR (realtime and non-realtime), UBR and ABR service categories; − negotiation of certain signalling parameters; − inter-PINX virtual channel identifier (IPVCI) negotiation; − out-of-band signalling for all signalling messages; − error recovery; − B-PISN addressing formats; − end-to-end compatibility parameter identification; − signalling interworking with N-PISN and provision of N-PISN services; − forward compatibility; − call/connection handling at different types of PINX, including Transit PINX, Originating PINX, Terminating PINX, Incoming Gateway PINX, Outgoing Gateway PINX and Interworking PINX; − Signalling of individual Q0S parameters − ATM anycast addresses − Negotiation of ATM traffic descriptors − Soft PVPC and PVCC support − Generic Identifier Transport
- 2 -
2
Conformance In order to conform to this Standard, a PINX shall satisfy the requirements identified in the Protocol Implementation Conformance Statement (PICS) proforma in annex A.
3
References (normative) The following standards contain provisions which, through reference in this text, constitute provisions of this Standard. All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. In the case of references to ECMA Standards that are aligned with ISO/IEC International Standards, the number of the appropriate ISO/IEC International Standard is given in brackets after the ECMA reference. ECMA-142
Private Integrated Services Network - Circuit-mode 64 kbit/s Bearer Services - Service Description, Functional Capabilities and Information Flows (International Standard ISO/IEC 11574)
ECMA-143
Private Integrated Services Network - Circuit-mode Bearer Services - Inter-Exchange Signalling Procedures and Protocol (International Standard ISO/IEC 11572)
ECMA-265
Broadband Private Integrated Services Network (B-PISN) - Inter-Exchange Signalling Protocol - Signalling ATM Adaptation Layer (International Standard ISO/IEC 13246)
ISO/IEC 8348
Information technology - Open Systems Interconnection - Network Service Definition (1996)
ISO/IEC 9646-1
Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 1: General concepts (1994)
ISO/IEC 9646-7
Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 7: Implementation Conformance Statements (1995)
ISO/IEC 11571
Information technology - Telecommunications and information exchange between systems Numbering and sub-addressing in private integrated services networks
ISO/IEC 11579-1
Information technology - Telecommunications and information exchange between systems Private Integrated Services Network - Part 1: Reference configuration for PISN Exchanges (PINX)
ISO/IEC 11584
Information technology - Telecommunications and information exchange between systems Private Integrated Services Network - Circuit-mode multi-rate bearer service - Service description, functional capabilities and information flows (1996)
CCITT Rec. I.330
ISDN numbering and addressing principles (Blue Book) (1988)
CCITT Rec. Q.9
Vocabulary of switching and signalling terms (Blue Book) (1988)
ITU-T Rec. E.164
Numbering plan for the ISDN era (1991)
ITU-T Rec. I.112
Vocabulary of terms for ISDNs (1993)
ITU-T Rec. I.321
B-ISDN protocol reference model and its application (1991)
ITU-T Rec. I.363
B-ISDN ATM adaptation layer (AAL) specification (1996)
ITU-T Rec. I.371
Traffic control and congestion control in B-ISDN (1996)
ITU-T Rec. I.610
B-ISDN operation and maintenance principles and functions (1995)
ITU-T Rec. Q.2931
Broadband Integrated Services Digital Network (B-ISDN) - Digital Subscriber Signalling System No. 2 (DSS2) - User-Network Interface (UNI) layer 3 specification for basic call/connection control (1995)
ITU-T Rec. Q.2971
Broadband Integrated Services Digital Network (B-ISDN) - Digital Subscriber Signalling System No. 2 (DSS2) - User-Network Interface (UNI) layer 3 specification for point-tomultipoint call/connection control (1995)
ITU-T Rec. Z.100
Specification and description language (1993)
- 3 -
ATM Forum PNNI 1.0 Private Network-Network Interface Specification Version 1.0 (af-pnni-0055.000) (1996) ATM Forum UNI 4.0
4
User-Network Interface (UNI) Signalling Specification Version 4.0 (af-sig-0061.000) (1996)
Definitions For the purposes of this Standard the following definitions apply.
4.1
Definitions in PNNI 1.0 References contained in sections 2.2 and 6.1 of PNNI 1.0 are applicable with the exception of the definitions applicable to the routing sections of PNNI 1.0 and with the exception of terms for which there are replacement definitions in 4.2 and 4.3 of this Standard. Where text of PNNI 1.0 is referenced from this Standard, terms used within the referenced text shall be interpreted a shown in table 1. Table 1 - Interpretation of PNNI terms
4.2
Term used in PNNI referenced text
Interpretation for the purposes of this Standard
network node
PINX
call
call/connection
logical link
inter-PINX link (IPL)
physical link
inter-PINX link (IPL)
virtual channel identifier (VCI)
inter-PINX virtual channel identifier (IPVCI)
virtual path identifier (VPI)
inter-PINX virtual path identifier (IPVPI)
PNNI interface
inter-PINX link (IPL)
PNNI link
inter-PINX link (IPL)
Other external definitions This Standard uses the following terms defined in other documents:
4.3 4.3.1
− ATM transfer capability (ATC)
(ITU-T Rec. I.371)
− connection
(CCITT Rec. Q.9)
− F5
(ITU-T Rec. I.610)
− private integrated services network (PISN)
(ISO/IEC 11579-1)
− private integrated services network exchange (PINX)
(ISO/IEC 11579-1)
− signalling
(CCITT Rec. I.112)
− user plane
(CCITT Rec. I.321)
Other definitions ATM endsystem address The address of a point of attachment to an ATM network.
4.3.2
Broadband private integrated services network (B-PISN) A PISN that offers ATM services to its users and employs ATM transmission between PINXs and ATM switching.
4.3.3
Call An association between two or more users for the use or attempted use of a telecommunication service.
- 4 -
4.3.4
Call/connection A call combined with a single connection in the user plane for the transfer of user information.
4.3.5
En bloc A method of signalling the called party number information in which all called party number digits are sent in the first message.
4.3.6
Gateway PINX Within the context of a call/connection, a PINX which performs interworking between B-QSIG and another signalling system.
4.3.7
Incoming call/connection A call/connection using an IPL from the point of view of the succeeding side of that IPL.
4.3.8
Incoming gateway PINX A Gateway PINX that routes a call/connection from a route employing another signalling system on to an IPL employing B-QSIG signalling. (See figure 1).
4.3.9
Information element A component of a message.
4.3.10
Information element with invalid contents An information element that is recognised, but whose contents cannot be interpreted as valid using the rules specified in clause 8 of this Standard, or that contains field values that are marked as “reserved” in clause 8 of this Standard.
4.3.11
Inter-PINX link (IPL) A link between the Q reference points of two PINXs, the link comprising a signalling IPVC together with one or more user information IPVCs under the control of that signalling IPVC.
4.3.12
Inter-PINX virtual channel (IPVC) One of a number of bi-directional transfers of digital information, multiplexed at the ATM layer, between two PINXs. NOTE 1 An IPVC can be a single virtual channel or a concatenation of virtual channels.
4.3.13
Inter-PINX virtual channel identifier (IPVCI) An integer that identifies an IPVC within the context of an IPVP.
4.3.14
Inter-PINX virtual path (IPVP) A grouping of one or more IPVCs within a single IPL.
4.3.15
Inter-PINX virtual path identifier (IPVPI) An integer that identifies an IPVP within the context of an IPL.
4.3.16
Interworking PINX Within the context of a call/connection, a PINX that performs interworking between a B-PISN and a N-PISN. NOTE 2 An interworking PINX will also be either an Originating PINX, a Terminating PINX or a Gateway PINX.
4.3.17
Narrow-band private integrated services network (N-PISN) A PISN that offers only 64 kbit/s-based services to its users.
4.3.18
Originating PINX Within the context of a call/connection, the PINX to which the calling user is attached. (See figure 1).
4.3.19
Outgoing call/connection A call/connection using an IPL from the point of view of the preceding side of that IPL.
- 5 -
4.3.20
Outgoing gateway PINX A Gateway PINX that routes an incoming call/connection from an IPL employing B-QSIG signalling on to a route employing another signalling system. (See figure 1).
4.3.21
Overlap A method of signalling the called party number information in which not all called party number information is sent in the same message.
4.3.22
Preceding PINX Within the context of a call/connection using an IPL, the PINX to which the preceding side of the IPL belongs, from the point of view of the PINX to which the succeeding side of the IPL belongs.
4.3.23
Preceding side In the context of a call/connection using an IPL, the side that initiates call/connection establishment over that IPL. (See figure 1).
4.3.24
Public broadband ISDN (public B-ISDN) A public ISDN that offers ATM services to its users and employs ATM transmission and switching.
4.3.25
Public integrated services digital network (public ISDN) A network that provides to the general public a range of different telecommunication services using digital connections.
4.3.26
Public narrow-band ISDN (public N-ISDN) A public ISDN that offers to the general public only 64 kbit/s-based services.
4.3.27
Side The Protocol Control entity in a PINX at one end of an IPL.
4.3.28
Signalling AAL (SAAL) The AAL used for the bi-directional transfer of layer 3 signalling information.
4.3.29
Succeeding PINX Within the context of a call/connection using an IPL, the PINX to which the succeeding side of the IPL belongs, from the point of view of the PINX to which the preceding side of the IPL belongs.
4.3.30
Succeeding side In the context of a call/connection using an IPL, the opposite side from the side that initiates call/connection establishment over that IPL. (See figure 1).
4.3.31
Terminating PINX Within the context of a call/connection, the PINX to which the called user is attached. (See figure 1).
4.3.32
Transit PINX Within the context of a call/connection, any PINX through which the call/connection passes, excluding any Originating PINX, Terminating PINX, Incoming Gateway PINX or Outgoing Gateway PINX. (See figure 1).
4.3.33
Unexpected message Within the context of a particular Protocol Control state, a message that is recognised, but for which no procedures are defined in 9.6 of this Standard (or in any other Standard relating to B-QSIG to which the PINX claims conformance) for receipt in that Protocol Control state.
4.3.34
Unrecognised information element An information element received in a particular message which is not specified as part of that message in clause 7 of this Standard or in any other Standard relating to B-QSIG to which the PINX claims conformance (e.g., a Standard specifying generic procedures for supplementary services). NOTE 3 The handling of national/private information elements is outside the scope of this Standard (see annex H).
- 6 -
4.3.35
Unrecognised message A message that is not specified in clause 7 of this Standard or in any other Standard relating to B-QSIG to which the PINX claims conformance (e.g., a Standard specifying generic procedures for supplementary services). NOTE 4 The handling of national/private messages is outside the scope of this Standard (see annex H).
4.3.36
Unspecified bit rate (UBR) An ATM service category for which no traffic-related service guarantees are specified.
4.3.37
Virtual channel One of a number of multiplexed, bi-directional transfers of digital data provided by the ATM layer across an interface between two ATM switching points.
4.3.38
Virtual channel connection A concatenation of virtual channels that extends between two points where the ATM adaptation layer is accessed. Forward direction
Backward direction
Originating PINX or Incoming Gateway PINX (preceding PINX with respect to the Transit PINX)
Transit PINX (succeeding PINX with respect to the Originating or Incoming Gateway PINX) (preceding PINX with respect to the Terminating or Outgoing Gateway PINX)
Inter-PINX Link
Preceding Side
Terminating PINX or Outgoing Gateway PINX (succeeding PINX with respect to the Transit PINX)
Inter-PINX Link
Succeeding Side
Preceding Side
Succeeding Side
Figure 1 - Illustration of terminology through example of a call/connection routed over two inter-PINX links
5
List of acronyms Abbreviations contained in section 2.1 of ATM Forum’s PNNI 1.0 are applicable with the following additions and/or replacements: ATC
ATM transfer capability
B-BC
Broadband bearer capability
B-HLI
Broadband high layer information
B-ISDN
Broadband ISDN
B-LLI
Broadband low layer information
B-PISN
Broadband PISN
BCOB
Broadband Connection Orientated Bearer class
CCH
Call/connection handling
CPCS
Common Part Convergence Sublayer (of AAL)
DSS2
Digital Subscriber Signalling System Number 2
DTL
designated transit list
- 7 -
6
IE
Information Element
IPL
Inter-PINX Link
IPVC
Inter-PINX Virtual Channel
IPVCI
Inter-PINX Virtual Channel Identifier
IPVP
Inter-PINX Virtual Path
IPVPI
Inter-PINX Virtual Path Identifier
ISDN
Integrated Services Digital Network
MP
Mapping (functional grouping)
N-ISDN
Narrow-band ISDN
N-PISN
Narrow-band PISN
N-BC
Narrow-band bearer capability
N-HLC
Narrow-band high layer compatibility
N-LLC
Narrow-band low layer compatibility
OAM
Operations, Administration and Maintenance
PICS
Protocol Implementation Conformance Statement
PINX
Private Integrated Services Network Exchange
PISN
Private Integrated Services Network
PSS1
Private Signalling System Number 1
QOS
Quality Of Service
SDL
Specification and Description Language
SDU
Service Data Unit
General Principles This Standard specifies the layer 3 signalling procedures operating within the control plane for establishing, maintaining and clearing a broadband basic call/connection across an inter-PINX link (IPL). These signalling procedures are defined in terms of messages exchanged over a Signalling ATM Adaptation Layer (SAAL) connection within the signalling inter-PINX virtual channel (IPVC) of the IPL. The result of successful basic call/connection establishment is a virtual channel connection within the user plane for the purpose of user information transfer. This virtual channel connection uses an IPVC other than the signalling IPVC within the Inter-PINX link. Conceptually, an IPL is attached to a PINX at the Q-reference point and comprises a signalling IPVC and one or more user information IPVCs. User information IPVCs are grouped into one or more inter-PINX virtual paths (IPVPs). A user information IPVC is uniquely identified within the context of an IPL by the combination of its inter-PINX virtual path identifier (IPVPI) and its inter-PINX virtual channel identifier (IPVCI). NOTE 5 For example, an IPVP might comprise those IPVCs that share a collective traffic capability through the intervening network. In practice, these IPVCs are provided by an intervening network. The nature of the intervening network and the way it provides IPVCs are outside the scope of this Standard. NOTE 6 Examples of intervening network types include dedicated transmission systems, cross-connect networks and switched networks. Furthermore they can provide constant bit rate connections or ATM switching/cross-connection. The virtual path identity and virtual channel identity that appear in ATM cell headers at the interface between one of the PINXs and the intervening network need not equate to the IPVPI/IPVCI of the corresponding IPVC at the Q reference point.
- 8 -
An example of an IPL comprising a signalling IPVC and a number of user information IPVCs, the latter grouped into two IPVPs, is shown in figure 2. Q
Q IPL
signalling IPVC
user information IPVCs (first IPVP) etc. user information IPVCs (second IPVP) etc.
Figure 2 - Example of IPL provision
6.1
Protocol model Figure 3 shows the relationship, within the control plane, between layer 3 and the adjacent layers. The layer 3 entity within each PINX is known as Protocol Control, and this provides services to Call/Connection Handling (CCH). CCH handles each call/connection in accordance with the role of the PINX for that call/connection (e.g., Originating PINX, Transit PINX). The services of Protocol Control are accessed by means of primitives exchanged across the boundary between CCH and Protocol Control. Protocol Control provides the mapping between these primitives and the messages transferred across the IPL. NOTE 7 CCH corresponds to "Call Control" in PNNI 1.0. In order to transfer messages, Protocol Control uses the services of the Signalling ATM Adaptation Layer (SAAL). The SAAL uses the services of the ATM layer, which in turn uses the services of the physical layer. This Standard specifies the behaviour of Protocol Control. In addition, certain aspects of CCH are specified for various types of PINX: Transit PINX, Originating PINX, Terminating PINX, Incoming Gateway PINX and Outgoing Gateway PINX. The SAAL and ATM layer are outside the scope of this Standard.
- 9 -
PINX
PINX
Call/Connection Handling (CCH)
Call/Connection Handling (CCH)
Layer 3: Protocol Control
Q
Layer 3 protocol
Q
Layer 3: Protocol Control
Inter-PINX Link
SAAL
SAAL
ATM Layer
ATM Layer
Physical Layer
Physical Layer
Physical inter-PINX connection
Figure 3 - Control plane protocol model
6.2
Services provided to CCH Protocol Control provides services to CCH whereby CCH can send information flows to and receive information flows from a peer CCH. A primitive from CCH to Protocol Control of type “request” or “response” normally results in the associated information flow being presented to the peer CCH as a primitive of type “indication” or “confirmation” respectively. The following primitives are used: − SETUP.Request/Indication/Response/Confirmation for the establishment of a call/connection; − MORE_INFORMATION.Request/Indication for requesting more called party number information during call/connection establishment (for support of 64 kbit/s services only); − INFORMATION.Request/Indication for providing more called party number information during call/connection establishment (for support of 64 kbit/s services only); − PROCEED.Request/Indication for indicating that sufficient called party number information has been received and call/connection establishment is proceeding; − ALERTING.Request/Indication for indicating that the called user is being alerted (for support of 64 kbit/s services only); − PROGRESS.Request/Indication for indicating interworking conditions and/or the availability of in-band patterns (for support of 64 kbit/s services only); − REJECT.Request/Indication for the immediate rejection of a call/connection;
- 10 -
− RELEASE.Request/Indication/Response/Confirmation for releasing a call/connection. − NOTIFY.Request/Indication for the delivery of bearer-related notifications. − STATUS.Request for causing the sending of a STATUS message.
6.3
Services required of the SAAL The services required of the SAAL can be defined in terms of the services provided by the SAAL Service Specific Coordination Function specified in ECMA-265. Protocol Control uses the following SAAL services and their associated primitives: − Assured transfer of data (for Protocol Control message transfer), using the AAL-DATA.request/indication primitives; − SAAL connection establishment, using the AAL-ESTABLISH.request/indication/confirm primitives; − SAAL connection release, using the AAL-RELEASE.indication primitive. NOTE 8 Because the SAAL should normally remain established for the lifetime of the IPL, no procedures are specified for layer 3 to request SAAL connection release. Hence the AAL-RELEASE-Request and AAL-RELEASE-Confirmation primitives are not used.
6.4
Protocol Control states Protocol Control procedures for calls/connections and restart are specified in terms of: a) messages which are transferred across the Inter-PINX link; b) primitives to and from the SAAL; c) the primitives to and from CCH at each PINX; d) the information processing and actions that take place within Protocol Control at each PINX; and e) the states that can exist within Protocol Control at each PINX. A state machine is deemed to exist for each call/connection. Two further state machines are deemed to exist for restart initiation and restart response.
6.4.1
Call/connection states Refer to section 6.2.1 of PNNI 1.0 for “ATM point-to-point call states”.
6.4.2 6.4.2.1
Additional call/connection states relating to the provision of N-PISN services Overlap Sending (NN2) This state exists for an outgoing call/connection when the preceding side has received acknowledgement that the succeeding side is able to receive additional called party number information in overlap mode.
6.4.2.2
Overlap Receiving (NN25) This state exists for an incoming call/connection when the succeeding side has sent acknowledgement to the preceding side that it is able to receive additional called party number information in overlap mode.
6.4.3
States for restart initiation The states below are used in association with the global call reference for a side that initiates restart.
6.4.3.1
Null (Rest 0) This state exists when there is no restart transaction initiated by this side and still in progress.
6.4.3.2
Restart Request (Rest 1) This state exists when a restart transaction has been initiated from this side and is still in progress.
6.4.4
States for restart response The states below are used in association with the global call reference for a side that responds to a restart request.
- 11 -
6.4.4.1
Null (Rest 0) This state exists when there is no restart transaction initiated by the other side and still in progress.
6.4.4.2
Restart (Rest 2) This state exists when a restart transaction has been initiated by the other side and is still in progress.
6.5
CCH states at a Transit PINX The states below exist within CCH at a Transit PINX for each individual call/connection. NOTE 9 These states are used in order to specify essential CCH requirements for a Transit PINX. These internal states are a descriptive tool and are not intended to constrain implementations.
6.5.1
TCC_Idle (0) No call/connection exists.
6.5.2
TCC_Incoming_Call_Proceeding (4) This state exists when CCH has determined that it has received all called party number information necessary to effect call/connection establishment and has informed the Preceding PINX, but no response to the request for call/connection establishment has been received from the Succeeding PINX.
6.5.3
TCC_Transit_Call_Proceeding (5) This state exists when CCH has received from the Succeeding PINX a response to the request for call/connection establishment. NOTE 10 In the case of N-PISN services, additional called party number information is no longer awaited from the Preceding PINX, i.e., overlap mode is not used or is complete.
6.5.4
TCC_Call_Alerting (6) This state exists when CCH has received from the Succeeding PINX an indication that the called user is being alerted and has relayed the indication on to the Preceding PINX.
6.5.5
TCC_Call_Active (7) This state exists when CCH has received from the Succeeding PINX and relayed on to the Preceding PINX an indication that the called user has answered the call. NOTE 11 "answered" is the act of the end user accepting the call.
6.5.6
TCC_Await_Incoming_Release (8) This state exists when CCH has initiated call/connection clearing towards the Preceding PINX and is awaiting an acknowledgement.
6.5.7
TCC_Await_Outgoing_Release (9) This state exists when CCH has initiated call/connection clearing towards the Succeeding PINX and is awaiting an acknowledgement.
6.5.8
TCC_Await_Two-Way_Release (10) This state exists when CCH has initiated call/connection clearing towards the Preceding PINX and towards the Succeeding PINX and is awaiting an acknowledgement from each.
6.6 6.6.1
Additional CCH states relating to the provision of N-PISN services at a Transit PINX TCC_Await_Digits (1) This state exists when CCH has received a request for call/connection establishment from the Preceding PINX and is awaiting additional called party number information in order to select a route to the Succeeding PINX.
- 12 -
6.6.2
TCC_Await_Additional_Digits (2) This state exists when CCH has sent a request for call/connection establishment to the Succeeding PINX and is awaiting possible additional called party number information from the Preceding PINX.
6.6.3
TCC_Overlap (3) This state exists when CCH is awaiting possible additional called party number information from the Preceding PINX, having received acknowledgement that the Succeeding PINX is able to receive additional called party number information in overlap mode.
7
Message functional definitions and content Refer to section 6.3 (excluding its subsections) of PNNI 1.0. The following modifications apply: 1. For each codeset 0 information element, either the subclause of this Standard or the subsection of PNNI describing the information element is indicated. 2. The definitions of "incoming call/connection", "outgoing call/connection", "preceding side" and "succeeding side" in 4.3 of this Standard apply. NOTE 12 All messages may contain information elements from codesets 4, 5, 6 and 7 and corresponding Broadband locking shift and Broadband non-locking shift information elements which comply with the coding rules specified in 8.5.2 to 8.5.4. None of these information elements, however, are listed in this clause.
7.1
Messages for B-QSIG call/ connection control Table 6-1 in 6.3.1 of PNNI 1.0 summarises the messages for ATM point-to-point call/connection control. In addition, the message shown in table 2 applies. Table 2 - Additional message for ATM point-to-point call/connection control Message
Reference
Call establishment messages: PROGRESS
7.1.1
7.1.8
ALERTING Refer to section 6.3.1.1 of PNNI 1.0. The following modifications apply: 1. The Notification indicator information element may be repeated. The maximum number of occurrences is implementation dependent. 2. The additional content specified in table 3 applies. Table 3 - Additional ALERTING message content
7.1.2
Information element
Reference
Type
Length
Progress indicator
8.5.33
O
6
CALL PROCEEDING Refer to section 6.3.1.2 of PNNI 1.0.
7.1.3
CONNECT Refer to section 6.3.1.3 of PNNI 1.0. The following modifications apply: 1. The Notification indicator information element may be repeated. The maximum number of occurrences is implementation dependent. 2. The additional content specified in table 4 applies.
- 13 -
Table 4 - Additional CONNECT message content
7.1.4
Information element
Reference
Type
Length
OAM traffic descriptor
8.5.32
O
6
Progress indicator
8.5.33
O
6
RELEASE Refer to section 6.3.1.4 of PNNI 1.0. The following modifications apply: 1. The Notification indicator information element may be repeated. The maximum number of occurrences is implementation dependent. 2. The Crankback information element is not applicable.
7.1.5
RELEASE COMPLETE Refer to section 6.3.1.5 of PNNI 1.0. The following modification applies: 1. The Crankback information element is not applicable.
7.1.6
SETUP Refer to section 6.3.1.6 of PNNI 1.0. The following modifications apply: 1. The Notification indicator information element may be repeated. The maximum number of occurrences is implementation dependent. 2. The Designated transit list information element is not applicable. 3. The Connection identifier information element may be omitted only if the side sending the message is configured as the non-selecting side of the IPL. 4. The additional content specified in table 5 applies. Table 5 - Additional SETUP message content Information element
Reference
Type
Length
Broadband sending complete
8.5.14
O
5 (NOTE)
OAM traffic descriptor
8.5.32
O
6
Progress indicator
8.5.33
O
6
NOTE: The Broadband sending complete information element is mandatory in the case of a B-PISN-specific service (i.e.., not a 64 kbit/s-based PISN service).
7.1.7
NOTIFY Refer to section 6.3.1.9 of PNNI 1.0. The following modification applies: 1. The Notification indicator information element may be repeated. The maximum number of occurrences is implementation dependent.
7.1.8
PROGRESS See table 6. This message is sent by the succeeding side to indicate the progress of a call/connection in the event of interworking or by either side in the call/connection with the provision of optional in-band information/patterns.
- 14 -
Table 6 - PROGRESS message content Message type: PROGRESS Direction: both Significance: Global Information element
Reference
Type
Length
Protocol discriminator
6.4.2 of PNNI 1.0
M
1
Call reference
6.4.3 of PNNI 1.0
M
4
Message type
6.4.4.1 of PNNI 1.0
M
2
Message length
6.4.4.2 of PNNI 1.0
M
2
Cause
6.4.5.19 of PNNI 1.0
O (NOTE 3)
6-34
Notification indicator
6.4.5.27 of PNNI 1.0
O (NOTE 1)
5-*
Progress Indicator
8.5.33
M (NOTE 2)
6
NOTE 1: This information element may be present in order to deliver a notification. The Notification indicator information element may be repeated in a message. The maximum number of occurrences is implementation dependent. NOTE 2: This information element may occur up to three times. NOTE 3: Included if a call/connection failure has to be reported and inband tones/announcements are provided.
7.2
Additional or modified messages related to the support of 64 kbit/s based PISN circuit-mode services Table 6-2 in 6.3.2 of PNNI 1.0 summarises the messages for ATM point-to-point call/connection control for the support of 64 kbit/s based PISN circuit-mode services. In addition, the messages shown in table 7 apply. Table 7 - Additional messages for the support of 64 kbit/s-based PISN circuit-mode services Message
Reference
Call establishment messages: SETUP ACKNOWLEDGE
7.2.7
Miscellaneous messages: INFORMATION
7.2.1
7.2.6
ALERTING Refer to section 6.3.2.1 of PNNI 1.0. The following modifications apply: 1. The modifications specified in 7.1.1 of this Standard apply.
- 15 -
2. The Progress indicator information element may be repeated. The maximum number of occurrences is 3. 7.2.2
CONNECT Refer to section 6.3.2.2 of PNNI 1.0. The following modifications apply: 1. The modifications specified in 7.1.3 of this Standard apply. 2. The Progress indicator information element may be repeated. The maximum number of occurrences is 3.
7.2.3
PROGRESS This message is as specified in 7.1.8 with the additional content specified in table 8. Table 8 - Additional PROGRESS message content
7.2.4
Information element
Reference
Type
Length
Narrow-band bearer capability
6.4.7.1 of PNNI 1.0
O
4-14
Narrow-band high layer compatibility
6.4.7.2 of PNNI 1.0
O
4-7
RELEASE Refer to section 6.3.2.4 of PNNI 1.0. The following modifications apply: 1. The modifications specified in 7.1.4 of this Standard apply. 2. The additional content specified in table 9 applies. Table 9 - Additional PROGRESS message content Information element
Reference
Type
Length
Progress indicator
8.5.33
O
6 (NOTE)
NOTE: The Progress indicator information element may be repeated. The maximum number of occurrences is 3.
7.2.5
SETUP Refer to section 6.3.2.5 of PNNI 1.0. The following modifications apply: 1. The modifications specified in 7.1.6 of this Standard apply. 2. The Progress indicator information element may be repeated. The maximum number of occurrences is 3. 3. The Broadband sending complete information element is optional. 4. The maximum number of occurrences of the Narrow-band high layer compatibility information element is 2. 5. The maximum number of occurrences of the Narrow-band low layer compatibility information element is 4.
7.2.6
INFORMATION See table 10. This message is sent by the preceding side to provide additional information during call/connection establishment (in case of overlap sending).
- 16 -
Table 10 - INFORMATION message content Message type: INFORMATION Direction: preceding to succeeding Information element
Reference
Type
Length
Protocol discriminator
8.2
M
1
Call reference
8.3
M
4
Message type
8.4
M
2
Message length
8.4
M
2
Broadband sending complete
8.5.14
O (NOTE)
4-5
Called party number
8.5.16
O (NOTE)
4-*
NOTE: Either the information element Broadband sending complete or the information element Called party number or both shall be present.
7.2.7
SETUP ACKNOWLEDGE See table 11. This message is sent by the succeeding side to the preceding side to indicate that call/connection establishment has been initiated, but additional information may be required. Table 11 - SETUP ACKNOWLEDGE message content Message type: SETUP ACKNOWLEDGE Direction: succeeding to preceding Information element
Reference
Type
Length
Protocol discriminator
8.2
M
1
Call reference
8.3
M
4
Message type
8.4
M
2
Message length
8.4
M
2
Connection Identifier
8.5.23
O (NOTE)
4-9
NOTE: This information element shall be included except where the Connection identifier information element in the SETUP message indicated “Exclusive IPVPI; exclusive IPVCI“, in which case it shall be omitted.
7.3
Messages for point-to-multipoint call/connection control Additional messages for point-to-multipoint call/connection control are summarised in table 6-4 in 6.3.4 of PNNI 1.0.
7.3.1
ADD PARTY Refer to section 6.3.4.1 of PNNI 1.0. The following modifications apply: 1. The Notification indicator information element may be repeated. The maximum number of occurrences is implementation dependent.
- 17 -
2. The Designated transit list information element is not applicable. 3. The additional content specified in table 12 applies. Table 12 - Additional ADD PARTY message content
7.3.2
Information element
Reference
Type
Length
Progress indicator
8.5.33
O
6
ADD PARTY ACKNOWLEDGE Refer to section 6.3.4.2 of PNNI 1.0. The following modifications apply: 1. The Notification indicator information element may be repeated. The maximum number of occurrences is implementation dependent. 2. The additional content specified in table 13 applies. Table 13 - Additional ADD PARTY ACKNOWLEDGE message content
7.3.3
Information element
Reference
Type
Length
Progress indicator
8.5.33
O
6
PARTY ALERTING Refer to section 6.3.4.3 of PNNI 1.0. The following modifications apply: 1. The Notification indicator information element may be repeated. The maximum number of occurrences is implementation dependent. 2. The additional content specified in table 14 applies. Table 14 - Additional PARTY ALERTING message content
7.3.4
Information element
Reference
Type
Length
Progress indicator
8.5.33
O
6
ADD PARTY REJECT Refer to section 6.3.4.4 of PNNI 1.0. The following modification applies: 1. The Crankback information element is not applicable.
7.3.5
DROP PARTY Refer to section 6.3.4.5 of PNNI 1.0. The following modification applies: 1. The Notification indicator information element may be repeated. The maximum number of occurrences is implementation dependent.
7.3.6
DROP PARTY ACKNOWLEDGE Refer to section 6.3.4.6 of PNNI 1.0.
7.4
Messages used with the global call reference Refer to section 6.3.3 of PNNI 1.0.
8
General message format and information elements coding Refer to section 6.4 of PNNI 1.0.
8.1
Overview Refer to section 6.4.1 of PNNI 1.0.
- 18 -
8.2
Protocol discriminator Refer to section 6.4.2 of PNNI 1.0.
8.3
Call reference Refer to section 6.4.3 of PNNI 1.0.
8.4 8.4.1
Message type, and message length Message type Refer to section 6.4.4.1 of PNNI 1.0. The following additional message types that are specified in 4.4.1 of Q.2931 but are not supported in PNNI 1.0 are supported in this Standard: SETUP ACKNOWLEDGE INFORMATION Escape to national or private specific message types is supported.
8.4.2
Message length Refer to section 6.4.4.2 of PNNI 1.0.
8.5 8.5.1
Variable length information elements for B-ISDN environment Coding rules Refer to section 6.4.5.1 of PNNI 1.0 with the following changes: The value "1111 1111" for the information element identifier is reserved for an extension mechanism, when all other information element identifier values are exhausted. This mechanism allows 65 536 additional information elements to be identified. The information elements applicable to this Standard are as shown in table 6-5 in 6.4.5.1 of PNNI 1.0 with the following modifications: 1. The maximum number of occurrences of a given information element in a message is message-dependent, as indicated in clause 7. 2. Additional information elements as specified in table 15 apply. Table 15 - Additional information elements Bits
Information element
Max. Length
0101 1011
OAM traffic descriptor
6
0110 0010
Broadband sending complete
5
8765 4321
8.5.2
Extensions of codesets Refer to section 4.5.2 of ITU-T recommendation Q.2931. The following modifications apply: 1. "User or network equipment" shall be interpreted as "PINX". 2. Codeset 5 is outside the scope of this Standard. 3. Codeset 6 and/or codeset 7 may be used for conveying non-standardized information between adjacent PINXs (e.g. for manufacturer or network specific purposes, see annex H). 4. Information elements from codesets other than codeset 0 shall be handled according to the procedures for unrecognised information elements (see 6.5.6.8.1 of PNNI 1.0) unless recognised as relating to a future standardized or non-standardized capability.
8.5.3
Broadband-locking shift procedure Refer to section 4.5.3 of ITU-T recommendation Q.2931. The following modifications apply: 1. Bit 4 of octet 2 shall have the meaning "pass along request".
- 19 -
2. The New Codeset Identification field (bits 3 to 1 of octet 5) shall be encoded in accordance with table 16. Table 16 - Broadband-locking shift information element - New Codeset identification (octet 5): Bits 3 2 1 0 0 0 not applicable 0 0 1) to } reserved for future ITU-T use 0 1 1) 1 0 0 codeset 4: reserved for use by ISO/IEC standards 1 0 1 codeset 5: outside the scope of this Standard 1 1 0 codeset 6: information elements for conveying non-standardized information 1 1 1 codeset 7: information elements for conveying non-standardized information
8.5.4
Broadband-non-locking shift procedure Refer to section 4.5.4 of ITU-T recommendation Q.2931. The following modifications apply: 1. Bit 4 of octet 2 shall have the meaning "pass along request". 2. The New Codeset Identification field (bits 3 to 1 of octet 5) shall be encoded in accordance with table 16.
8.5.5
ABR additional parameters Refer to section 6.4.5.5 of PNNI 1.0.
8.5.6
ABR setup parameters Refer to section 6.4.5.6 of PNNI 1.0.
8.5.7
Alternative ATM traffic descriptor Refer to section 6.4.5.7 of PNNI 1.0.
8.5.8
ATM adaptation layer parameters Refer to section 6.4.5.8 of PNNI 1.0.
8.5.9
ATM traffic descriptor Refer to section 6.4.5.9 of PNNI 1.0.
8.5.10
Broadband bearer capability Refer to section 6.4.5.10 of PNNI 1.0.
8.5.11
Broadband high layer information (B-HLI) Refer to section 6.4.5.11 of PNNI 1.0.
8.5.12
Broadband low layer information (B-LLI) Refer to section 6.4.5.12 of PNNI 1.0.
8.5.13
Broadband repeat indicator Refer to section 6.4.5.13 of PNNI 1.0.
8.5.14
Broadband sending complete Refer to section 4.5.21 of ITU-T Recommendation Q.2931. The following modification applies: 1. The statement concerning the mandatory nature of this information element when operating in en bloc mode does not apply. 2. Bit 4 of octet 2 shall have the meaning "pass along request".
- 20 -
8.5.15
Call state Refer to section 6.4.5.14 of PNNI 1.0 with the additional call state values in table 17: Table 17 - Call state information element
- Call/connection state value (octet 5) Bits 6 5 4 3 2 1 state 0 0 0 0 1 0 2 - Overlap sending 0 1 1 0 0 1 25 - Overlap receiving
8.5.16
Called party number Refer to subclause 4.5.11 of ITU-T recommendation Q.2931. The following modifications apply: 1. Bit 4 of octet 2 shall have the meaning "pass along request". 2. If the use of ATM endsystem address encoded as NSAP address is not indicated in the addressing / numbering plan identification, the address/number digits appear in octet 6 and note 1 of the referenced subclause applies. 3. If the use of ATM endsystem address encoded as NSAP address is indicated in the addressing / numbering plan identification, the NSAP address octets appear in octet 6 and note 2 of the referenced subclause applies. 4. Only the type of number / numbering plan identification combinations shown in table 18 shall be used.
- 21 -
Table 18 - Called party number information element - Type of number (octet 5): Bits ISDN numbering plan 7 6 5 0 0 0 unknown (Note 2) 0 0 1 international number (Note 1, Note 3) 0 1 0 national number (Note 1, Note 3) 0 1 1 reserved 1 0 0 subscriber number (Note 1, Note 3) 1 1 0 reserved 1 1 1 reserved for extension All other values are reserved.
Private numbering plan unknown (Note 2) level 2 regional number (Note 3) level 1 regional number (Note 3) B-PISN specific number level 0 regional number (Note 3) reserved reserved for extension
ATM endsystem address unknown (Note 2) reserved reserved reserved reserved reserved reserved
unknown numbering plan unknown (Note2) reserved reserved reserved reserved reserved reserved
Note 1 - For the definition of international, national and subscriber number, see Recommendation I.330. Note 2 - The type of number "unknown" is used when ATM endsystem addressing or “unknown“ is indicated in the addressing / numbering plan identification field or when the type of number is implicit in the address / number digits, e.g. through the use of prefix or escape digits Note 3 - Prefix digits shall not be included. - Addressing / numbering plan identification (octet 5) : Bits 4 3 2 1 0 0 0 0 unknown (Note 1,2) 0 0 0 1 ISDN numbering plan (Recommendation E.164) 0 0 1 0 ATM endsystem address encoded as NSAP address (ISO/IEC 8348) (Note 3) 1 0 0 1 private numbering plan (ISO/IEC 11571) (Note 2) 1 1 1 1 reserved for extension All other values are reserved. Note 1 - The numbering plan identification "unknown" indicates the numbering plan identity is implicit in the address / number digits, e.g., through the use of prefix or escape digits. Note 2 - The use of this codepoint is a network option and requires bilateral agreement. Note 3 - If this codepoint is used, the type of number is coded as "unknown". - Address / number digits (octets 6, etc., unless ATM endsystem addressing): This field is coded with IA5 characters, according to the formats specified in the appropriate numbering/dialling plan. - NSAP Address Octets (octets 6, etc. for NSAP addressing): If the use of ATM endsystem address encoded as NSAP address is indicated in the addressing / numbering plan identification, the address is coded as described in ISO/IEC 8348 annex A. Any AFI value that denotes binary encoding may be used.
8.5.17
Called party subaddress Refer to section 6.4.5.16 of PNNI 1.0.
8.5.18
Calling party number Refer to subclause 4.5.13 of ITU-T recommendation Q.2931. The following modifications apply: 1. Bit 4 of octet 2 shall have the meaning "pass along request". 2. Octets 5 (but not 5a) and 6 shall be coded as specified for the Called party number information element in 8.5.16 of this Standard.
8.5.19
Calling party subaddress Refer to section 6.4.5.18 of PNNI 1.0.
8.5.20
Cause Refer to section 6.4.5.19 of PNNI 1.0.
- 22 -
8.5.21
Connected number Refer to section 6.4.5.20 of PNNI 1.0. The following modification applies. 1. Octets 5 (but not 5a) and 6 shall be coded as specified for the Called party number information element in 8.5.16 of this Standard.
8.5.22
Connected subaddress Refer to section 6.4.5.21 of PNNI 1.0.
8.5.23
Connection identifier Refer to section 6.4.5.22 of PNNI 1.0. The following modifications apply: The overall range of IPVCI values is 0 to 65535. The range of IPVPI and IPVCI values available on an individual IPL will be determined at IPL establishment time.
8.5.24
Connection scope selection Refer to section 6.4.5.23 of PNNI 1.0.
8.5.25
End-to-end transit delay Refer to section 6.4.5.24 of PNNI 1.0.
8.5.26
Extended Quality of service (QOS) parameter Refer to section 6.4.5.25 of PNNI 1.0.
8.5.27
Minimum acceptable ATM traffic descriptor Refer to section 6.4.5.26 of PNNI 1.0.
8.5.28
Notification indicator Refer to section 6.4.5.27 of PNNI 1.0 with the following changes as shown in figure 4: Bits 8
7 6 5 4 3 2 Further contents as defined in other standards
1
Octets 5
Figure 4 - Notification indicator information element
8.5.29
Quality of service (QOS) parameter Refer to section 6.4.5.28 of PNNI 1.0.
8.5.30
Restart indicator Refer to 4.5.20 of ITU-T recommendation Q.2931. The following modifications apply: 1. Bit 4 of octet 2 shall have the meaning "pass along request". 2. Table 4-20/Q.2931 is replaced by table 19 below.
- 23 -
Table 19 - Restart indicator information element - Class (octet 5) Bits 3 2 1 0 0 0 Indicated IPVC (Note 1) 0 0 1 All IPVCs in the indicated IPVP (Note 2) 0 1 0 All IPVCs controlled by the signalling IPVC (Note 3) All other values are reserved. Note 1: The Connection identifier IE shall be included and shall indicate the IPVC to be restarted. Note 2: The Connection identifier IE shall be included and shall indicate the IPVP in which all IPVCs are to be restarted. The IPVCI field in the Connection identifier information element is ignored. Note 3: The Connection identifier IE shall not be included.
8.5.31
Transit network selection Refer to section 6.4.5.30 of PNNI 1.0.
8.5.32
OAM traffic descriptor Refer to section 4.5.24 of ITU-T Recommendation Q.2931. NOTE 13 The encoding of this information element is not specified in this Standard for it is defined as transparent to this protocol, except for the shaping indicator field (octet 5).
8.5.33
Progress indicator Refer to 8.5.32 of PNNI 1.0. The following modification applies: 1. Octets 5 onwards shall be encoded as specified in ECMA-143, subject to the restrictions given in table 20. Table 20 - Progress indicator information element
Coding standard (octet 5): Only the following coding is applicable. Bits 7 6 0 1 ISO/IEC standard all other values reserved Progress description (octet 6): Only the following coding is applicable. Bits 7 6 5 4 3 2 1 0 0 1 0 0 0 0 0 0 1 1 0 0 1
8.5.34
No 16 21
Interworking with public network Delayed call completion
Calling party soft PVPC or PVCC Refer to section 6.4.6.1 of PNNI 1.0.
8.5.35
Called party soft PVPC or PVCC Refer to section 6.4.6.2 of PNNI 1.0.
8.6 8.6.1
Information Elements for the support of 64 kbit/s based ISDN circuit mode services Narrow-band bearer capability Refer to section 6.4.7.1 of PNNI 1.0 with the following changes as shown in figure 5:
- 24 -
Bits 8 7 6 5 4 3 2 1 Further contents as specified for octet three onwards of the Bearer capability information element in ECMA-143
Octets 5-
Figure 5 - Narrow-band bearer capability information element
8.6.2
Narrow-band high layer compatibility Refer to section 6.4.7.1 of PNNI 1.0.
8.6.3
Narrow-band low layer compatibility Refer to section 6.4.7.3 of PNNI 1.0.
8.6.4
Progress indicator Refer to section 8.5.32 of PNNI 1.0 specification. The following modification applies: 1. Additional combinations of Coding Standard values and Progress Descriptions values apply, as specified for octets 3 and 4 of the Progress indicator information element in ECMA-143.
8.7
Information Elements for Point-to-Multipoint Call/connection control Refer to 6.4.8 of PNNI 1.0.
9
Protocol control procedures for B-QSIG point-to-point calls/connections This clause describes the general procedures for protocol control on either side of an IPL. Clause 11 specifies the particular features required to provide 64 kbit/s based circuit-mode ISDN services in B-PISN and to support signalling interworking between B-PISN and N-PISN or N-ISDN. These procedures apply to a signalling IPVC that has already been established and are used to control B-PISN connections on the IPL concerned. Different connections controlled by the same signalling IPVC are distinguished through different call reference values. The call/connection states referred to in this clause are those perceived by the Protocol Control entity in a PINX at either side of the IPL. Detailed Specification and Description Language (SDL) diagrams for the procedures specified in this clause are contained in annex D. When there is an ambiguity in the text, the SDL diagrams should be used to resolve the conflict. Where the text and the SDL are in disagreement, the text should be used as the prime source.
9.1
Establishment of a signalling AAL Before these procedures are invoked, an assured mode signalling AAL connection must be established between the PINXs at either side of the IPL. All layer 3 messages shall be sent to the signalling AAL using the AAL-DATA.request primitive and received from the signalling AAL using the AAL-DATA.indication primitive. Establishment of Signalling AAL connections is initiated as part of IPL establishment by transferring an AALESTABLISH.request primitive to the signalling AAL. On receipt of an AAL-ESTABLISH.confirm or AAL-ESTABLISH.indication primitive from the SAAL, inter-PINX signalling procedures may begin. The AAL-ESTABLISH.indication primitive will be received in the case of signalling AAL establishment requested by the peer Protocol Control entity, and the AAL-ESTABLISH.confirm primitive will be received in response to a local request to establish a signalling AAL connection.
9.2
Call/Connection establishment Refer to section 6.5.2 (and its subsections) of PNNI 1.0. The following modifications apply: 1. The statement in 6.5.2.2 concerning the use of VPI=0/VCI=5 as the signalling virtual channel for use with nonassociated signalling does not apply. The allocation of a signalling virtual channel is outside the scope of this Standard. 2. Subsection 6.5.2.2.3 of PNNI 1.0 is not applicable.
- 25 -
3. The following mechanism replaces the use of node identifiers in 6.5.2.2.1, 6.5.2.2.2.1 and 6.5.2.2.2.2 of PNNI 1.0 as a means of avoiding call/connection collisions. The two sides of an IPL may optionally be configured so that a single side is responsible for IPVPI/IPVCI selection for all call/connections in either direction. In this case, the side responsible for IPVCI selection is known as the selecting side and the other side is known as the non-selecting side. The selecting side shall use case b) of 6.5.2.2.1, case b) of 6.5.2.2.2.1 or case d) of 6.5.2.2.2.2 of PNNI 1.0 when transmitting a SETUP message. A non-selecting side shall use case a) of 6.5.2.2.1, case a) or case c) of 6.5.2.2.2.1 or case c) of 6.5.2.2.2.2 of PNNI 1.0 when transmitting a SETUP message. NOTE 14 Call/connection collisions can still occur if the optional configuration of a selecting side and a non-selecting side is not employed or in the case of misconfiguration. 4. All references to the Crankback information element are not applicable.. 5. The procedures in 9.2.1 below for the handling of the PROGRESS message apply. 6. The procedures in 9.2.2 below for the call/connection failure replace the procedures of 6.5.2.7 of PNNI 1.0. 9.2.1
Handling of a PROGRESS message During state Incoming Call Proceeding or Call Received, in order to send a progress description in a Progress indicator information element when no ALERTING or CONNECT message is to be sent at the same time, the succeeding side may send a PROGRESS message. No state change shall occur on sending a PROGRESS message. On receipt of a PROGRESS message during state Outgoing Call Proceeding or Call Delivered, no state change shall occur. If the Progress indicator information element in the PROGRESS message contains progress description 21 and timer T310 is running (state Outgoing Call Proceeding only), timer T310 shall be stopped.
9.2.2
Call/connection failure If the succeeding side determines that the call/connection cannot proceed, then the succeeding side shall initiate call/connection clearing in accordance with 9.3. The following are examples of causes that can be used: #1
"unassigned (unallocated) number";
#3
"no route to destination";
#17
"user busy";
#18
"no user responding";
#19
"no answer from user";
#21
"call rejected";
#22
"number changed";
#28
"invalid number format (address incomplete)";
#47
"resources unavailable, unspecified" (e.g., unable to provide the indicated peak cell rate);
#49
"quality of service not available" (e.g., unable to provide the requested QOS class or unable to accept the requested maximum transit delay);
#57
"bearer capability not authorised";
#58
"bearer capability not presently available";
#63
"service or option not available, unspecified";
#65
"bearer service not implemented".
In particular the succeeding side shall initiate call/connection clearing with cause #65 "bearer service not implemented" if the Broadband bearer capability information element in the SETUP message contains a value that is not specified in 8.5.10 or is not implemented in any of the following fields: − Bearer class;
- 26 -
− ATM transfer capability; − Susceptibility to clipping; − User plane connection configuration.
9.3
Call/Connection clearing Refer to section 6.5.3 of PNNI 1.0. The following modification applies: 1. Crankback does not apply.
9.4
Call/connection collisions Refer to section 6.5.4 of PNNI 1.0. The following modification applies: 1. The Crankback information element does not apply.
9.5
Restart procedure Refer to section 6.5.5 of PNNI 1.0.
9.6
Handling of error conditions Refer to section 6.5.6 of PNNI 1.0. The following modifications apply: 1. Information element error procedures may also apply to information elements in codesets other than 0. In that case, the diagnostics in the Cause information element may indicate information elements other than those in codeset 0 by applying the locking or non-locking shift procedures as described in 8.5. 2. The last two paragraphs of 6.5.6.8.1 of PNNI 1.0 relating to the Broadband-locking shift IE and Broadband-nonlocking shift information elements are not applicable for B-QSIG. 3. The procedures of 9.6.1 below for sending a STATUS message apply. 4. The procedures of 9.6.2 below for determining state compatibility on receipt of a STATUS message that does not contain the global call reference apply in addition to the procedures of 6.5.6.12 of PNNI 1.0.
9.6.1
Sending a STATUS message In addition to the circumstances specified elsewhere in this Standard for sending a STATUS message, a STATUS message may be sent at any other time to indicate the state associated with a call reference.
9.6.2
Determination of protocol state compatibility on receipt of a STATUS message containing a call reference other than the global call reference On receipt of a STATUS message containing a call reference value other than the global call reference, the receiving entity shall check whether the protocol control state reported in the STATUS message is compatible with the state associated with that call reference internally. Table 21 indicates which protocol control states shall be considered compatible. However, this table does not imply that all other pairs of states are to be considered incompatible.
- 27 -
Table 21 - Compatible protocol control states Internal protocol control state associated with call reference
9.7
Reported protocol control state in STATUS message
NN0 - Null
NN0 - Null
NN1 - Call Initiated
NN6 - Call Present
NN2 - Overlap Sending
NN25 - Overlap Receiving
NN3 - Call Proceeding Sent
NN9 - Call Proceeding Received
NN4 - Alerting Delivered
NN7 - Alerting Received
NN6 - Call Present
NN1 - Call Initiated
NN7 - Alerting Received
NN4 - Alerting Delivered
NN9 - Call Proceeding Received
NN3 - Call Proceeding Sent
NN10 - Active
NN10 - Active
NN11 - Release Request
NN11 - Release Request NN12 - Release Indication
NN12 - Release Indication
NN11 - Release Request
NN25 - Overlap Receiving
NN2 - Overlap Sending
Error procedures with explicit action indication Refer to 6.5.7 of PNNI 1.0.
9.8
Handling of messages with insufficient information Refer to section 6.5.8 of PNNI 1.0.
9.9
Notification procedures Refer to section 6.5.10 of PNNI 1.0.
9.10
Notification of interworking Refer to section 6.5.11 of PNNI 1.0.
9.11
List of Timers Refer to section 6.5.12 of PNNI 1.0. The following clarifications apply: 1. On the first expiry of T303, as an alternative to restarting T303 and retransmitting the SETUP message, this may be treated as the final expiry of T303. 2. T316 is mandatory. 3. T317 is mandatory. The following modifications apply: 1. T310 shall also be stopped on receipt of a PROGRESS message containing progress description 1, 2, 8 or 21. 2. The additional timers in table 22 apply.
- 28 -
Table 22 - Additional protocol timer definitions for the support of 64 kbit/s circuit basic mode services Timer number
Default value
Call state
Cause for start
T302
15 s
Overlap receiving
Sending of On the sending of SETUP ACK. CALL Restarted on PROCEEDING receipt of each INFORMATION message.
Clear call/connection if information is definitely incomplete, else send CALL PROCEEDING
M
T304
30 s
Overlap sending
SETUP ACK Receiving CALL received. PROCEEDING Restarted on sending of each INFORMATION message.
Clear the call/connection
M
10
Cause for normal Action to be taken Implementation stop when timer expires
Call/connection Control Procedures for Point-to-Multipoint Calls Refer to section 6.6 of PNNI 1.0. The following clarification applies: 1. The CONNECT ACK message and the Connect Request state are not applicable. The following modifications apply: 1. Crankback procedures and the Crankback information element are not applicable. 2. Support of point-to-multipoint call/connections is optional. Detailed Specification and Description Language (SDL) diagrams for the procedures specified in this clause are contained in annex K. When there is an ambiguity in the text, the SDL diagrams should be used to resolve the conflict. Where the text and the SDL are in disagreement, the text should be used as the prime source.
11
Procedures for the support of 64kbit/s based circuit mode basic services in B-PISN and interworking between N-PISNs and B-PISNs This clause specifies the particular features required to provide 64 kbit/s based circuit-mode basic services ("N-PISN services") in B-PISNs and to support interworking between B-PISNs and N-PISNs. N-PISN services are the services defined in ECMA-142 and ISO/IEC 11584 and supported by the QSIG (PSS1) signalling protocol specified in ECMA-143. For these services interworking with N-PISNs is possible. NOTE 15 Interworking functions to support packet and frame mode bearer services are not in the scope of this Standard.
11.1
Introduction The procedures defined in this Standard are based on the principle that there is no difference between the provision of N-PISN services in a pure B-PISN environment and the provision of these services in the case of interworking with an N-PISN. Separate service-related information elements are defined for N-PISN services and for B-PISN services. For the provision of N-PISN services, the information elements Narrow-band bearer capability (N-BC), Narrow-band low layer compatibility (N-LLC) and Narrow-band high layer compatibility (N-HLC) are specified in clause 8. Table 23 shows the information elements required for the provision of N-PISN services in B-PISNs.
- 29 -
Table 23 - Information elements to provide N-PISN services Information elements used to describe network relevant bearer attributes
Information elements used to describe lower layer attributes (transparent for the B-PISN)
Information elements used to describe high layer attributes
N-PISN related Narrow-band bearer capability information (N-BC) elements
Narrow-band low layer compatibility (N-LLC)
Narrow-band high layer compatibility (N-HLC)
B-PISN related − Broadband bearer capability information (B-BC) elements − ATM traffic descriptor
− ATM adaptation layer parameters (AAL parameters)
− QOS parameter
_
− OAM traffic descriptor (optional)
− End-to-end transit delay (optional)
11.2 describes the use of N-PISN service-related information elements. 11.3 and 11.4 specify the interworking functions between B-PISNs and N-PISNs.
11.2
Use of information elements for N-PISN services
11.2.1
General aspects When N-PISN services are requested in a B-PISN environment, the information elements defined in 8.5 are used in the same manner as for B-PISN specific services. Additionally, the information elements defined in 8.5.34 are used for the provision of the N-PISN services as described below. The following subclauses (11.2.2 to 11.2.4) only describe the use of the service-related information elements in the SETUP message. However, in the case of service negotiation they may also be included in a suitable response message returned to the call initiating entity.
11.2.2
Bearer service related information The B-BC information element shall always be included in the SETUP message. This information is interpreted by the B-PINX. For N-PISN services, the N-BC information element shall also be included in the SETUP message. Unlike the B-BC information element, however, the N-BC information element need only be interpreted when there is a possibility of providing tones/announcements according to 11.7.1. The coding of the Broadband bearer capability information element shall be as shown in table 24. Table 24 - Coding of the Broadband bearer capability information element
Octet
Information element field
Field value
5
Bearer class
BCOB-A
6
Susceptibility to clipping
susceptible to clipping
User plane connection configuration
point-to-point
The ATM traffic descriptor information element shall always be included in the SETUP message. For N-PISN services, a value for the ATM user cell rate shall be selected such that the bit rate of the N-PISN service (64 kbit/s or n x 64 kbit/s) can be transported as the cell payload of the ATM cells, i.e. excluding the overhead of the ATM cell and the AAL header. When AAL1 is used, the coding of the ATM traffic descriptor information element for N-BC information transfer rate of 64 kbit/s shall be as shown in table 25.
- 30 -
Table 25 - Coding of the ATM traffic descriptor information element for 64 kbit/s using AAL1 Octet
Information element field
Field value if no Field value if 1 OAM cells are used OAM cell/s is used (NOTE 1) (NOTE 2)
Field value with maximal OAM support (NOTE 3)
7.1 7.2 7.3
Forward peak cell rate (CLP=0+1)
0000 0000 0000 0000 1010 1011 (171 cells/s)
0000 0000 0000 0000 1010 1100 (172 cells/s)
0000 0000 0000 0000 1010 1111 (175 cells/s)
8.1 8.2 8.3
Backward peak cell rate (CLP=0+1)
0000 0000 0000 0000 1010 1011 (171 cells/s)
0000 0000 0000 0000 1010 1100 (172 cells/s)
0000 0000 0000 0000 1010 1111 (175 cells/s)
NOTE 1: These values are based on an AAL type 1 payload of 47 octets per cell (i.e. no partially filled cell) for user information and no cell rate allocation for OAM cells. NOTE 2: These values are based on an AAL type 1 payload of 47 octets per cell (i.e. no partially filled cell) for user information and on 1 cell/s allocation for OAM cells. NOTE 3: These values are based on an AAL type 1 payload of 47 octets per cell (i.e. no partially filled cell) for user information and the following cell rate allocation for OAM: two percent of the user cell rate and an additional 1 cell/s. NOTE 4: Octet groups 5, 6 and 9 onwards shall not be used.
When AAL5 is used, the coding of the ATM traffic descriptor information element for N-BC information transfer rate of 64 kbit/s shall be as shown in table 26.
- 31 -
Table 26 - Coding of the ATM traffic descriptor information element for 64 kbit/s using AAL5 Octet
Information element field
Field value if no Field value if 1 OAM cells are used OAM cell/s is used (NOTE 1) (NOTE 2)
Field value with maximal OAM support (NOTE 3)
7.1 7.2 7.3
Forward peak cell rate (CLP=0+1)
0000 0000 0000 0000 1100 1000 (200 cells/s)
0000 0000 0000 0000 1100 1001 (201 cells/s)
0000 0000 0000 0000 1100 1101 (205 cells/s)
8.1 8.2 8.3
Backward peak cell rate (CLP=0+1)
0000 0000 0000 0000 1100 1000 (200 cells/s)
0000 0000 0000 0000 1100 1001 (201 cells/s)
0000 0000 0000 0000 1100 1101 (205 cells/s)
NOTE 1: These values are based on an AAL type 5 payload of 40 octets per cell for user information and no cell rate allocation for OAM cells. For a payload of less than 40 octets, the field value shall be 8000 ÷ payload_length, encoded in binary format. NOTE 2: These values are based on an AAL type 5 payload of 40 octets per cell for user information and on 1 cell/s allocation for OAM cells. For a payload of less than 40 octets, the field value shall be 8000 ÷ payload_length + 1, encoded in binary format. NOTE 3: These values are based on an AAL type 5 payload of 40 octets per cell for user information and the following cell rate allocation for OAM: two percent of the user cell rate and an additional 1 cell/s. For a payload of less than 40 octets, the field value shall be 8000 ÷ payload_length × 1.02 + 1, encoded in binary format. NOTE 4: Octet groups 5, 6 and 9 onwards shall not be used.
When AAL1 is used, coding of the ATM traffic descriptor information element for N-BC information transfer rate of n x 64 kbit/s shall be as shown in table 27. Table 27 - Coding of the ATM traffic descriptor information element for n x 64 kbit/s using AAL1 Octet
Information element field
Field value if no Field value if 1 OAM cells are used OAM cell/s is used
Field value with maximal OAM support
7.1 7.2 7.3
Forward peak cell rate (CLP=0+1)
nx8000/47 rounded up to the next integer value
(nx8000/47) + 1 rounded up to the next integer value
((nx8000/47)x1,02) + 1 rounded up to the next integer value
8.1 8.2 8.3
Backward peak cell rate (CLP=0+1)
nx8000/47 rounded up to the next integer value
(nx8000/47) + 1 rounded up to the next integer value
((nx8000/47)x1,02) + 1 rounded up to the next integer value
When AAL5 is used, coding of the ATM traffic descriptor information element for N-BC information transfer rate of n x 64 kbit/s shall be as shown in table 28.
- 32 -
Table 28 - Coding of the ATM traffic descriptor information element for n x 64 kbit/s using AAL5 Octet
Information element field
Field value if no Field value if 1 OAM cells are used OAM cell/s is used
Field value with maximal OAM support
7.1 7.2 7.3
Forward peak cell rate (CLP=0+1)
nx8000/40 rounded up to the next integer value
(nx8000/40) + 1 rounded up to the next integer value
((nx8000/40)x1,02) + 1 rounded up to the next integer value
8.1 8.2 8.3
Backward peak cell rate (CLP=0+1)
nx8000/40 rounded up to the next integer value
(nx8000/40) + 1 rounded up to the next integer value
((nx8000/40)x1,02) + 1 rounded up to the next integer value
NOTE: For a payload of less than 40 octets, '40' in the above formulae shall be replaced by the payload length
The Quality of service parameter information element shall always be included in the SETUP message, indicating the unspecified QOS class. The coding of the QOS parameter information element shall be as shown in table 29. Table 29 - Coding of the QOS parameter information element Octet
Information element field
Field value
5
QOS-class forward
unspecified QOS class
6
QOS-class backward
unspecified QOS class
The End-to-end transit delay information element may be included in the SETUP message and coded according to 8.5.25. The OAM traffic descriptor information element may be included in the SETUP message and coded according to 8.5.32. 11.2.3
Low layer related information If available, the N-LLC information element shall be included in the SETUP message. The rules for the use of low layer related information are outside the scope of this Standard. No B-LLI information element shall be included. The ATM adaptation layer parameters information element shall be included in the SETUP message, specifying the AAL type to be used. The coding of the AAL parameters information element for 64 kbit/s unrestricted digital information and 64 kbit/s restricted digital information using AAL1 shall be as shown in table 30.
- 33 -
Table 30 - Coding of the AAL parameters information element for 64 kbit/s unrestricted digital information and 64 kbit/s restricted digital information Octet
Information element field
Field value
5
AAL-Type
0000 0001
(AAL Type 1)
6.1
Subtype
0000 0010
(circuit transport)
7.1
CBR Rate
0000 0001
(64 kbit/s)
9.1
Source Clock Frequency
0000 0000
(Null) (NOTE)
10.1
Error Correction method
0000 0000
(Null) (NOTE)
NOTE: These fields may also be absent.
The coding of the AAL parameters information element for speech and 3,1 kHz audio information transfer capabilities using AAL1 shall be as shown in table 31. Table 31 - Coding of the AAL parameters information element for speech and 3,1 kHz audio information transfer capabilities Octet
Information element field
Field value
5
AAL-Type
0000 0000
(AAL for voice) (NOTE)
NOTE: AAL for voice is a simplified AAL type 1, where synchronous circuit transport (no SRTS), no SDT pointer, no error correction method, and no partially filled cells method are used (see ITU-T Recommendation I.363).
The coding of the AAL parameters information element for n x 64 kbit/s information transfer rate using AAL1 shall be as shown in table 32. Table 32 - Coding of the AAL parameters information element for n x 64 kbit/s Octet
Information element field
Field value
5
AAL-Type
0000 0001
(AAL Type 1)
6.1
Subtype
0000 0010
(circuit transport)
7.1
CBR Rate
0100 0000
(nx64 kbit/s)
8.1, 8.2
Multiplier
xxxx xxxx xxxx xxxx
9.1
Source Clock Frequency
0000 0000
(Null) (NOTE)
10.1
Error Correction method
0000 0000
(Null) (NOTE)
NOTE: These fields may also be absent.
(2 ... 65.535)
- 34 -
The coding of the AAL parameters information element when using AAL5 shall be as shown in table 33. Table 33 - Coding of the AAL parameters information element for n x 64 kbit/s Octet
Information element field
Field value
5
AAL-Type
0000 0101
6.1 6.2
Forward maximum CPCS-SDU size
Any value in the range 1 to 40, encoded in binary format
7.1 7.2
Backward maximum CPCS-SDU size Any value in the range 1 to 40, encoded in binary format
8 8.1
SSCS-type
11.2.4
(AAL Type 5)
Absent (preferred) or 0000 0000 null
Higher layer related information If available, the N-HLC information element shall be included in the SETUP message. The rules for the use of higher layer related information are outside the scope of this Standard. No B-HLI information element shall be included.
11.2.5
Handling of inconsistent combination of service parameters If the PINX detects an inconsistent combination of broadband and narrow-band service parameters, it may clear the call with cause No. 63 Service or option not available, unspecified.
11.3
Interworking PINX procedures for the succeeding side This subclause specifies the protocol control functions to be performed by an Interworking PINX in the case of a call originated in an N-PISN. Examples of the mapping of codepoints are given in annex C.
11.3.1
Mapping of service related information The information elements Bearer capability, Low Layer Compatibility, if present, and High Layer Compatibility, if present, shall be mapped to the information elements N-BC, N-LLC and N-HLC, respectively, such that octets 3 onwards of the former are equal to octets 5 onwards of the latter. The Flag bit in the second octet shall be set to "0", i.e. the normal error handling procedures as defined in 9.6 apply. In addition to the N-BC information element, the B-BC information element shall be generated by the Interworking PINX. The ATM traffic descriptor and the QOS parameter information elements shall also be generated by the Interworking PINX. The End-to-end transit delay information element and the OAM traffic descriptor information element may be generated. The AAL parameters information element shall be generated by the Interworking PINX, indicating the AAL-type used. An N-PISN service-related information element received in a backward message shall be mapped according to 11.4.2.
11.3.2
Mapping of cause information A Cause information element received from the N-PISN shall be mapped to the corresponding Cause information element by the Interworking PINX such that octets 5 onwards are equal to octets 3 onwards of the N-PISN information element. The Flag bit in the second octet shall be set to "0", i.e. the normal error handling procedures as defined in 9.6 apply. A Cause information element received from the B-PISN shall be mapped according to 11.4.3.
- 35 -
11.4
Interworking PINX procedures for the preceding side This subclause specifies the protocol control functions to be performed by an Interworking PINX in the case of a call leaving the B-PISN towards an N-PISN.
11.4.1
General aspects If a B-PISN specific service is selected for a call to be routed towards an N-PISN, then the call shall be rejected by the Interworking PINX with cause No. 63 Service or option not available, unspecified.
11.4.2
Mapping of service related information The B-BC, the ATM traffic descriptor, the QOS parameter, the End-to-end transit delay and the OAM traffic descriptor information elements shall be discarded by the Interworking PINX. The information elements N-BC, N-LLC, if present, and N-HLC, if present, shall be mapped to the corresponding N-PISN information elements such that octets 3 onwards of the latter are equal to octets 5 onwards of the former. If no N-BC information element is included in the SETUP message, then a B-PISN service shall be assumed and the call shall be rejected according to 11.4.1. The AAL parameter information element shall be discarded by the Interworking PINX. An N-PISN service-related information element received in a backward message shall be mapped according to 11.3.1.
11.4.3
Mapping of cause information For the mapping of the B-PISN Cause information element to the corresponding QSIG Cause information element the following rules shall apply. a) Any broadband specific cause value where there is no equivalent value in the QSIG protocol shall be mapped to the unspecified value of the same class, e.g. the B-PISN cause values: − Requested VPCI/VCI not available − VPCI/VCI assignment failure − User cell rate not available and − No VPCI/VCI available − are mapped to the QSIG cause value 47 Resource unavailable, unspecified; − Unsupported combination of traffic parameters − is mapped to the QSIG cause value 79 Service or option not implemented, unspecified; and − AAL parameters cannot be supported − is mapped to the QSIG cause value 95 Invalid message, unspecified. b) Any cause value and diagnostic used in both protocols shall not be changed by the Interworking PINX. c) If any cause value used in the B-PISN protocol is received by the Interworking PINX for which a diagnostic field may be present (e.g. cause value 82) while the same cause value of the QSIG protocol does not allow for a diagnostic field, then the Interworking PINX shall discard the diagnostic field and leave the cause value unchanged. A Cause information element received from the N-PISN shall be mapped according to 11.3.2.
11.5 11.5.1
Overlap sending Preceding side procedures Overlap sending may be supported at the preceding side of an inter-PINX link. When a SETUP ACKNOWLEDGE message is received, the preceding side shall: stop timer T303; start timer T304; enter the Overlap Sending state; and send the remainder of the called party number (if any) in one or more INFORMATION messages, (re-)starting timer T304 when each INFORMATION message is sent.
- 36 -
The called party number information shall be provided in the Called party number information element. An INFORMATION message may contain a Broadband sending complete information element, in addition to or instead of a Called party number information element. NOTE 16 It is recommended that the preceding side inserts the Broadband sending complete information element in the INFORMATION message if the preceding side can determine that this message contains the last digit(s) of the called party number. At the expiration of timer T304 the preceding side shall initiate call clearing to the succeeding side in accordance with 9.3 with cause No. 102 recovery on timer expiry and indicate call failure with cause 28 invalid number format (incomplete number) to call/connection handling. NOTE 17 This will result in clearing with cause 28 towards the calling user. 11.5.2
Succeeding side procedures Overlap sending shall be supported at the succeeding side of an inter-PINX link. When the succeeding side determines that a received SETUP message contains either: a) incomplete called number information, or b) called number information which the succeeding side cannot determine to be complete, the succeeding side shall: start timer T302; send a SETUP ACKNOWLEDGE message to the preceding side; and enter the Overlap Receiving state. The succeeding side shall (re-)start timer T302 on receipt of every INFORMATION message not containing a Broadband sending complete information element. Following the receipt of a Broadband sending complete information element, or the determination that sufficient call information has been received, the succeeding side shall stop timer T302 and send a CALL PROCEEDING message to the preceding side. Alternatively, depending on internal events, the succeeding side may send an ALERTING or CONNECT message to the preceding side. At the expiration of timer T302 the succeeding side shall either: a) send a CALL PROCEEDING, ALERTING or CONNECT message as appropriate if sufficient information has been received; or b) initiate clearing in accordance with 9.3 with cause No.28 invalid number format (incomplete number) if it determines that the call information is definitely incomplete. If, following the receipt of a SETUP message or during overlap sending, the succeeding side determines that the received call information is invalid (e.g. invalid called party number), it shall initiate call clearing in accordance with 9.3 with a cause such as one of the following: − 1 Unassigned (unallocated) number; − 3 No route to destination; − 22 Number changed − 28 Invalid number format (incomplete number).
11.6
Notification of interworking The QSIG-Progress indicator information element shall be mapped to the B-PISN-Progress indicator information element and vice versa, such that octet 3 of the former is equal to octet 5 of the latter. A Progress indicator information element included in a call control message shall not change the processing of that message. If the Progress indicator information element is included in the PROGRESS message, no state change shall occur but the PINX shall stop timer T310 if the progress description is No. l, No. 2, or No. 8.
- 37 -
11.7
Tones and announcements
11.7.1
Tones and announcements during call establishment Tones and announcements may be provided by the succeeding side only if the N-BC information element is present and indicates Speech, 3.1 kHz audio or Unrestricted digital information with tones and announcements. When providing tones or announcements, the succeeding side shall send a Progress indicator information element with progress description No. 8 In-band information or appropriate pattern now available in a suitable call control message or a PROGRESS message to the preceding side. NOTE 18 Call/connection handling will through-connect the user plane virtual channel (at least) in backward direction (if not done already) upon receipt of progress description No. 8. Traffic and protocol parameters indicated in the SETUP message shall be used for the transmission of tones and announcements. NOTE 19 Tones and announcements generated in a non-B-PISN are converted into ATM cells (using AAL type for voice) at the Interworking PINX. Tones and announcements generated in the B-PISN are converted into the 64 kbit/s stream at the Interworking PINX.
11.7.2
Clearing when tones and announcements are provided When in-band tones/announcements are provided by the succeeding side in the course of call clearing, a PROGRESS message may be sent, containing a Cause information element and a progress indicator No. 8 Inband information or appropriate pattern now available. Sending of the PROGRESS message is optional in the Active state but mandatory in the other call states. On receipt of a PROGRESS message with a Cause information element and a progress indicator No. 8, the preceding side shall inform call/connection handling. NOTE 20 The call/connection handling at the preceding PINX will either through-connect (if not already done) the user plane virtual channel or immediately start call/connection clearing according to 9.3. If call/connection clearing has not occurred after providing the tone/announcement for a sufficient time, the PINX providing the tone/announcement may initiate clearing according to 9.3.
12 12.1
Call/connection handling requirements Transit PINX call/connection handling requirements NOTE 21 The provision of Transit PINX functionality is an option. When provided, the procedures contained herein are mandatory. This clause specifies those aspects of call/connection handling at a Transit PINX that are necessary for coordinating the Succeeding Side and Preceding Side protocol entities. These procedures refer to the Preceding PINX and the Succeeding PINX. These PINXs are either side of Transit PINX. This terminology is used in order to clarify the text. The adjectives (Preceding / Succeeding) only have meaning when used in the context of a particular call/connection. The call/connection attempt will have passed from the Preceding PINX, through the Transit PINX, to the Succeeding PINX. Figure 6 shows the conceptual relationship between the Call/Connection Handling and Succeeding and Preceding Protocol Control within a Transit PINX.
- 38 -
Preceding PINX
Transit PINX Transit Call Handling Succeeding Side Protocol Control
Succeeding PINX
Preceding Side Protocol Control
Figure 6 - Conceptual Relationship between Call/Connection Handling and Protocol Control
The Transit PINX's Call/Connection Handling states used in this clause are a different set of states from the Protocol Control states described in earlier clauses. The Transit PINX's Call/Connection Handling states are marked as such by "TCC_" in front of their names. These states are conceptual and used only as an aid to description of the actions required at a Transit PINX. As such, they are not directly visible in the protocol and cannot be tested directly. A short description of each of the states is given below. Any reference to messages received shall be interpreted as meaning a message which has passed the validation checks of Protocol Control and which has therefore resulted in a notification being given to Call/Connection Handling. On receipt of a SETUP message, if the Call/Connection Handling of the PINX chooses to route the call/connection onwards on a further inter-PINX link employing the signalling protocol specified in this Standard, it shall conform to the procedures for a Transit PINX contained in this clause. The procedures defined in this clause show how the message flows of the two interfaces on either side of a Transit PINX are interrelated. Detailed specification and description language (SDL) diagrams for the procedures specified in this clause are contained in annex G. 12.1.1
Receipt of SETUP message On receipt of a SETUP message from the Preceding PINX, the call/connection request shall be processed. NOTE 22 Processing includes among other actions acceptance of the incoming and selection of an outgoing user plane virtual channel. If the processing is successful and a regular broadband service is requested, a CALL PROCEEDING message shall be sent to the Preceding PINX, a SETUP message shall be sent to the Succeeding PINX, and the Transit PINX shall enter the TCC_Incoming_Call_Proceeding state. If the processing is not successful, a RELEASE COMPLETE message shall be sent to the Preceding PINX, and the Transit PINX shall remain in the TCC_Idle state. For determination of service category, selection of traffic parameters, negotiation of traffic parameters and selection of quality of service parameters the procedures of PNNI 1.0, clause 6.5.2.3 shall apply, with the following exception: Crankback procedures shall not apply. If the SETUP message contains an OAM traffic descriptor information element with field Shaping indicator set to "aggregate shaping of user and OAM cells is not allowed, if shaping is applied by the network" then the PINX shall not apply aggregate shaping. If the PINX cannot comply with this requirement the call/connection request shall be considered unsuccessful. The cause value used in this case should be #63, service or option not available, unspecified.
12.1.2
Channel through connection procedures During call/connection setup, the Transit PINX should through connect the agreed user plane virtual channel to the Succeeding PINX as outlined below. The earliest point at which through connection may occur (in either forward, backward or both directions) is when the Transit PINX receives the first response to an outgoing SETUP message.
- 39 -
The latest point that through connection in both directions shall occur is on receipt of a CONNECT message from the Succeeding PINX. NOTE 23 It is recommended that through connection in both directions be achieved as early as possible during call/connection set up. This is important for services providing the conveyance of speech information. Delaying through connection, particularly in the backward direction, to a later stage during call/connection setup may lead to "speech clipping". 12.1.3
State TCC_Incoming_Call_Proceeding If a RELEASE COMPLETE message is received from the Succeeding PINX, the call/connection shall either be cleared as described in 12.1.7.1, or other procedures may be attempted by the Transit PINX. If a CALL PROCEEDING message is received from the Succeeding PINX, the Transit PINX may through connect the user plane virtual channel and shall enter the TCC_Transit_Call_Proceeding state. If a RELEASE or RELEASE COMPLETE message is received from the Preceding PINX, the call/connection shall be cleared as described in 12.1.7.1. If, for any reason, the Transit PINX decides to abort the call/connection, it shall clear the call/connection in both directions as described in 12.1.7.2.
12.1.4
State TCC_Transit_Call_Proceeding If an ALERTING message is received from the Succeeding PINX, an ALERTING message shall be sent to the Preceding PINX, and the Transit PINX shall enter the TCC_Call_Alerting state. The user plane virtual channel may be through connected in the backward direction or in both directions. If a CONNECT message is received from the Succeeding PINX, a CONNECT message shall be sent to the Preceding PINX and the Transit PINX shall through connect the user plane virtual channel in both directions (unless it has already done so) and enter the TCC_Call_Active state. The ATM traffic descriptor information element shall be handled according to PNNI 1.0, clause 6.5.2.6.1 and 6.5.2.6.2. If a PROGRESS message is received from the Succeeding PINX, a PROGRESS message shall be sent to the Preceding PINX, and no state change shall occur. If a RELEASE or RELEASE COMPLETE message is received from the Preceding PINX, the call/connection shall be cleared as described in 12.1.7.1. If a RELEASE or RELEASE COMPLETE message is received from the Succeeding PINX, the call/connection shall either be cleared using procedures as described in 12.1.7.1, or other procedures may be attempted by the Transit PINX. If, for any reason, the Transit PINX decides to abort the call/connection, it shall clear the call/connection in both directions as described in 12.1.7.2.
12.1.5
State TCC_Call_Alerting If a CONNECT message is received from the Succeeding PINX, a CONNECT message shall be sent to the Preceding PINX and the Transit PINX shall through connect the user plane virtual channel in both directions (unless it has already done so) and enter the TCC_Call_Active state. The ATM traffic descriptor information element shall be handled according to PNNI 1.0, clause 6.5.2.6.1 and 6.5.2.6.2. If a PROGRESS message is received from the Succeeding PINX, a PROGRESS message shall be sent to the Preceding PINX, and no state change shall occur. If a RELEASE or RELEASE COMPLETE message is received from the Preceding PINX, the call/connection shall be cleared as described in 12.1.7.1. If a RELEASE or RELEASE COMPLETE message is received from the Succeeding PINX, the call/connection shall be cleared as described in 12.1.7.1. If, for any reason, the Transit PINX decides to abort the call/connection, it shall clear the call/connection in both directions as described in 12.1.7.2.
- 40 -
12.1.6
State TCC_Call_Active If a RELEASE or RELEASE COMPLETE message is received from either the Preceding or Succeeding PINXs, the call/connection shall be cleared as described in 12.1.7.1. If, for any reason, the Transit PINX decides to abort the call/connection, it shall clear the call/connection in both directions as described in 12.1.7.2.
12.1.7 12.1.7.1
Clearing at a Transit PINX Call/connection clearing not initiated by the Transit PINX On receipt of a RELEASE or RELEASE COMPLETE message from the Preceding PINX, the Transit PINX shall: − disconnect the incoming and outgoing virtual channels, if connected, − send a RELEASE message to the Succeeding PINX, − if a RELEASE message was received from the Preceding PINX, send a RELEASE COMPLETE message to the Preceding PINX, and − enter the TCC_Await_Outgoing_Release state. When subsequently a RELEASE COMPLETE message is received from the Succeeding PINX, the Transit PINX shall release any assigned resources and revert to the TCC_Idle state. On receipt of a RELEASE or RELEASE COMPLETE message from the Succeeding PINX, the Transit PINX shall disconnect the incoming and outgoing user plane virtual channels, if connected, and send a RELEASE message to the Preceding PINX. Alternatively, during call/connection establishment, if the call/connection has not yet reached the TCC_Call_Alerting state, the Transit PINX may attempt some other (unspecified) procedure instead of sending RELEASE to the Preceding PINX. If a RELEASE message was received from the Succeeding PINX, the Transit PINX shall send a RELEASE COMPLETE message to the Succeeding PINX. If a RELEASE message was sent to the Preceding PINX, the Transit PINX shall enter the TCC_Await_Incoming_Release state. When subsequently a RELEASE COMPLETE message is received from the Preceding PINX, the Transit PINX shall release any assigned resources and revert to the TCC_Idle state.
12.1.7.2
Call/connection clearing initiated by the Transit PINX If a Transit PINX decides to abort a call/connection, it shall disconnect the incoming and outgoing user plane virtual channels, if connected, send (in both directions) a RELEASE message and enter the TCC_Await_TwoWay_Release state. Each side of the PINX shall then continue normal clearing procedures (i.e. release of all associated resources) independently of the other. If subsequently a RELEASE COMPLETE message is received first from the Preceding PINX or the Succeeding PINX the Transit PINX shall enter the TCC_Await_Outgoing_Release or the TCC_Await_Incoming_Release state, respectively. On receipt of a RELEASE COMPLETE message from the second side the Transit PINX shall revert to the TCC_Idle state.
12.1.8
Additional procedures for N-PISN interworking The following procedures are in addition to the Transit PINX call/connection handling requirements described in 12.1.1 through 12.1.7 and the protocol control requirements described in clause 11. If an N-PISN service is requested the SETUP message may contain incomplete called party number information. If the Transit PINX either recognizes that the address information is incomplete or is not able to determine whether it is complete, the Transit PINX shall: − send a SETUP ACKNOWLEDGE message to the Preceding PINX; − if enough digits have been received to route the call/connection, send a SETUP message to the Succeeding PINX and enter the TCC_Await_Additional_Digits state, − else enter the TCC_Await_Digits state.
- 41 -
12.1.8.1
State TCC_Await_Digits Additional address information is received in INFORMATION messages. Once enough address information has been received in order to route the call/connection, a SETUP message shall be sent to the Succeeding PINX. If, on analysis of the digits, the Transit PINX identifies that there are no more digits expected, a CALL PROCEEDING message shall be sent to the Preceding PINX and the Transit PINX shall enter the TCC_Incoming_Call_Proceeding state; otherwise the Transit PINX shall enter the TCC_Await_Additional_Digits state. NOTE 24 The method by which the Transit PINX determines that the address information is adequate for the particular use is beyond the scope of this Standard. If a RELEASE or RELEASE COMPLETE message is received from the Preceding PINX, the call/connection shall be cleared as described in 12.1.7.1. If, for any reason, the Transit PINX decides to abort the call/connection, it shall clear the call/connection by sending a RELEASE message to the Preceding PINX and continuing normal clearing procedures as described in 12.1.7.2. If the Protocol Control of the Succeeding Side of the interface notifies the Transit Call/Connection Handling that T302 has expired, then the PINX may either clear the call/connection by sending RELEASE to the Preceding PINX, or attempt some other (unspecified) procedure.
12.1.8.2
State TCC_Await_Additional_Digits Any additional address information which is received in INFORMATION messages shall be buffered in the Transit PINX whilst waiting for a response to the SETUP message that has been sent to the Succeeding PINX. If the Transit PINX determines that the address information it has received is complete, a CALL PROCEEDING message shall be sent to the Preceding PINX and the Transit PINX shall enter the TCC_Incoming_Call_Proceeding state; otherwise it shall remain in the TCC_Await_Additional_Digits state. If a SETUP ACKNOWLEDGE message is received from the Succeeding PINX, the Transit PINX shall enter the TCC_Overlap state and may through connect the user plane virtual channel. Any buffered address information shall be forwarded to the Succeeding PINX in an INFORMATION message. If a RELEASE COMPLETE message is received from the Succeeding PINX, the call/connection may either be cleared as described in 12.1.7.1, or the PINX may attempt some other (unspecified) procedure. If a CALL PROCEEDING message is received from the Succeeding PINX, no more address information shall be sent to the Succeeding PINX, and the Transit PINX shall enter the TCC_Transit_Call_Proceeding state and may through connect the user plane virtual channel. Any buffered address information shall be discarded and any further INFORMATION messages received shall be ignored. If a RELEASE or RELEASE COMPLETE message is received from the Preceding PINX, the call/connection shall be cleared as described in 12.1.7.1. If, for any reason, the Transit PINX decides to abort the call/connection, it shall clear the call/connection in both directions as described in 12.1.7.2. If the Protocol Control of the Succeeding Side of the interface notifies Transit Call/Connection Handling that T302 has expired, then the PINX shall either send a CALL PROCEEDING message to the Preceding PINX and enter the TCC_Incoming_Call_Proceeding state, or attempt some other (unspecified) procedure.
12.1.8.3
State TCC_Overlap Any additional address information which is received in INFORMATION messages shall be sent on to the Succeeding PINX in INFORMATION messages. If it is known that the address information is complete, a Sending complete information element may be sent in an INFORMATION message. If a CALL PROCEEDING message is received from the Succeeding PINX, no more address information shall be sent to the Succeeding PINX, and the Transit PINX shall enter the TCC_Transit_Call_Proceeding state. If the Transit PINX determines that it has received all the address information (e.g. on receipt of CALL PROCEEDING from the Succeeding PINX, on receipt of a Sending complete information element from the Preceding PINX, or by digit analysis), a CALL PROCEEDING message shall be sent to the Preceding PINX,
- 42 -
and the Transit PINX shall enter the TCC_Transit_Call_Proceeding state; else it shall stay in the TCC_Overlap state. If an ALERTING message is received from the Succeeding PINX, an ALERTING message shall be sent to the Preceding PINX, and the Transit PINX shall enter the TCC_Call_Alerting state. If this message contains CCITT Progress description number 1 "call is not end to end ISDN, further information may be available in band" or number 8 "in band information or appropriate pattern now available", the user plane virtual channel shall be through connected in the backward direction, if this has not already occurred. If a CONNECT message is received from the Succeeding PINX, a CONNECT message shall be sent to the Preceding PINX and the PINX shall through connect the user plane virtual channel in both directions (unless it has already done so) and enter the TCC_Call_Active state. If a RELEASE or RELEASE COMPLETE message is received from the Preceding PINX, the call/connection shall be cleared as described in 12.1.7.1. If a RELEASE or RELEASE COMPLETE message is received from the Succeeding PINX, the call/connection may either be cleared using procedures as described in 12.1.7.1, or other procedures may be attempted by the Transit PINX; however, the clearing sequence with the Succeeding PINX shall be completed as described in 12.1.7.1. If the Protocol Control of the Succeeding Side of the interface notifies the Transit Call Handling that T302 has expired, the PINX shall either send a CALL PROCEEDING message to the Preceding PINX and enter the TCC_Transit_Call_Proceeding state, or attempt some other (unspecified) procedure. If, for any reason, the Transit PINX decides to abort the call/connection, it shall clear the call/connection in both directions as described in 12.1.7.2. 12.1.8.4
State TCC_Incoming_Call_Proceeding If a SETUP ACKNOWLEDGE message is received from the Succeeding PINX the Transit PINX may through connect the user plane virtual channel and shall enter the TCC_Transit_Call_Proceeding state.
12.1.8.5
State TCC_Transit_Call_Proceeding If an ALERTING message is received from the Succeeding PINX containing CCITT Progress description number 1 "call is not end to end ISDN, further information may be available in band" or number 8 "in band information or appropriate pattern now available", the user plane virtual channel shall be through connected in the backward direction if this has not already occurred.
12.1.8.6
Receipt of a PROGRESS message If a PROGRESS message is received from the Succeeding PINX in any state other than TCC_Call_Active, a PROGRESS message shall be sent to the Preceding PINX. If this message contains CCITT Progress description number 1 "call is not end to end ISDN, further information may be available in band" or number 8 "in band information or appropriate pattern now available", the user plane virtual channel shall be through connected in the backward direction if this has not already occurred. No state change shall occur. If in the TCC_Call_Active state a PROGRESS message is received from the Preceding or the Succeeding PINX, containing CCITT Progress description number 8 "in band information or appropriate pattern now available", the Transit PINX may send a PROGRESS information to the Succeeding or Preceding PINX, respectively. NOTE 25 As an alternative procedure, the Transit PINX may discard a PROGRESS message received without sending a PROGRESS message to the adjacent PINX. However, this procedure is not recommended.
12.1.8.7
Clearing with tones or announcements If the call/connection is to be cleared, where an in-band tone or announcement is appropriate (i.e. if it conveys information which is not conveyable by signalling), the Transit PINX, instead of sending a clearing message, may connect an in-band tone or announcement to either (or both) side(s) of the PINX and transmit a PROGRESS message, containing CCITT Progress description number 8 "in band information or appropriate pattern now available" and an appropriate cause. If Call/Connection Handling is in the TCC_Call_Active state, the announcement may optionally be applied without sending a PROGRESS message, as the user plane virtual channel will be through connected in both directions at this stage.
- 43 -
Call/Connection Handling of the Transit PINX shall ensure that, for each side, if an indication of clearing has not been received by the time the tone or announcement is complete (or has been applied for sufficient time), normal clearing procedures as described in 12.1.7 shall be invoked. 12.1.9
Handling of basic call information elements at a Transit PINX This subclause applies only to information elements contained within messages which may (but need not) be passed on by a Transit PINX. Examples of these are SETUP, ALERTING, CONNECT and RELEASE.
12.1.9.1
Mandatory Information Elements All mandatory information elements will (by definition) appear in messages on both sides of the Transit PINX. Where necessary they will be processed within Transit PINX and may be different on either side of the PINX.
12.1.9.2
Non-Mandatory Information Elements Non-mandatory information elements fall into three categories: Category 1:
If they are present, they shall be passed on to the next PINX if the message is passed on. They may be locally generated or modified.
Category 2:
If they are present, they shall be passed unchanged onto the next PINX.
NOTE 26 These information elements need not be examined at the Transit PINX. Category 3:
If they are present, they may be passed on to the next PINX if the message is passed on. They may be locally generated or modified.
Table 34 shows the category to which each information element belongs.
- 44 -
Table 34 - Non-Mandatory Information Element Categories Information Element
Category 1 Category 2 Category 3 Notes
Called party subaddress Calling party number
* *
Calling party subaddress
May be modified *
Cause (in PROGRESS)
*
Connected number
*
May be modified
Connected subaddress
*
Narrowband bearer capability
*
Narrowband High layer compatibility
*
Narrowband Low layer compatibility
*
Progress indicator
*
Broadband sending complete
*
ATM adaptation layer parameter
*
OAM traffic descriptor
*
Broadband high layer information
*
Broadband low layer information
*
End to end transit delay
Shaping indicator field shall be examined by Transit PINXs that apply aggregate shaping
*
Notification indicator
May be modified *
Broadband repeat indicator
*
Depends on repeated IE
ATM traffic descriptor (in CONNECT)
*
May be modified or locally generated
Endpoint reference
*
Quality of service parameter
*
Transit network selection
*
Generic identifier transport
*
Minimum acceptable ATM traffic descriptor
*
Alternate ATM traffic descriptor
*
ABR setup parameters
*
Mandatory for ABR service; may be modified
Called party soft PVPC/PVCC
*
Calling party soft PVPC/PVCC
*
ABR additional parameters
*
Connection scope selection Extended QoS parameters
May be modified *
*
May be modified
- 45 -
12.1.9.3
Pass-along indication The following procedures shall apply if the flag in the instruction indicator is set to "follow explicit instructions": An unrecognized message having the pass along field set to "pass along request" shall be sent unmodified to the next PINX. Any information element which is unexpected or unrecognized or has unrecognized contents and for which the Pass-along field is set to "pass along at a Transit PINX" shall be included unmodified in a message which is to be passed on to the next PINX.
12.1.10
Notifications A NOTIFY message received from the Preceding PINX shall be passed on to the Succeeding PINX if the Succeeding PINX has responded to the SETUP message and call/connection clearing has not been initiated. A NOTIFY message received from the Succeeding PINX shall be passed on to the Preceding PINX if call/connection clearing has not been initiated. No state change shall be caused by the receipt or sending of a NOTIFY message.
12.2
Originating PINX call/connection handling requirements This subclause specifies requirements for Call/Connection Handling at an Originating PINX on the Preceding Side of an inter-PINX link. These requirements are additional to the Protocol Control procedures specified in clause 9. The following requirements apply when an Originating PINX chooses to route a call/connection over an inter-PINX link and has selected a user plane virtual channel to be used. Any reference to messages received shall be interpreted as meaning a message which has passed the validation checks of Protocol Control and which has therefore resulted in a notification being given to Call/Connection Handling.
12.2.1
Transmission of the SETUP message The Originating PINX shall transmit a SETUP message. The SETUP message shall include optional information elements according to the following rules. a) Broadband sending complete. The Originating PINX shall send this information element if a B-PISN specific service is requested. NOTE 27 In the case of an N-PISN service the PINX will become an Interworking PINX; see 12.6. b) Calling party number. The Originating PINX shall include the Calling party number information element identifying the calling user. The presentation indicator shall have the value "presentation restricted" if supplementary service Calling/Connected Line Identification Restriction has been invoked at the calling user. Otherwise, the presentation indicator, if present, shall have the value "presentation allowed". c) Calling party subaddress. The Originating PINX shall include the Calling party subaddress information element if a calling party subaddress is available. d) Called party subaddress. The Originating PINX shall include the Called party subaddress information element if a called party subaddress is available. e) Broadband low layer information. The Originating PINX shall include the B-LLI information element if low layer information is available. f) Broadband high layer information. The Originating PINX shall include the B-HLI information element if high layer information is available. g) AAL parameters. The Originating PINX shall include the AAL parameters information element if ATM adaptation layer information is available. h) End to end transit delay. The Originating PINX shall include the End to end transit delay information element if maximum end to end transit delay information is available. Both cumulative transit delay and maximum end-to-end transit delay subfields shall be included.
- 46 -
i) OAM traffic descriptor. The Originating PINX shall include the OAM traffic descriptor information element if this information is available. If the Shaping indicator field is set to "aggregate shaping of user and OAM cells is not allowed, if shaping is applied by the network" the Originating PINX shall not apply aggregate shaping. If this is not possible the call/connection request shall be rejected. j) Notification indicator. The Originating PINX shall include the Notification indicator information element if notification information is appropriate. 12.2.2
Connection to the user plane virtual channel On receipt of a CALL PROCEEDING message, the Originating PINX may optionally connect the user plane virtual channel in the forward direction, in the backward direction or in both directions. NOTE 28 It is recommended that the virtual channel be connected in both directions at this stage, particularly for services involving the conveyance of speech information. Leaving the virtual channel unconnected until a later stage, particularly in the backward direction, may lead to "speech clipping". However, there may be reasons for delaying connection, particularly in the forward direction, e.g., to avoid the onward transmission of in-band signalling information from the user's access.
12.2.3
Receipt of an ALERTING message On receipt of an ALERTING message, an indication of alerting may be given to the calling user. If the ALERTING message contains a Notification indicator information element the information shall be passed on to the calling user, if the user is capable of receiving it. If the ALERTING message contains one or more Progress indicator information element(s) the information may be passed on to the calling user. Through connection may occur at this point.
12.2.4
Receipt of a CONNECT message On receipt of a CONNECT message, the Originating PINX shall connect the user plane virtual channel in both directions, if it has not already done so, and shall indicate connection to the calling user. If the CONNECT message contains a Connected number information element and/or a Connected subaddress information element, this information may be used for purposes such as the provision of the Connected Line Identification Presentation supplementary service to the calling user. If the CONNECT message contains a B-LLI information element, the information shall be passed on to the calling user, if the user is capable of receiving it. If the CONNECT message contains an AAL parameters information element, the information shall be passed on to the calling user, if the user is capable of receiving it. If the CONNECT message contains an End to end transit delay information element, the information shall be passed on to the calling user, if the user is capable of receiving it. If the CONNECT message contains an OAM traffic descriptor information element, the information shall be passed on to the calling user, if the user is capable of receiving it. If the CONNECT message contains a Notification indicator information element, the information shall be passed on to the calling user, if the user is capable of receiving it. If the CONNECT message contains one or more Progress indicator information element(s) the information may be passed on to the calling user.
12.2.5
Receipt of PROGRESS message Information received in Progress indicator information elements in a PROGRESS message shall be conveyed to the calling user if the calling user is capable of receiving it.
12.2.6
Notifications The Originating PINX may send a NOTIFY message at any time after a first response to SETUP has been received and before call/connection clearing has been initiated.
- 47 -
If the Originating PINX receives a NOTIFY message associated with a call/connection in progress the PINX shall pass the information to the calling user if the user is capable of receiving it and if call/connection clearing has not been initiated. 12.2.7
Call/connection clearing initiated by the Originating PINX The Originating PINX shall initiate clearing on the inter-PINX link if a clear request is received from the calling user. The Originating PINX may also initiate clearing if a failure condition occurs. Clearing is initiated by disconnecting the user plane virtual channel, if connected, informing Protocol Control and supplying a cause.
12.2.8
Receipt of an indication of call/connection clearing On receipt of an indication of call/connection clearing from Protocol Control, the Originating PINX shall either indicate to the calling user that the call/connection has cleared or take some other implementation dependent action.
12.3
Terminating PINX call/connection handling requirements This subclause specifies requirements for Call/Connection Handling at a Terminating PINX on the Succeeding Side of an inter-PINX link. These requirements are additional to the Protocol Control procedures specified in clause 9.6. The following requirements apply when a PINX receives a SETUP message and determines that the destination is a user on that PINX. The PINX therefore becomes a Terminating PINX. Any reference to messages received shall be interpreted as meaning a message which has passed the validation checks of Protocol Control and which has therefore resulted in a notification being given to Call/Connection Handling.
12.3.1
Receipt of the SETUP message If the SETUP message contains the value "point-to-multipoint" in the field User plane connection configuration of the Broadband bearer capability information element and this feature is not supported the call/connection request shall be rejected with cause #65, bearer service not implemented. If the SETUP message contains an End-to-end transit delay information element the cumulative transit delay subfield shall be updated. If the updated value exceeds the value in the maximum end-to-end transit delay subfield, the call/connection request shall be rejected with cause #49, Quality of service not available. If the SETUP message contains a OAM traffic descriptor information element with the Shaping indicator field set to "aggregate shaping of user and OAM cells is not allowed, if shaping is applied by the network" the Terminating PINX shall not apply aggregate shaping. If this is not possible the call shall be rejected with cause #63, service or option not available, unspecified. Optional information elements in the received SETUP message shall be used as follows. a) AAL parameters, Broadband low layer information, Broadband high layer information, Called party subaddress, End to end transit delay, OAM traffic descriptor, and Notification indicator. If the SETUP message contains one or more of these information elements, and if the called user is capable of receiving them, the information element(s) shall be conveyed to the called user. b) Calling party number and Calling party subaddress. Information in the Calling party number information element, and also in the optional Calling party subaddress information element, may be used for purposes such as the provision of the Calling Line Identification Presentation supplementary service to the called user. c) Progress indicator. The information may be passed to the called user.
12.3.2
Transmission of an ALERTING message The Terminating PINX shall transmit an ALERTING message when it is aware that the called user is being alerted. The ALERTING message may include a Notification indicator information element if appropriate.
12.3.3
Transmission of a CONNECT message When the Terminating PINX is aware that the called user has answered the call/connection, it shall connect the user plane virtual channel in both directions and send a CONNECT message.
- 48 -
The Terminating PINX shall include in the CONNECT message the Connected number information element identifying the party which has answered. The presentation indicator shall have the value "presentation restricted" if supplementary service Calling / Connected Line Identification Restriction has been invoked at the called user. Otherwise, the presentation indicator, if present, shall have the value "presentation allowed". The Terminating PINX shall include in the CONNECT message the Connected subaddress information element if a connected subaddress is available. The Terminating PINX shall include in the CONNECT message any of the information elements Broadband low layer information, AAL parameters, End to end transit delay, OAM traffic descriptor, and Notification indicator if the corresponding information has been supplied by the called user. In the End-to-end transit delay information element the subfield maximum end-to-end transit delay shall be omitted. 12.3.4
Notifications The Terminating PINX may send a NOTIFY message if a first response to SETUP has been sent and call/connection clearing has not been initiated. On receipt of a NOTIFY message the contents shall be passed to the called user if the user is capable of receiving the information and call/connection clearing has not been initiated.
12.3.5
Call/connection clearing initiated by the Terminating PINX The Terminating PINX shall initiate clearing on the inter-PINX link if it is not able to proceed with call/connection establishment or if a clear request is received from the called user. Clearing may also be initiated if a failure condition occurs after the call/connection has been established. Clearing is initiated by disconnecting the user plane virtual channel, if connected, informing Protocol Control and supplying a cause.
12.3.6
Receipt of an indication of call/connection clearing On receipt of an indication of call/connection clearing from Protocol Control, the Terminating PINX shall either indicate to the called user that the call/connection has cleared or take some other implementation dependent action.
12.4
Incoming Gateway PINX call/connection handling requirements This subclause specifies requirements for Call/Connection Handling at a Gateway PINX on the Preceding Side of an inter-PINX link. These requirements are additional to the Protocol Control procedures specified in clause 9. The following requirements apply when a call/connection request is routed, by the Gateway PINX, over an interPINX link employing B-QSIG signalling, a user plane virtual channel on that link having been selected. Any reference to messages received shall be interpreted as meaning a message that has passed the validation checks of Protocol Control and has therefore resulted in a notification being given to Call/Connection Handling.
12.4.1
Transmission of the SETUP message The Gateway PINX shall transmit a SETUP message which shall include optional information elements according to the following rules: a) Broadband sending complete. The Gateway PINX may send this information element if it can determine that the number in the Called Party Number information element is complete or if this has been indicated by the other network. b) Progress indicator. The Gateway shall send this information element containing progress description #16 "interworking with a public network" if the call/connection request comes from a public network. c) Calling party number. If the other network has supplied a calling party number with or without an indication that presentation is restricted or a restriction indication only, the Gateway PINX shall include this information in the SETUP message within the Calling party number information element. Otherwise, the Calling party number information element shall either contain the presentation indicator value "number not available due to interworking" or be omitted. d) Calling party subaddress. If the other network supplies a calling party subaddress, the Gateway PINX shall pass the information on unchanged within the Calling party subaddress information element.
- 49 -
e) Called party subaddress. If the other network supplies a called party subaddress, the Gateway PINX shall pass the information on unchanged within the Called party subaddress information element. f) If the other network is a B-ISDN and supplies a B-LLI information element, the Interworking PINX shall pass the information element on unchanged in the SETUP message. g) B-HLI. If the other network is a B-ISDN and supplies a B-HLI information element, the Interworking PINX shall pass the information element on unchanged in the SETUP message. h) AAL parameters. If the other network is a B-ISDN and supplies this information element, the Interworking PINX shall pass the information element on unchanged in the SETUP message. i) End to end transit delay. If the other network is a B-ISDN and supplies this information element, the Interworking PINX shall update subfield cumulative transit delay and pass the information element on in the SETUP message if the updated value is less than the value in the maximum end-to-end transit delay subfield. If the updated value is equal or higher the call/connection request shall be rejected. j) OAM traffic descriptor. If the other network is a B-ISDN and supplies this information element, the Interworking PINX shall pass the information element on unchanged in the SETUP message. If the Shaping indicator field contains value “aggregate shaping of user and OAM cells is not allowed, if shaping is applied by the network“ the Gateway PINX shall not apply aggregate shaping. If this is not possible the call/connection request shall be rejected. k) Notification indicator. This information element may be included if notification information was received from the other network. 12.4.2
Connection of the user plane virtual channel On receipt of a CALL PROCEEDING message, the Gateway PINX may connect the user plane virtual channel in the forward direction, in the backward direction or in both directions. NOTE 29 It is recommended that the virtual channel be connected in both directions at this stage, particularly for services involving the conveyance of speech information. Leaving the connection until a later stage, particularly in the backward direction, may lead to the "speech clipping". However, there may be reasons for delaying connection, particularly in the forward direction, e.g., to avoid the onward transmission of in-band signalling information.
12.4.3
Receipt of ALERTING message On receipt of an ALERTING message, an indication of alerting shall be given to the other network if the signalling system allows. If the ALERTING message contains any of the information elements Notification indicator and Progress indicator the information shall be conveyed to the other network if the network is able to receive the information.
12.4.4
Receipt of CONNECT message On receipt of a CONNECT message, the Gateway PINX shall connect the user plane virtual channel in both directions, if it has not already done so, and shall indicate connection to the other network. If the CONNECT message contains any of the information elements AAL parameters, B-LLI, End-to-end transit delay, Notification indicator, Progress indicator, OAM traffic descriptor, Connected subaddress, this information shall be conveyed to the other network if the network is able to receive the information. If the CONNECT message contains a Connected number information element, this information shall be passed to the other network, with the exception that a restricted connected number may be omitted, depending on the arrangement with the other network.
12.4.5
Receipt of PROGRESS message Information received in Progress indicator information elements in a PROGRESS message shall be conveyed to the other network if the other network is able to receive this information.
12.4.6
Notifications The Gateway PINX may send a NOTIFY message towards the Terminating PINX at any time after a response to SETUP has been received and before call/connection clearing has been initiated.
- 50 -
On receipt of a NOTIFY message the information shall be conveyed to the other network if the network is able to receive the information and call/connection clearing has not been initiated. 12.4.7
Call/connection clearing initiated by the Gateway PINX The Gateway PINX shall initiate clearing on the inter-PINX link if a clear request is received from the other network. The Gateway PINX may also initiate clearing on the inter-PINX link if a failure condition occurs. Clearing is initiated by disconnecting the user plane virtual channel, if connected, informing Protocol Control and supplying a cause.
12.4.8
Receipt of an indication of call/connection clearing On receipt of an indication of call/connection clearing from Protocol Control, the Gateway PINX shall initiate clearing towards the other network.
12.5
Outgoing Gateway PINX call/connection handling requirements This subclause specifies requirements for Call/Connection Handling at a Gateway PINX on the Succeeding Side of an inter-PINX link. These requirements are additional to the Protocol Control procedures specified in clause 9. The following requirements apply when a PINX receives a SETUP message and determines that the call/connection is to be routed to another network. Any reference to messages received shall be interpreted as meaning a message that has passed the validation checks of Protocol Control and has therefore resulted in a notification being given to Call/Connection Handling.
12.5.1
Receipt of the SETUP message If the SETUP message contains the value "point-to-multipoint" in the field User plane connection configuration of the Broadband bearer capability information element and this feature is not supported the call/connection request shall be rejected with cause value #65, bearer service not implemented. If the SETUP message contains an End-to-end transit delay information element the cumulative transit delay subfield shall be updated. If the updated value exceeds the value in the maximum end-to-end transit delay subfield, the call/connection request shall be rejected with cause #49, Quality of service not available. If the SETUP message contains an OAM traffic descriptor information element with field Shaping indicator set to “aggregate shaping of user and OAM cells is not allowed, if shaping is applied by the network“ the Gateway PINX shall not apply aggregate shaping. If this is not possible the call/connection request shall be rejected with cause #63, service or option not available, unspecified. Information elements in the received SETUP message shall be used as follows. a) AAL parameters, End to end transit delay, OAM traffic descriptor, Notification indicator, Progress indicator, B-HLI, B-LLI, Called party subaddress and Calling party subaddress. If the SETUP message contains one or more of these information elements, the information element(s) shall be conveyed to the other network if it is capable of receiving the information. b) Calling party number. If the SETUP message contains a Calling party number information element whose presentation is not restricted it shall be conveyed to the other network if the network is able to receive the information. If the received Calling party number information element has the presentation indicator value "presentation restricted", the number may be omitted, depending on the arrangement with the other network.
12.5.2
Connection of the user plane virtual channel The Interworking PINX may connect the user plane virtual channel in the forward direction, in the backward direction or in both directions as soon as the information channel to the other network has been agreed. NOTE 30 It is recommended that the user plane virtual channel is connected in both directions at this stage, particularly for services involving the conveyance of speech information. Leaving the connection until a later stage, particularly in the backward direction, may lead to the "speech clipping" or the loss of in-band tones or announcements. However, there may be reasons for delaying connection, particularly in the forward direction, e.g., while transmitting in-band signalling information.
- 51 -
12.5.3
Transmission of ALERTING message The Gateway PINX shall transmit an ALERTING message when it receives an indication from the other network that the called user is being alerted. The ALERTING message may contain a Progress indicator information element with Progress description #16 “interworking with a public network“ if the other network is a public network. The ALERTING message may also contain a Notification indicator information element if notification information is supplied by the other network.
12.5.4
Transmission of CONNECT message When the Gateway PINX receives an indication from the other network that the called user is connected, the Gateway PINX shall connect the user plane virtual channel in both directions, if it has not already done so, and send a CONNECT message. The CONNECT message shall contain a Progress indicator information element with Progress description #16 'interworking with a public network' if the other network is a public network and this indication has not been sent before. If the other network has supplied a connected number with or without an indication that presentation is restricted or a restriction indication only, the Gateway PINX shall include this information in the CONNECT message within the Connected number information element. Otherwise, the Connected number information element shall either contain the presentation indicator value "number not available due to interworking" or be omitted. If the other network supplies a connected subaddress, the Gateway PINX shall include a Connected subaddress information element in the CONNECT message. If the other network is a B-ISDN and supplies one or more of the information elements AAL parameters, B-LLI, End-to-end transit delay, Notification indicator, OAM traffic descriptor, the Gateway PINX shall include the corresponding information element(s) in the CONNECT message.
12.5.5
Transmission of PROGRESS message A Progress indicator information element with progress description #16 'interworking with a public network' may be transmitted in a PROGRESS message as an alternative to transmitting this information in an ALERTING or CONNECT message.
12.5.6
Notifications The Gateway PINX may send a NOTIFY message towards the Originating PINX at any time after having sent a first response to SETUP and before call/connection clearing has been initiated. On receipt of a NOTIFY message the contents shall be conveyed to the other network if the network is able to receive the information.
12.5.7
Call/connection clearing initiated by the Gateway PINX The Gateway PINX shall initiate clearing on an inter-PINX link if it is not able to proceed with call/connection establishment or if a clear request is received from the other network. Clearing may also be initiated if a failure condition occurs after the call/connection has been established. Clearing is initiated by disconnecting the user plane virtual channel, if connected, informing Protocol Control and supplying a cause.
12.5.8
Receipt of an indication of call/connection clearing On receipt of a call/connection clearing indication from Protocol Control, the Gateway PINX shall initiate call clearing towards the other network.
12.6
Interworking PINX call/connection handling requirements for N-PISN -> B-PISN interworking The requirements for an Incoming Gateway PINX as stated in 12.4 shall apply, with the additions contained in this subclause, if the other network is an N-PISN. NOTE 31 For the purposes of this subclause, a call is considered to have originated in the N-PISN even if in reality it has originated at a narrow-band terminal attached to the Interworking PINX or in another narrow-band network (e.g. public ISDN or non-ISDN) attached to the Interworking PINX. The requirements here are additional to the Protocol Control procedures specified in clause 11.
- 52 -
12.6.1
Transmission of the SETUP message The SETUP message transmitted by the Interworking PINX shall include optional information elements according to 12.4.1 and the following additional rules. a) Progress indicator. If the N-PISN supplies one or more Progress indicator information element(s), the Interworking PINX shall pass the contents of the information element(s) on unchanged in the SETUP message. b) N-BC. The Interworking PINX shall include the Narrowband bearer capability information element. c) If the N-PISN supplies a Low layer compatibility information element, the Interworking PINX shall pass the contents of the information element on unchanged in the SETUP message. d) N-HLC. If the N-PISN supplies a High layer compatibility information element, the Interworking PINX shall pass the contents of the information element on unchanged in the SETUP message. The SETUP message may be followed by one or more INFORMATION messages conveying additional called party number information.
12.6.2
Connection of the user plane virtual channel On receipt of a SETUP ACKNOWLEDGE message, the Interworking PINX may connect the user plane virtual channel in the forward direction, in the backward direction or in both directions. NOTE 32 It is recommended that the virtual channel be connected in both directions at this stage, particularly for services involving the conveyance of speech information. Leaving the connection until a later stage, particularly in the backward direction, may lead to the "speech clipping". However, there may be reasons for delaying connection, particularly in the forward direction, e.g., to avoid the onward transmission of in-band signalling information from the N-PISN.
12.6.3
Receipt of progress indicators Information received in a Progress indicator information element in a PROGRESS message, an ALERTING message or a CONNECT message shall be passed on unchanged to the N-PISN. On receipt of a Progress indicator information element with CCITT progress description number 1 "call is not end-to-end ISDN, further call progress information may be available in-band" or number 8 "in-band information or appropriate pattern now available", the Interworking PINX shall connect the user plane virtual channel in the backward direction if it has not already done so.
12.6.4
Receipt of CONNECT message If the CONNECT message contains an N-LLC information element, the contents of the information element shall be conveyed unchanged to the N-PISN.
12.6.5
Call/connection clearing initiated by the interworking PINX Alternatively to clearing, for services for which an in-band tone or announcement is appropriate, if the protocol control state is Active, the Interworking PINX may connect an in-band tone or announcement to the outgoing user plane virtual channel and may transmit to the Succeeding PINX a PROGRESS message containing a Progress indicator information element with CCITT progress description 8 "in-band information or appropriate pattern now available" and an appropriate cause. If in protocol control state Active the N-PISN sends a PROGRESS message containing a Cause and a Progress indicator information element with CCITT progress description 8 "in-band information or appropriate pattern now available", the Interworking PINX may send a PROGRESS message with the same cause value and progress description to the Succeeding PINX. In both cases, if an indication of clearing has not been received from Protocol Control by the time the tone or announcement is complete or has been applied for sufficient time, the Interworking PINX shall instruct Protocol Control to initiate clearing (in both directions). NOTE 33 It is recommended that an in-band tone or announcement be provided by the Interworking PINX only if it conveys call failure information which is not conveyable by signalling.
- 53 -
12.7
Interworking PINX call/connection handling requirements for B-PISN -> N-PISN interworking The requirements for an Outgoing Gateway PINX as stated in 12.5 shall apply, with the additions contained in this subclause, if the other network is an N-PISN. NOTE 34 For the purposes of this subclause, a call is considered to terminate in the N-PISN even if in reality it terminates at a narrow-band terminal attached to the Interworking PINX or in another narrow-band network (e.g. public ISDN or non-ISDN) attached to the Interworking PINX. These requirements are additional to the Protocol Control procedures specified in clause 11.
12.7.1
Receipt of the SETUP message A PINX shall become an Interworking PINX only if an N-BC information element is present, the bearer class in the B-BC information element indicates BCOB-A, and the ATM traffic descriptor and/or the AAL parameters information elements specify values in accordance with 11.2. Information elements in the received SETUP message shall be used as follows. a) Progress indicator. If the SETUP message contains one or more Progress indicator information element(s), the information therein shall be passed on to the N-PISN. b) N-BC, N-LLC, N-HLC. If the SETUP message contains one or more of these information elements, the contents of the information element(s) shall be conveyed unchanged to the N-PISN. c) AAL parameters, End to end transit delay, OAM traffic descriptor. These information elements shall be discarded if contained in the SETUP message. d) Notification indicator. Notification information may be presented to the N-PISN if it is capable of receiving the notification.
12.7.2
Transmission of progress indications If provided with progress indications (e.g. if the B-PISN interworks with an N-PISN which in turn interworks with a non-ISDN), the Interworking PINX shall transmit Progress indicator information elements to the Preceding PINX in a PROGRESS message, an ALERTING message or a CONNECT message. A PROGRESS message shall be used unless an ALERTING or CONNECT message is to be sent at the time. PROGRESS shall not be sent as the first response to SETUP. Interworking with an N-PISN (without interworking with a further network) shall not cause a Progress indicator information element to be generated. For services which require an in-band tone or announcement to be supplied to the calling user during call establishment, the Interworking PINX is responsible for connecting the appropriate tone or announcement to the user plane virtual channel in the backwards direction, unless an appropriate tone or announcement is being provided by the N-PISN. If a tone or announcement is being provided either by the Interworking PINX or by the N-PISN, the Interworking PINX shall include a Progress indicator information element with CCITT progress description number 8 "in-band information or appropriate pattern now available" in the ALERTING or a PROGRESS message.
12.7.3
Transmission of CONNECT message If the N-PISN supplies a Low layer compatibility information element, the Interworking PINX shall pass the contents of the information element on unchanged as N-LLC information element in the CONNECT message.
12.7.4
Call/connection clearing initiated by the Interworking PINX Alternatively to clearing, for services for which an in-band tone or announcement is appropriate, the Interworking PINX may connect an in-band tone or announcement to the incoming user plane virtual channel and may optionally transmit a PROGRESS message containing a Progress indicator information element with CCITT progress description number 8 "in-band information or appropriate pattern now available" and an appropriate cause. A PROGRESS message containing a Progress indicator information element with CCITT progress description number 8 "in-band information or appropriate pattern now available" may also be sent in cases where the N-PISN has sent a corresponding indication..
- 54 -
In both cases: − If an indication of clearing has not been received from Protocol Control by the time the tone or announcement is complete or has been applied for sufficient time, the Interworking PINX shall instruct Protocol Control to initiate clearing. − The sending of the PROGRESS message is optional in the Active state, but mandatory in other states. NOTE 35 It is recommended that an in-band tone or announcement be provided by the Interworking PINX only if it conveys call/connection rejection or failure information which is not conveyable by signalling.
- 55 -
Annex A (normative)
Protocol Implementation Conformance Statement (PICS) proforma
A.1 A.1.1
Introduction Basic reference documents for PICS proforma specifications General rules for the specification of PICS proforma are provided by ISO/IEC 9646-1. Detailed guidance for the specification of PICS proforma is provided by ISO/IEC 9646-7; in particular the structure of a PICS proforma, the questions to be asked, the syntax and notation to be used and the semantics of the questions and expected answers. For a PICS proforma, specific acronyms and terms are used as defined in ISO/IEC 9646-1 or ISO/IEC 9646-7, e.g.:
A.1.2
− ICS
Implementation Conformance Statement
− ICS proforma
Implementation Conformance Statement proforma
− ICS (proforma) item
A row in an ICS (proforma) table
− PICS
Protocol ICS
− PICS proforma
Protocol ICS proforma
− status (value)
An allowed entry in the status column for an item in an ICS proforma table
− (support) answer
An allowed entry in the support or supported values columns for an item in an ICS question
Copyright Information Users of this specification may freely reproduce the PICS proforma of this annex A so that it can be used for its intended purpose and may further publish the completed PICS.
A.1.3
Structure of this PICS proforma This PICS proforma is subdivided into (sub-)clauses as follows: − Instructions (A.2) − Purpose of a PICS proforma (A.2.1) − Instructions for completing the PICS proforma (A.2.2) − Additional Information (A.2.3) − Exception Information (A.2.4) − Legend for the columns of the PICS proforma tables (A.2.5) − Legend for further indications of the PICS proforma tables (A.2.6) − Identification of the implementation (A.3), including: − Identification of the protocol for which this PICS applies (A.3.7) − Global statement of conformance (A.4) − Roles (A.5) − Service and Addressing Capabilities (A.6) − Protocol Control Procedures and Error Handling (A.7)
- 56 -
− Call/Connection Handling (A.8) − Restart Procedures (A.9) − Timers (A.10) − Sending and Receipt of Protocol Data Units (A.11)
A.2 A.2.1
Instructions Purpose of a PICS proforma To evaluate conformance of a particular implementation, it is necessary to have a statement of which capabilities and options have been implemented for a given OSI specification. Such a statement is called an Implementation Conformance Statement (ICS). For protocol specifications, this statement is called "Protocol Implementation Conformance Statement" (PICS). For the provision of this statement, a fixed format questionnaire called PICS proforma has to be used. A completed PICS proforma is the PICS for the implementation in question. It is an ICS (as defined in ISO/IEC 9646-7) for an implementation or system which claims to conform to a given specification. The PICS can have a number of uses, including: − by the protocol implementor, as a check list for implementations to reduce the risk of unintended nonconformance, e.g. through oversight; − by the supplier and acquirer, or potential acquirer, of the implementation, as a detailed indication of the capabilities of the implementation, stated relative to the common basis for understanding provided by the Standard's PICS proforma; − by the user or potential user of the implementation, as a basis for initially checking the possibility of interworking with another implementation - while interworking can never be guaranteed, failure to interwork can often be predicted from incompatible PICS − by a protocol tester, as the basis for selecting appropriate tests against which to assess the claim for conformance of the implementation. The PICS proforma of this annex therefore reflect a compromise between these different requirements.
A.2.2
Instructions for completing the PICS proforma The supplier of a protocol implementation which is claimed to conform to this Standard shall complete the following Protocol Implementation Conformance Statement (PICS) proforma. The PICS proforma is a fixed format questionnaire. The supplier of the implementation shall complete this questionnaire, in particular identify the implementation, complete the global statement of conformance, and providing the answers in the rows of the tables in clauses A.5 - A.11. The structure of the tables is explained in subclauses A.2.5 and A.2.6. For each row in each table, the supplier shall enter an explicit answer (i.e. by ticking the appropriate "yes", "no", or "N/A" in each of the support column boxes provided. Where a support column box is left blank, or where it is marked "N/A" without any tick box, no answer is required. If a "prerequisite line" (see A.2.6 below) is used after a subclause heading or table title, and its predicate is false, no answer is required for the whole sublause or table, respectively. A supplier may also provide - or be required to provide - further information, categorized as either Additional Information or Exception Information. When present, each kind of further information is to be provided in a further subclause of items labelled "a.<i>"
for additional information,
"x.<i>" for exceptional information for cross-referencing purposes, where <i> is any unambiguous identification for the item (e.g., simply a numeral); there are no other restrictions on its format and presentation.
- 57 -
A.2.3
Additional Information Items of Additional Information allow a supplier to provide further information intended to assist the interpretation of the PICS. It is not intended or expected that a large quantity will be supplied, and a PICS can be considered complete without any such information. Examples might be an outline of the ways in which a (single) implementation can be set up to operate in a variety of environments and configurations. References to items of Additional Information may be entered next to any answer in the questionnaire, and may be included in items of Exception information.
A.2.4
Exception Information It may occasionally happen that a supplier will wish to answer an item with mandatory or prohibited status (after any conditions have been applied) in a way that conflicts with the indicated requirement. No pre-printed answer will be found in the Support column for this. Instead, the supplier is required to write into the support column an x.<i> reference to an item of Exception Information, and to provide the appropriate rationale in the Exception item itself. An implementation for which an Exception item is required in this way does not conform to this Standard; and the answer to the global statement of conformance (see A.4) cannot be "yes". A possible reason for the situation described above is that a defect in the Standards has been reported, a correction for which is expected to change the requirement not met by the implementation.
A.2.5
Legend for the columns of the PICS proforma tables The questionnaire in clauses A.5-A.11 is structured as a set of tables in accordance with the guidelines presented in ISO/IEC 9646-7. The columns of the tables shall be interpreted as follows: "Item" The item column contains a unique reference (a mnemonic plus a number) for each item within the PICS proforma. Items need not always be numbered sequentially. "Item Description" The item description column contains a brief summary of the static requirement for which a support answer is required. This may be done by a question or a reference to a specific feature. "Conditions for Status" The conditions for status column contains a specification, if appropriate, of the predicate upon which a conditional status is based. The indication of an item reference in this column indicates a simple-predicate condition (support of this item is dependent on the support marked for the referenced item). Within the "conditions for status" column, the logical symbol "]" is used to indicate a logical negation ("NOT"). "Status" The following notations, as defined in ISO/IEC 9646-7, are used for the status column: I
Irrelevant or out-of-scope - this capability is outside the scope of the Standard to which this PICS proforma applies and is not subject to conformance testing in this context.
M
Mandatory - the support of this capability is required for conformance to the Standard.
N/A
Not Applicable - in the given context, it is impossible to use the capability. No answer in the support column is required.
O
Optional - the capability is not required for conformance to the protocol and may be supported or not. However, if the capability is implemented, it is required to conform to the protocol specifications.
O.<n>
Qualified optional - in this case, <n> is an integer that identifies a unique group of related optional items. If no additional qualification is indicated, the support of at least one of the optional items is required for conformance to the Standard. Otherwise, the qualification and logic of the selection among the optional items is defined below the table explicitly.
- 58 -
X
eXcluded or prohibited - there is a requirement not to use this capability in a given context.
"Reference" Except where explicitly stated, the reference column refers to the appropriate subclause(s) of this Standard describing the particular item. The reference merely indicates the place(s) where the core of a description of an item can be found; additional information on this item may be contained in other parts of this Standard, and has to be taken into account when making a statement about the conformance to that particular item. "Support " In the support column, the supplier of the implementation shall enter an explicit answer. The following notation is used: [ ] Yes
[No]
[ ] N/A
Tick "yes", if item is supported; tick "No", if item is not supported. Tick "N/A", if the item is "not applicable".
In specific cases, the indication of explicit values may be requested. Where a support column box is left blank, or where it is marked "N/A" without any tick box, no answer is required.
A.2.6
Legend for further indications of the PICS proforma tables In addition to the columns of a table, the following information may be indicated: "Prerequisite line" A prerequisite line after a subclause heading or table title indicates that the whole subclause or the whole table is not required to be completed if the predicate is false. The prerequisite line takes the form: Prerequisite:<predicate>. "Qualification" At the end of a table, a detailed qualification for a group of optional items may be indicated, as specified in the description of the status "qualified optional" in subclause A.2.5. "Comments" This box at the end of a table allows a supplier to enter any comments to that table. Comments may also be provided separately (without using this box).
A.3
Identification of the implementation Identification of the implementation and the system in which it resides should be filled in to provide as much detail as possible regarding version numbers and configuration options. The implementation about which this PICS proforma asks questions corresponds to a B-QSIG BC implementation at the Q reference point. Configuration options outlined in B-QSIG BC have been incorporated into this PICS proforma. They are referred to by qualified options or prerequisite lines, in order to reflect that an implementation only needs to provide the addressed functions at an interface, if it is configured accordingly (e.g. an implementation only needs to provide gateway call handling functions, if it is configured to act as gateway PINX at an interface). The contact person indicated (see A.3.6) should be able to answer queries regarding information supplied in the PICS. As specified in clause 5 of ISO/IEC 9646-7, it is required for all implementations to at least provide the identification of the implementation (A.3.2), product supplier information (A.3.4), identification of a contact person (A.3.6), and detailed identification of the protocol for which the PICS applies (A.3.7). Identification of the system in which the implementation resides (A.3.3) is recommended in order to facilitate full identification of the system, and avoid
- 59 -
possible problems during conformance testing. The client information (A.3.5) only needs to be filled in if it is relevant and different from the product supplier information.
A.3.1
Date of statement ___________________________________________________________________________________
A.3.2
Identification of the implementation The terms "name" and "version" should be interpreted appropriately to correspond with a suppliers terminology (e.g. Type, Series, Model). Name of the implementation: ___________________________________________________________________________________ ___________________________________________________________________________________ Implementation version: ___________________________________________________________________________________ ___________________________________________________________________________________
A.3.3
Identification of the system in which it resides Name of the system: ___________________________________________________________________________________ ___________________________________________________________________________________ Hardware configuration: ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________ Operating system: ___________________________________________________________________________________ ___________________________________________________________________________________
A.3.4
Product supplier Name: ___________________________________________________________________________________ Address: ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________ Telephone number: ___________________________________________________________________________________ Facsimile number: ___________________________________________________________________________________ E-Mail address: ___________________________________________________________________________________
- 60 -
Additional information: ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________
A.3.5
Client Name: ___________________________________________________________________________________ Address: ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________ Telephone number: ___________________________________________________________________________________ Facsimile number: ___________________________________________________________________________________ E-Mail address: ___________________________________________________________________________________ Additional information: ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________
A.3.6
PICS contact person Name: ___________________________________________________________________________________ Address: ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________ Telephone number: ___________________________________________________________________________________ Facsimile number: ___________________________________________________________________________________ E-Mail address: ___________________________________________________________________________________ Additional information: ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________
- 61 -
A.3.7
Protocol for which this PICS applies Protocol: B-QSIG BC - B-PISN inter-exchange signalling protocol - basic call/connection control Protocol Version - please identify the standards document unambiguously, including e.g. reference number (ECMA-266), edition number (if applicable) and publication date: ___________________________________________________________________________________ ___________________________________________________________________________________ Corrigenda Implemented (if applicable): ___________________________________________________________________________________ ___________________________________________________________________________________ Addenda Implemented (if applicable): ___________________________________________________________________________________ ___________________________________________________________________________________ Amendments Implemented (if applicable): ___________________________________________________________________________________ ___________________________________________________________________________________
A.4
Global Statement of Conformance Does the implementation described in this PICS meet all the mandatory requirements of the referenced standard: [ ]
Yes
[ ]
No
NOTE A.1 Answering "No" to this question indicates non-conformance to the protocol specification. In this case, an explanation shall be given of the nature of non-conformance either below or on a separate sheet of paper. Further the instructions outlined in subclause A.2.4 ("Exception Information") shall be followed when completing the PICS proforma tables. Nature of non-conformance (if applicable): ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________ ___________________________________________________________________________________
- 62 -
A.5
Roles The concept of roles is illustrated in subclause 8.5.2 of ISO/IEC 9646-7. For implementations, it is required to identify which roles are supported. Roles are used in PICS proformas as predicates for the "conditions for status" column if an item is conditional upon the role(s) supported. Table A-1 - Roles Reference
Support
O.1
12.1
[ ]Yes [ ]No
functioning as an originating PINX?
O.1
12.2
[ ]Yes [ ]No
Role3
functioning as a terminating PINX?
O.1
12.3
[ ]Yes [ ]No
Role4
functioning as an incoming gateway PINX?
O.1
12.4
[ ]Yes [ ]No
Role5
functioning as an outgoing gateway PINX?
O.1
12.5
[ ]Yes [ ]No
Role6
functioning as an Interworking PINX for N-PISN -> B-PISN interworking?
Role4
O
12.6
[ ]Yes [ ]No
] Role4
N/A
functioning as an Interworking PINX for B-PISN -> N-PISN interworking?
Role5
O
] Role5
N/A
0
Roles Is the implementation capable of ...
Role1
functioning as a transit PINX?
Role2
Role7
Conditions for Status status
[ ]N/A 12.7
[ ]Yes [ ]No [ ]N/A
Comments:
A.6 A.6.1
Service and addressing capabilities Support of bearer capabilities and ATM transfer capabilities NOTE A.2 For the detailed specification of bearer capabilities and ATM transfer capabilities, see ATM Forum UNI 4.0, annex 9.
- 63 -
Table A-2 - ATM transfer capabilities Item
Bearer or ATM transfer capability Does the implementation support...
ATC1
CBR.1 ATM transfer capability?
ATC2 ATC2.1
Conditions for Status status
Reference
Support
M
8.5.9, 8.5.10
[ ]Yes [ ]No
Real-Time VBR ATM transfer capability?
O
8.5.9, 8.5.10
[ ]Yes [ ]No
Real-Time VBR.1 ATM transfer capability? ATC2
O.2
8.5.9, 8.5.10
[ ]Yes [ ]No
] (ATC2) ATC2.2
Real-Time VBR.2 ATM transfer capability? ATC2. ] (ATC2)
ATC2.3
Real-Time VBR.3 ATM transfer capability? ATC2. ] (ATC2)
ATC3
Non-Real-Time VBR ATM transfer capability?
ATC3.1
Non-Real-Time VBR.1 ATM transfer capability?
ATC3.2
ATC3.3
N/A O.2
[ ]N/A 8.5.9, 8.5.10
N/A O.2
[ ]Yes [ ]No [ ]N/A
8.5.9, 8.5.10
N/A
[ ]Yes [ ]No [ ]N/A
O
8.5.9, 8.5.10
[ ]Yes [ ]No
ATC3
O.3
8.5.9, 8.5.10
[ ]Yes [ ]No
] (ATC3)
N/A
Non-Real-Time VBR.2 ATM transfer capability?
ATC3
O.3
] (ATC3)
N/A
Non-Real-Time VBR.3 ATM transfer capability?
ATC3
O.3
] (ATC3)
N/A
[ ]N/A 8.5.9, 8.5.10
[ ]Yes [ ]No [ ]N/A
8.5.9, 8.5.10
[ ]Yes [ ]No [ ]N/A
ATC4
ABR ATM transfer capability?
O
8.5.9, 8.5.10
[ ]Yes [ ]No
ATC5
UBR ATM transfer capability?
O
8.5.9, 8.5.10
[ ]Yes [ ]No
ATC5.1
UBR.1 ATM transfer capability?
ATC5
O.4
8.5.9, 8.5.10
[ ]Yes [ ]No
] (ATC5)
N/A
ATC5
O.4
] (ATC5)
N/A
ATC5.1
UBR.2 ATM transfer capability?
[ ]N/A 8.5.9, 8.5.10
[ ]Yes [ ]No [ ]N/A
ATC6
Other ATM transfer capabilities for backward compatibility with earlier ATM Forum specifications?
O
8.5.9, 8.5.10
[ ]Yes [ ]No
BC1
Bearer Class BCOB-A?
O
8.5.9, 8.5.10
[ ]Yes [ ]No
BC2
Bearer Class BCOB-C?
O
8.5.9, 8.5.10
[ ]Yes [ ]No
BC3
Bearer Class BCOB-X?
O
8.5.9, 8.5.10
[ ]Yes [ ]No
BC4
the switched virtual path (VP) service?
O
8.5.9, 8.5.10
[ ]Yes [ ]No
BC5
soft PVPCs? (NOTE)
O
Annex B
[ ]Yes [ ]No
BC6
soft PVCCs? (NOTE)
O
Annex B
[ ]Yes [ ]No
BC7
the frame diiscard option?
O
8.5.9, 8.5.10
[ ]Yes [ ]No
Conn1
point-to-point connections?
M
9, 8.5.10
[ ]Yes [ ]No
Conn2
point-to-multipoiint connections?
O
10, 8.5.10
[ ]Yes [ ]No
- 64 -
Comments:
NOTE. In case of support of these capabilities, it is recommended that responses to additional PICS proforma questions on these capabilities, as currently drafted by the ATM Forum PNNI group, are completed and attached as well.
A.6.2
Emulated 64 kbit/s-based bearer services supported NOTE A.2 For the detailed specification of the 64 kbit/s based bearer services, see ECMA-143. Table A-3 - Emulated 64 kbit/s-based service capabilities
Item
N-PISN service emulation capability Does the implementation support...
Conditions for Status status
Reference
Support
NEmu1
emulation of 64 kbit/s unrestricted bearer services?
Role6 OR Role7
O.5
11, 8.6.1
[ ]Yes [ ]No
] (Role6 OR Role7)
O
Role6 OR Role7
O.5
] (Role6 OR Role7)
O
Role6 OR Role7
O.5
] (Role6 OR Role7)
O
NEmu2
NEmu3
NEmu4 Comments:
emulation of 64 kbit/s bearer services with speech transfer capability?
emulation of 64 kbit/s bearer services with3.1 kHz audio transfer capability?
emulation of nx64 kbit/s multirate bearer services?
O
[ ]Yes [ ]No 11, 8.6.1
[ ]Yes [ ]No [ ]Yes [ ]No
11, 8.6.1
[ ]Yes [ ]No [ ]Yes [ ]No
11, 8.6.1
[ ]Yes [ ]No
- 65 -
A.6.3
Addressing capabilities supported Table A-4 - Addressing Capabilities
Item
Addressing capability Does the implementation support...
Addr1
IA5-addressing based on the B-ISDN numbering plan (ITU-T Rec. E.164 / E.191)?
Addr2
ATM end system addressing based on 20 octet OSI-NSAP formats (ISO/IEC 8348) with AFIs 39 (DCC), 47 (ICD), and 45 (encapsulated E.164),?
Addr2.1
ATM end system addressing based on 20 octet OSI-NSAP formats (ISO/IEC 8348) with AFI 49 (local) ?
Addr3
Reference
Support
O
8.5.16, 8.5.18, 8.5.21
[ ]Yes [ ]No
M
8.5.16, 8.5.18, 8.5.21
[ ]Yes [ ]No
O
8.5.16, 8.5.18, 8.5.21
[ ]Yes [ ]No
IA5 addressing according to a private numbering plan?
O
8.5.16, 8.5.18, 8.5.21
[ ]Yes [ ]No
Addr4
implicit numbering (numbering plan "unknown")?
O
8.5.16, 8.5.18, 8.5.21
[ ]Yes [ ]No
Addr5
the anycast addressing capability?
M
8.5.16, 8.5.xx
[ ]Yes [ ]No
Comments:
Conditions for Status status
Addr2
- 66 -
A.7
Protocol control procedures and error handling
A.7.1
Procedures for successful call/connection establishment and release Table A-5 - Establishment and release capabilities
Item
Establishment and release capability Does the implementation...
Conditions for Status status
Reference
Support
EstR1
support procedures for call/connection establishment at the preceding side?
c.1
M
9.2
[ ]Yes [ ]No
] (c.1)
N/A
include the complete called party number information and the Broadband sending complete information element, in case of a B-PISN specific service?
c.1
O
] (c.1)
N/A
retransmit the SETUP message upon expiry of timer T303?
c.1
O
] (c.1)
N/A
For non-VP-associated signalling,: is the implementation capable to generally select and request an IIPVPI/PVCI value in the SETUP message exclusively?
c.1
M
] (c.1)
N/A
EstR1.1
EstR1.2
EstR1.3
EstR1.4
EstR1.4.1
EstR1.4..2
EstR1.5
EstR1.6
EstR1.7
EstR2
EstR2.1
For non-VP-associated signalling: s the c.1 implementation capable of being configured ] (c.1) to act as the non-selecting side with regard to IPVPI/IPVCI selection?
O
If acting as non-selecting side, is the implementarion capable of indicating exclusive IPVPI, any IPVCI
EstR1.4
O.6
] (EstR1.4)
N/A
If acting as non-selecting side, is the implementarion capable of sending the SETUP message without including the Connection identifier IE?
EstR1.4
O.6
] (EstR1.4)
N/A
For VP-associated signalling, is the implementation capabile of indicating exclusive IPVPI, any IPVCI?
c1 AND EstR4
O.7
] (c1 AND EstR4)
N/A
For VP-associated signalling, is the implementation capabile of indicating exclusive IPVPI, exclusive IPVCI?
c1 AND EstR4
O.7
] (c1 AND EstR4)
N/A
[ ]N/A 9.2
[ ]N/A
9.2
O
supprt procedures for call/connection establishment at the succeeding side?
c.2
M
] (c.2)
N/A
Is the implementation capable of being configured to act as the selecting side with regard to IPVPI/IPVCI selection?
c.2
O
] (c.2)
N/A
[ ]Yes [ ]No [ ]N/A
9.2
[ ]Yes [ ]No [ ]N/A
9.2
N/A
If there is no End-to-end transit delay c.1 information element in the received SETUP ] (c.1) message, does the preceding side generate an End-to-end transit delay information element?
[ ]Yes [ ]No
[ ]Yes [ ]No [ ]N/A
9.2
[ ]Yes [ ]No [ ]N/A
9.2
[ ]Yes [ ]No [ ]N/A
9.2
[]Yes [ ]No [ ]N/A
9.2
[]Yes [ ]No [ ]N/A
9.2
N/A
[ ]Yes [ ]No [ ]N/A
9.2
[ ]Yes [ ]No [ ]N/A
9.2
[ ]Yes [ ]No [ ]N/A
- 67 -
EstR3
support call clearing procedures
M
9.3
[ ]Yes [ ]No
EstR3.1
Is the implementation capable of creating and inserting a second Cause IE with cause #102 into a (retransmitted) RELEASE message?
O
9.3
[ ]Yes [ ]No
EstR3.1.1
support always inserting a second Cause IE with cause #102 into a retransmitted RELEASE message?
EstR3.1
O
9.3
[ ]Yes [ ]No
] (EstR3.1)
N/A
[ ]N/A
EstR4
support procedures for VP-associated signalling?
O
9.2
[ ]Yes [ ]No
EstR5
support procedures for negotiation of ATM traffic descriptors?
O
9.2
[ ]Yes [ ]No
EstR6
support the transfer of the Generic identifier transport information element?
O
9.2, 8.5.xx
[ ]Yes [ ]No
Comments:
c.1: Role1 OR Role2 OR Role4 OR Role6 c.2: Role1 OR Role3 OR Role5 OR Role7
- 68 -
A.7.2
Handling of Error Conditions Table A-6 - Error handling capabilities
Item
Error handling capability Does the implementation support...
Err0
the procedures for the resolution of call/connection collisions?
Err0.1
the use of cause # 47 in case of call/connectioncollisions?
Err0.2
Reference
Support
M
9.4
[ ]Yes [ ]No
Err0
O.8
9.4
[ ]Yes [ ]No
the use of cause #49 in case of call/connection collisions?
Err0
O.8
9.4
[ ]Yes [ ]No
Err0.3
the use of cause #51 in case of call/connection collisions?
Err0
O.8
9.4
[ ]Yes [ ]No
Err1
handling of protocol discrimination errors?
M
9.6
[ ]Yes [ ]No
Err2
handling of call reference errors?
M
9.6
[ ]Yes [ ]No
Err3
handling of message type or message sequence errors?
M
9.6
[ ]Yes [ ]No
Err3.1
the use of cause # 97 in a STATUS message Err3 returned in case of the receipt of an unexpected message?
O.9
9.6
[ ]Yes [ ]No
Err3.2
the use of cause # 101 in a STATUS Err3 message returned in case of the receipt of an unexpected message?
O.9
9.6
[ ]Yes [ ]No
Err4
handling of general information element errors?
M
9.6
[ ]Yes [ ]No
Err5
handling of mandatory information element errors?
M
9.6
[ ]Yes [ ]No
Err6
handling of non-mandatory information element errors (flag bit in instruction field =0)?
M
9.6
[ ]Yes [ ]No
Err7
error procedures with explicit action indication (flag bit in instruction field =0)?
M
9.7
[ ]Yes [ ]No
Err8
handling of messages with insufficient information?
M
9.8
[ ]Yes [ ]No
Err9
procedures in case of a spontaneous signalling AAL reset?
M
9.6
[ ]Yes [ ]No
Err9.1
Does the implementation invoke a status enquiry procedure for calls/connections in the establishment phase, if being informed of a spontaneous S-AAL reset?
O
9.6
[ ]Yes [ ]No
Err10
procedures in case of a signalling AAL connection release?
M
9.6
[ ]Yes [ ]No
Comments:
Conditions for Status status
- 69 -
A.7.3
Status and Status Enquiry Protocol Procedures Table A-7 - Status and status enquiry capabilities
Item
Status and status enquiry capability Does the implementation...
Stat1
support the status enquiry procedure?
Stat1.1
retransmit the STATUS ENQUIRY message in case of expiry of timer T322?
Stat1.1.1
Number of times the STATUS ENQUIRY message is retransmitted?
Conditions for Status status
Reference
Support
M
9.6
[ ]Yes [ ]No
O
9.6
[ ]Yes [ ]No
Stat1.1
M
9.6
] (Stat1.1)
N/A
Value:____ _ [ ]N/A
Stat2
support the procedures for receiving an unsolicited STATUS message?
M
9.6, 9.6.1
[ ]Yes [ ]No
Reference
Support
Comments:
A.7.4
Notification procedures Table A-8 - Notification capabilities
Item
Notification capability Does the implementation support...
Notf1
the generic notification procedures?
M
9.8
[ ]Yes [ ]No
Notf2
the procedures for the notification of interworking?
M
9.9
[ ]Yes [ ]No
Notf2.1
the procedures for the handling of progress indicatore for B-PISN specific services?
Notf2
M
9.9, 8.5.32, 9.2.1
[ ]Yes [ ]No
Notf2.2
the procedures for the handling of progress indicators for N-ISDN circuit mode services?
Notf2
M
9.9, 8.6.4, 9.2.1 [ ]Yes [ ]No
Notf2.2.1
the progress indicator No. 4 for N-ISDN circuit mode services?
Notf2.2
O
9.9
Comments:
Conditions for Status status
[ ]Yes [ ]No
- 70 -
A.7.5
Protocol control procedures for the support of N-PISN services Table A-9 - N-PISN service support capabilities Prerequisite: (NEmu1 OR NEmu2 OR NEmu3 OR NEmu4)
Item
N-PISN service support capability Does the implementation ..
NPS1
support the additional specifications for the call/connection establishment and release for N-PISN services
NPS2
support the interworking PINX procedures for a call originated in an N-PISN?
NPS3
NPS4
NPS5
NPS5.1
NPS6
Reference
Support
M
11.1, 11.2
[ ]Yes [ ]No
Role6
M
11.3
[ ]Yes [ ]No
] (Role6)
N/A
support the interworking PINX protocol procedures for a call originated in B-PISN?
Role7
M
] (Role7)
N/A
include a Sending complete IE in every generated SETUP message for an N-PISN service?
c.1
O
] (c.1)
N/A
support the preceding side procedures for overlap sending?
c.1 AND (] NPS4)
M
(] c.1) OR NPS4
N/A
insert the Broadband sending complete IE in NPS5 the INFORMATION message, if it ] (NPS5) determines that this message contains the last digit(s) of the called party number?
O
support the succeeding side procedures for overlap sending?
c.2
M
] (c.2)
N/A
NPS7
support transfer of call progress information for notification of interworking?
NPS7.1
support mapping of call progress information?
NPS8
NPS9
Conditions for Status status
provide tones and announcements during call establishment? support procedures for tones and announcements in the course of call clearing?
Comments:
c.1: Role1 OR Role2 OR Role4 OR Role6 c.2: Role1 OR Role3 OR Role5 OR Role7
[ ]N/A 11.4
[ ]Yes [ ]No [ ]N/A
11.5
[ ]Yes [ ]No [ ]N/A
11.5.1
[ ]Yes [ ]No [ ]N/A
11.5.1
N/A
[ ]Yes [ ]No [ ]N/A
11.5.2
[ ]Yes [ ]No [ ]N/A
M
11.6
[ ]Yes [ ]No
Role6 OR Role7
M
11.6
[ ]Yes [ ]No
] (Role6 OR Role7)
N/A
c.2
O
] (c.2)
N/A O
[ ]N/A 11.7.1
[ ]Yes [ ]No [ ]N/A
11.7.2
[ ]Yes [ ]No
- 71 -
A.8
Call/connection handling procedures
A.8.1
Call/connection handling functions for a transit PINX Table A-10 - Transit call/connection handling capabilities Prerequisite: Role1
Item
Transit call/conn. handling capability Does the implementation.support ..
TCH1
transit PINX call handling procedures during call/connection establishment?
TCH2
Reference
Support
M
12.1.1-12.1.6
[ ]Yes [ ]No
procedures for call/connection clearing not inititated by the transit PINX?
M
12.1.7.1
[ ]Yes [ ]No
TCH3
procedures for inititating call/connection clearing in both directions?
O
12.1.7.2
[ ]Yes [ ]No
TCH4
additional transit PINX call handling procedures for the support of N-PISN services?
c.3
M
12.1.8
[ ]Yes [ ]No
] (c.3)
N/A
TCH4.1
Conditions for Status status
[ ]N/A
call handling procedures for processing and TCH4 forwarding a received PROGRESS message ] (TCH4) in state TCC_Call_Active?
O.5
procedures for discarding a received TCH4 PROGRESS message in state ] (TCH4) TCC_Call_Active without sending a PROGRESS message to the adjacent PINX?
O.5
TCH5
handling of basic call information elements, including the use of categories for nonmandatory information elements?
M
12.1.9
[ ]Yes [ ]No
TCH6
procedures for processing end-to-end transit delay information?
M
12.1.1
[ ]Yes [ ]No
TCH4.2
Comments:
c.3: NEmu1 OR NEmu2 OR NEmu3 OR NEmu4 O.5: the two options are mutually exclusive; TCH4.2 is not recommended.
12.1.8.6
N/A
[ ]Yes [ ]No [ ]N/A
12.1.8.6
N/A
[ ]Yes [ ]No [ ]N/A
- 72 -
A.8.2
Specific call/connection handling procedures Table A-11 - Specific call/connection handling capabilities
Item
Specific call/conn. handling capability Does the implementation support...
Conditions for Status status
Reference
Support
SpCH1
call/connection handling procedures for an originating PINX?
Role2
M
12.2
[ ]Yes [ ]No
] (Role2)
N/A
call/connection handling procedures for a terminating PINX?
Role3
M
] (Role3)
N/A
call/connection handling procedures for an incoming gateway PINX?
Role4
M
] (Role4)
N/A
call/connection handling procedures for an outgoing gateway PINX?
Role5
M
] (Role5)
N/A
call/connection handling procedures for an interworking PINX for N-PISN -> B-PISN interworking?
Role6
M
] (Role6)
N/A
SpCH2
SpCH3
SpCH4
SpCH5
SpCH5.1
SpCH6
SpCH6.1
Comments:
sending a PROGRESS message with SpCH5 progress description 8 in the Active protocol ] (SpCH5) state as an alternative initiation of call/connection clearing?
O
call/connection handling procedures for an interworking PINX for B-PISN -> N-PISN interworking?
Role7
M
] (Role7)
N/A
sending a PROGRESS message with SpCH6 progress description 8 in the Active protocol ] (SpCH6) state as an alternative initiation of call/connection clearing?
[ ]N/A 12.3
[ ]N/A 12.4
N/A
[ ]Yes [ ]No [ ]N/A
12.5
[ ]Yes [ ]No [ ]N/A
12.6
[ ]Yes [ ]No [ ]N/A
12.6.5
N/A
O
[ ]Yes [ ]No
[ ]Yes [ ]No [ ]N/A
12.7
[ ]Yes [ ]No [ ]N/A
12.7.5
[ ]Yes [ ]No [ ]N/A
- 73 -
A.9
Restart Procedures Table A-12 - Restart capabilities
Item
Restart capability Does the implementation support ...
Rest1.1
initiation of restart procedures for a single IPVC (class 0)?
Rest1.2
Reference
Support
O
9.5, 8.5.29
[ ]Yes [ ]No
initiation of restart procedures for all virtual channels in the indicated IPVP (class 1)?
O
9.5, 8.5.29
[ ]Yes [ ]No
Rest1.3
initiation of restart procedures for all virtual channels (class 2)?
O
9.5, 8.5.29
[ ]Yes [ ]No
Rest2
retransmit the RESTART message in case of c.6 expiry of timer T316? ] (c.6)
M
9.5
[ ]Yes [ ]No
Number of times the RESTART message is retransmitted?
Rest2
M
] (Rest2)
N/A
Rest2.1
Conditions for Status status
N/A
[ ]N/A 9.5
Value: _____ [ ]N/A
Rest3.1
procedures upon receiving a RESTART message, indicating an IPVC (class 0)?
M
9.5, 8.5.29
[ ]Yes [ ]No
Rest3.2
procedures upon receiving a RESTART message, indicating all virtual channels in the indicated IPVP (class 1)?
M
9.5, 8.5.29
[ ]Yes [ ]No
Rest3.3
procedures upon receiving a RESTART message, indicating all virtual channels (class 2)?
M
9.5, 8.5.29
[ ]Yes [ ]No
Rest4
procedures on receipt of a RESTART message, implicitly or explicitly specifying semi-permanent connections or non-existent IPVPs or IPVCs?
M
9.5, 8.5.29
[ ]Yes [ ]No
Rest4.1
Is the implementation capable of sending a STATUS message with the global call reference and cause #82 in case of the receipt of a RESTART message explicitly specifying semi-permanent connections or non-existent IPVPs or IPVCs?
O
9.5
[ ]Yes [ ]No
Comments:
c.6: Rest1.1 OR Rest1.2 OR Rest1.3
- 74 -
A.10 Timers Table A-13 - Timer capabilities Item
TImer capability Does the implementation support ...
Conditions for Status status
Reference
Support
Tim1
Timer T301?
c.1
M
9.11
[ ]Yes [ ]No
] (c.1)
N/A
Which value or range of values of Timer T301 (in seconds >= 180) has been implemented)?
Tim1
M
] (Tim1)
N/A
Is an internal alerting supervision timing function used, e.g. incorporated within call/connection handling?
c.1
O
] (c.1)
N/A
Timer T302?
c.5
M
] (c.5)
N/A
c.1
M
] (c.1)
N/A
c.4 AND (] NPS4)
M
(] c.4) OR NPS4
N/A
Tim1.1
Tim1.2
Tim2
Tim3
Tim4
Timer T303?
Timer T304?
[ ]N/A 9.11
Value/Range: ______ [ ]N/A
9.11
[ ]Yes [ ]No [ ]N/A
9.11
[ ]Yes [ ]No [ ]N/A
9.11
[ ]Yes [ ]No [ ]N/A
9.11, 11.5.1
[ ]Yes [ ]No [ ]N/A
Tim5
Timer T308?
M
9.11
[ ]Yes [ ]No
Tim6
Timer T309?
M
9.11
[ ]Yes [ ]No
Tim7
Timer T310?
c.1
M
9.11
[ ]Yes [ ]No
] (c.1)
N/A
Which value or range of values of Timer T310 (in seconds between 30 and 120) has been implemented)?
Tim7
M
] (Tim7)
N/A
Timer T316?
c.6
M
] (c.6)
N/A
Stat1
M
] (Stat1)
N/A
c.6
M
] c.6
N/A
Tim10
M
] (Tim10)
N/A
Tim7.1
Tim8
Tim9
Tim10
Tim10.1
Comments:
Timer T322?
Timer T317?
Which value or range of values of Timer T317 (in seconds) has been implemented)?
[ ]N/A 9.11
Value/Range: ______ [ ]N/A
9.11
[ ]Yes [ ]No [ ]N/A
9.11
[ ]Yes [ ]No [ ]N/A
9.11
[ ]Yes [ ]No [ ]N/A
9.11
Value/Range: ______ [ ]N/A
- 75 -
c.1: Role1 OR Role2 OR Role4 OR Role6 c.2: Role1 OR Role3 OR Role5 OR Role7 c.3: NEmu1 OR NEmu2 OR NEmu3 OR NEmu4 c.4: c.1 AND c.3 c.5: c.2 AND c.3 c.6: Rest1.1 OR Rest1.2 OR Rest1.3
- 76 -
A.11 Sending and Receipt of PDUs Table A-14 - PDU handling capabilities Item
PDU handling capability Does the implementation support ...
PDU1
sending of messages, including for each message those information elements marked as mandatory for that message, in accordance with procedures supported?
PDU2
PDU3
Conditions for Status status
Reference
Support
M
7
[ ]Yes [ ]No
receipt of messages in accordance with the procedures supported and receipt of all the per-mitted information elements in those messages?
M
7
[ ]Yes [ ]No
formats and codings for messages and information elements supported?
M
8
[ ]Yes [ ]No
Comments:
A.12 Complementary Configuration Information Table A-15 - Complementary configuration information Item
Complementary configuration information
Conditions for Status status
Reference
Support
Does the implementation support ... Cfig1
the use of IPVPI=0, IPVCI=5 for non-VPassociated signalling as a default?
M
6
[ ]Yes [ ]No
Cfig1.1
the use of other or additional IPVPI/IPVICI values for non-VP-associated signalling?
O
6
[ ]Yes [ ]No
Cfig2
the use of IPVCI=5 for VP-associated signalling as a default?
EstR4
M
6
[ ]Yes [ ]No
Cfig2.1
the use of other or additional IPVICI values EstR4 for non-VP-associated signalling?
O
6
[ ]Yes [ ]No
Comments:
- 77 -
Annex B (normative)
Soft permanent virtual connection procedures
Annex C of PNNI 1.0 applies.
- 78 -
- 79 -
Annex C (informative)
Mapping functions to support 64 kbit/s based circuit-mode PISN services in B-PISNs and interworking between N-PISNs and B-PISNs (QSIG/B-QSIG)
This annex shows examples of the functions to be performed by an Interworking PINX.
Mapping functions for the direction B-QSIG → QSIG
C.1
The mapping functions performed by the Interworking PINX for the direction from B-QSIG to QSIG are illustrated by the examples given below. These examples are not exhaustive. The same mapping principles also apply for other circuit-switched N-PISN services. The Interworking PINX will relay the content of the N-BC, N-LLC and N-HLC information elements transparently to the N-PISN. No further processing is required, except for the changes needed to accommodate the different coding rules. The B-BC, ATM traffic descriptor, QOS parameter, End-to-end transit delay, OAM traffic descriptor and AAL parameters information elements are discarded.
C.1.1
A B-PISN user requests the 3.1 kHz audio N-PISN bearer service Table C-1 - Mapping performed by the Interworking PINX for the 3,1 kHz audio bearer service (direction B-QSIG → QSIG)
B-QSIG: QSIG: emulation of the N-PISN 3.1 kHz audio bearer service 3.1 kHz audio bearer service N-BC:
- 3,1 kHz audio - circuit mode - 64 kbit/s - G.711 A or µ law
BC:
- 3,1 kHz audio - circuit mode - 64 kbit/s - G.711 A or µ law
N-HLC: optional
HLC:
present, if provided
N-LLC: optional
LLC:
present, if provided
B-BC:
- BCOB-A - Susceptible to clipping
-
ATM traffic descriptor:
equivalent to 64 kbit/s
-
Quality of service:
unspecified QOS class
-
AAL parameters:
AAL for voice or AAL type 5
-
End-to-end transit delay: optional
-
OAM traffic descriptor:
-
optional
- 80 -
C.1.2
A B-PISN user requests the N-PISN unrestricted digital information bearer service
Table C-2 - Mapping performed by the Interworking PINX for the unrestricted digital information bearer service (direction B-QSIG →QSIG) B-QSIG: emulation of the N-PISN unrestricted digital information bearer service
QSIG: unrestricted digital information bearer service
N-BC:
- unrestricted digital Information - circuit mode - 64 kbit/s
BC:
- unrestricted digital Information - circuit mode - 64 kbit/s
N-HLC:
optional
HLC:
present, if provided
N-LLC:
optional
LLC:
present, if provided
B-BC:
- BCOB-A - Susceptible to clipping
-
ATM traffic descriptor:
equivalent to 64 kbit/s
-
Quality of service:
unspecified QOS class
-
AAL parameters:
AAL type 1 or type 5
-
End-to-end transit delay: optional
-
OAM traffic descriptor:
-
C.1.3
optional
A B-PISN user requests the N-PISN telephony teleservice Table C-3 - Mapping performed by the Interworking PINX for the N-PISN telephony teleservice (direction B-QSIG → QSIG)
B-QSIG: emulation of the N-PISN telephony teleservice
QSIG: telephony teleservice
N-BC: - speech - circuit mode - 64 kbit/s - G.711 A or µ law
BC:
- speech - circuit mode - 64 kbit/s - G.711 A or µ law
N-HLC: telephony
HLC:
telephony
N-LLC: optional
LLC:
present, if provided
B-BC:
- BCOB-A - Susceptible to clipping
-
ATM traffic descriptor:
equivalent to 64 kbit/s
-
Quality of service:
unspecified QOS class
-
AAL parameters:
AAL for voice or AAL type 5
-
End-to-end transit delay:
optional
-
OAM traffic descriptor:
optional
-
- 81 -
C.1.4
A B-PISN user requests the N-PISN videotelephony teleservice based on the unrestricted digital information with tones/announcements bearer capability Table C-4 - Mapping performed by the Interworking PINX for the videotelephony teleservice (direction B-QSIG → QSIG)
B-QSIG: emulation of the N-PISN videotelephony teleservice
QSIG: videotelephony teleservice
N-BC:
BC:
- unrestricted digital information with tones/announcements - circuit mode - 64 kbit/s - Recommendations H.221 and H.242
N-HLC: Videotelephony (Recommendation F.721)
HLC:
Videotelephony (Recommendation F.721)
N-LLC: optional
LLC:
present, if provided
B-BC:
C.2
- unrestricted digital information with tones/announcements - circuit mode - 64 kbit/s - Recommendations H.221 and H.242
- BCOB-A - Susceptible to clipping
-
ATM traffic descriptor:
equivalent to 64 kbit/s
-
Quality of service:
unspecified QOS class
-
AAL parameters:
AAL type 1 or type 5
-
End-to-end transit delay:
optional
-
OAM traffic descriptor:
optional
-
Mapping functions for the direction QSIG → B-QSIG The mapping functions performed by the Interworking PINX for the direction from QSIG to B-QSIG are illustrated by the examples given below. These examples are not exhaustive. The same principles also apply to other circuit-switched PISN services. The Interworking PINX will relay the content of the BC, LLC and HLC information elements transparently to the B-PISN. No further processing is required, except for the changes needed to accommodate the different coding rules. The B-BC, ATM traffic descriptor, QOS parameter, and AAL parameters information elements are generated by the Interworking PINX, using default values specified in 11.2 and the information provided by the QSIG information elements. The "susceptibility to clipping" field of the B-BC information element in B-QSIG is always set to susceptible to clipping.
- 82 -
C.2.1
A N-PISN user requests the 3.1 kHz audio bearer service Table C-5 - Mapping performed by the Interworking PINX for the 3.1 kHz audio bearer service (direction QSIG → B-QSIG)
QSIG: 3.1 kHz audio bearer service
B-QSIG: emulation of the N-PISN 3.1 kHz audio bearer service
BC:
- 3.1 kHz audio - circuit mode - 64 kbit/s - G.711 A or µ law
N-BC: - 3.1 kHz audio - circuit mode - 64 kbit/s - G.711 A or µ law
HLC:
optional
N-HLC: present, if provided
LLC:
optional
N-LLC: present, if provided
-
B-BC:
-
ATM traffic descriptor:
see 11.2
-
Quality of service:
see 11.2
-
AAL parameters:
see 11.2
C.2.2
see 11.2
A N-PISN user requests the unrestricted digital information bearer service Table C-6 - Mapping performed by the Interworking PINX for the unrestricted digital information bearer service (direction QSIG → B-QSIG)
QSIG: unrestricted digital information bearer service
B-QSIG: emulation of the N-PISN unrestricted digital information bearer service
BC:
- unrestricted digital information - circuit mode - 64 kbit/s
N-BC: - unrestricted digital information - circuit mode - 64 kbit/s
HLC:
optional
N-HLC: present, if provided
LLC:
optional
N-LLC: present, if provided
-
B-BC:
-
ATM traffic descriptor:
see 11.2
-
Quality of service:
see 11.2
-
AAL parameters:
see 11.2
see 11.2
- 83 -
C.2.3
A N-PISN user requests the telephony teleservice Table C-7 - Mapping performed by the Interworking PINX for the telephony teleservice (direction QSIG → B-QSIG)
QSIG: telephony teleservice
B-QSIG: emulation of the N-PISN telephony teleservice
BC:
- speech - circuit mode - 64 kbit/s - G.711 A or µ law
N-BC: - speech - circuit mode - 64 kbit/s - G.711 A or µ law
HLC:
telephony
N-HLC: telephony
LLC:
optional
N-LLC: present, if provided
-
B-BC:
-
ATM traffic descriptor:
see 11.2
-
Quality of service:
see 11.2
-
AAL parameters:
see 11.2
C.2.4
see 11.2
A N-PISN user requests the videotelephony teleservice based on the unrestricted digital information with tones/announcements bearer capability Table C-8 - Mapping performed by the Interworking PINX for the videotelephony teleservice (direction QSIG → B-QSIG)
QSIG: videotelephony teleservice
B-QSIG: emulation of the N-PISN videotelephony teleservice
BC:
- unrestricted digital information with tones/announcements - circuit mode - 64 kbit/s - Recommendations H.221 and H.242
N-BC: - unrestricted digital information with tones/announcements - circuit mode - 64 kbit/s - Recommendations H.221 and H.242
HLC:
Videotelephony (Recommendation F.721)
N-HLC: Videotelephony (Recommendation F.721)
LLC:
optional
N-LLC: present, if provided
-
B-BC:
-
ATM traffic descriptor:
see 11.2
-
Quality of service:
see 11.2
-
AAL parameters:
see 11.2
see 11.2
- 84 -
- 85 -
Annex D (informative)
Specification and Description Language (SDL) representation of protocol control procedures
D.1
Protocol Control SDL diagrams This annex contains SDL diagrams in accordance with CCITT Recommendation Z.100 which reflect the Protocol Control procedures as described in clause 9 of this Standard. The procedures illustrated are not intended to be exhaustive, and several potential situations that may occur have been omitted from the SDL (e.g. some error conditions and procedures). Figure D.1 provides the key to the symbols used in this annex. The primitive symbols contain primitives which come from a number of sources, each identified by a prefix to the primitive name as indicated in table D.1 Table D.1 - Key to primitive types in Protocol Control SDL diagram Prefix
Primitive from/to:
CC_
Call/Connection Handling
AAL_
Signalling AAL
Event_
An entity which provides Protocol Control with notification of protocol related events other than receipt of incoming messages or primitives from Call /Connection Handling or the Signalling AAL
- 86 -
Process symbol
n
1(1)
Protocol Control state n
Decision symbol
Incoming Primitive
Incoming Message
Outgoing Primitive
Outgoing Message
Task symbol
Option Symbol
Figure D.1 - Key to symbols used in the Protocol Control SDL diagram
- 87 -
Process ProtocolControl
1(33) Null (0)
CC_SETUP Request Allocate Call Reference CREF flag = 0
Side ? selecting non selecting
Implementation option to indicate the IPVPI IPVPI Indication
No Indication
Idle IPVPI/IPVCI available Yes
No
IPVPI available
No
Select Idle IPVPI/IPVCI
Yes Select IPVPI
CC_REJECT Indication
SETUP
CC_REJECT Indication
Start Timer T303
Null (0)
Call Present (6)
Null (0)
- 88 -
Process ProtocolControl
2(33) Null (0)
STATUS with NULL State SETUP
Null
STATUS
Save Call Reference
Call state other than NULL
Cause #101
RELEASE COMPLETE
Null (0) Exclusive IPVPI/IPVCI
No
Cause #35
Requested IPVPI and IPVCI available Yes
Exclusive IPVPI Any IPVCI
Requested IPVPI available
Allocate requested IPVPI/IPVCI
Any IPVCI available
RELEASE COMPLETE
Yes Allocate requested IPVPI and available IPVCI
Call Initiated (1)
CC_SETUP Indication
Call Initiated (1)
No
Yes Cause #45
Allocate available IPVPI and IPVCI
A
CC_SETUP Indication
Any IPVPI/IPVCI available?
Cause #35
A
Null (0)
No
Yes
A
Release Call Reference
No IPVPI/IPVCI indication
No Cause #45
A
CC_SETUP Indication
Call Initiated (1)
A
- 89 -
Process ProtocolControl
3(33)
Call Present (6)
CALL PROCEEDING
Side ? Non selecting Selecting
Are IPVPI/IPVCI acceptable?
No
Yes CC_RELEASE Indication
Stop timer T303
RELEASE
Start Timer T310
Stop timer T303
CC_PROCEED Indication Call Proceeding Received (9)
Start timer T308 Release Request (11)
- 90 -
Process ProtocolControl
4(33)
Call Present (6)
Event expiry T303
Yes CC_RELEASE Indication
Release Call Reference
Final Expiry ? No SETUP
Restart T303
Cause #102
RELEASE COMPLETE
Null (0)
Call Present (6)
- 91 -
Process ProtocolControl
5(33)
Call Present (6)
RELEASE
Release IPVC
Cause received in RELEASE
No
Yes Cause #31
CC_RELEASE Indication
RELEASE COMPLETE
Release Call Reference
Stop all related Timers
Null (0)
- 92 -
Process ProtocolControl
6(33)
Call Proceeding Received (9) Event_expiry T310
ALERTING
PROGRESS
CONNECT
CC_PROGRESS Indication
Cause #102
RELEASE
Stop timer T310
Start T308
Start Timer T301 if applicable
Stop timer T310 Progress Description #21
Yes
No CC_ALERTING Indication
Release Request (11)
Alerting Received (7)
Call Proceeding Received (9)
Stop timer T310
CC_SETUP Confirmation
Active (10)
- 93 -
Process ProtocolControl
7(33)
Alerting Received (7) Event_expiry CONNECT T301
Cause #102
RELEASE
Stop Timer T301 if running
PROGRESS
CC_PROGRESS Indication
CC_SETUP Confirmation
Start T308 Release Request (11)
Active (10)
Alerting Received (7)
- 94 -
Process ProtocolControl
8(33)
Call Initiated (1)
CC_PROCEED request
CC_reject request
Indication in SETUP ? Not exclusive IPVPI/IPVCI
Release Call reference
RELEASE COMPLETE
Indication of allocated IPVPI/IPVCI
CALL PROCEEDING
Null (0)
Call Proceeding Sent (3)
Exclusive IPVPI/IPVCI
- 95 -
Process ProtocolControl
9(33)
Call Proceeding Sent (3) CC_PROGRESS request
CC_ALERTING Request
CC_SETUP Response
PROGRESS
ALERTING
CONNECT
Call Proceeding Sent (3)
Alerting Delivered (4)
Active (10)
- 96 -
Process ProtocolControl
10(33)
Alerting Delivered (4)
CC_PROGRESS request
CC_SETUP Response
PROGRESS
CONNECT
Alerting Delivered (4)
Active (10)
- 97 -
Process ProtocolControl
11(33)
Active (10)
Event_expiry T309
release IPVC
AAL_RELEASE indication
IsT309 running
Yes
AAL_ESTABLISH confirmation
AAL_ESTABLISH indication Spontaneous SAAL Reset indication
Stop timer T309
No release call reference
Start timer T309
CC_RELEASE indication
AAL_ESTABLISH request
Null (0)
Active (10)
STATUS ENQUIRY
STATUS ENQUIRY
Start Timer T322
Start Timer T322
Active (10)
Active (10)
- 98 -
Process ProtocolControl
Any State
12(33)
Except Null, Call Initiated, Call Present, Release Request & Release Indication
Any state
CC_NOTIFY request
NOTIFY
NOTIFY
CC_NOTIFY Indication
Remain in same state
Remain in same state
Except Null, Call Initiated, Call Present, Release Request & Release Indication
- 99 -
Process ProtocolControl
13(33)
Null (0)
Any message
Cause #81
RELEASE COMPLETE
Null (0)
except SETUP STATUS ENQUIRY STATUS REL. COMP.
- 100 -
Process ProtocolControl
14(33)
Any State (except 0 & 11)
RELEASE COMPLETE Stop Any Timer running Release Call Reference Release Any reserved IPVC CC_RELEASE Indication
Null (0)
Any State (except 0)
SETUP
Remain in Current State
- 101 -
Process ProtocolControl
15(33) Any State (except 0) Unexpected (except REL or or unrecognised REL. COMP.) Message
Yes
Yes
"follow explicit instruction" indication ? No Cause #97 to use?
State #11 or #12?
Yes
No Remain in same sate
Cause #97 Discard & report status or undefined
Instruction ? Discard and ignore Clear call Remain in same state
No
Cause #97 to use? Yes
Cause #101
Cause #97
STATUS
Remain in Current State
Cause #97 to use? Yes Cause #97
RELEASE
Stop any Timer running
STATUS
Start Timer T308 Release Request (11)
Remain in same state
No Cause #101
No
Cause #101
- 102 -
Process ProtocolControl
16(33)
Null (0)
Any State (except 0)
SETUP with SETUP with Any messagewithexcept SETUP,REL mandatory IE(s) mandatory IE(s) Mandatory IE and REL. COMP. content errors missing missing Any message with Mandatory IE content error
Cause #100
Cause #96
Cause #96
Cause #100
RELEASE COMPLETE
RELEASE COMPLETE
STATUS
STATUS
Null
Null
Remain in Current State
Remain in Current State
except SETUP,REL and REL. COMP.
- 103 -
Process ProtocolControl
17(33) Any State
Any message with Unrecognized Non-Mandatory IE
Including unexpected IE but recognized and except RELEASE and RELEASE COMPLETE messages
"follow explicit instruction" indication ?
Yes
No
Cause # 99
Instuction? Discard Discard IE message and proceed and ignore Others or Undefined
Remain in same state
Cause #99
Clear call
Unrecognized IE identifier
A
Other instruction
In diagnostic field of Cause IE.
STATUS
Discard message and report status
Discard IE, proceed and report status Resubmit message without unrecognized IE. Remain in same state
The resubmitted message will be processed in this state
RELEASE
Stop any Timer running
STATUS
Start Timer T308
Remain in same state
Release Request (11)
STATUS
A
A
Resubmit message without unregognized IE Remain in same state
The resubmitted message will be processed in this state
- 104 -
Process ProtocolControl
18(33) Any State
Any message
with Non Mandatory IE content error
"follow explicit instruction" indication ?
Yes
No Instuction? Discard Discard IE message and proceed and ignore Others or Undefined Cause #100
Remain in same state
A
Unrecognized IE identifier
Cause #100
Clear call
Other instruction Discard message and report status
State (11) or (12) No
STATUS Discard IE, proceed and report status Remain in Current State
Yes A
Resubmit message The resubmitted without IE msg will be with content error processed in this state
RELEASE
Stop any Timer running
STATUS
Start Timer T308 Release Request (11)
STATUS
A
Remain in same state
Remain in same state
In diagnostic field of Cause IE.
- 105 -
Process ProtocolControl
Any state
19(33)
except Release Request, Release Indication, Active and Null
AAL_ESTABLISH indication
Any state (Except 0)
STATUS
Cause #30 received ?
Any state
not indicating Null state
STATUS ENQUIRY
No Cause #30
Yes STATUS ENQUIRY
Start Timer T322
Stop Timer T322
Incompatible state reported
STATUS
Yes
No Cause #101
RELEASE
Stop any Timer running Start Timer T308
Remain in current state
Remain in current state
Release Request (11)
Remain in current state
- 106 -
Process ProtocolControl
20(33)
Any state
except Release Request, Release Indication
Event_expiry T322 Max retramsmission reached ?
Yes
No Cause #41
STATUS ENQUIRY
RELEASE
Stop any Timer running Start Timer T308
Remain in current state
Release Request (11)
- 107 -
Process ProtocolControl
21(33)
Null (0)
Any state (except 0 & 10)
AAL_RELEASE indication
AAL_RELEASE indication
AAL_ESTABLISH request
AAL_ESTABLISH request
Remain in same state
CC_RELEASE Indication Stop any Timer running Release Any IPVC
Release Call Reference
Null (0)
- 108 -
Process ProtocolControl
22(33)
Any state
Message with insufficient information
Remain in current state
- 109 -
Process ProtocolControl
23(33)
Any State (except 0 & 11)
RELEASE
Any State (except Null) RELEASE with Invalid content
In Cause IE
CC_RELEASE Request
RELEASE
Stop any Timer running
Stop any Timer running
Stop any Timer running
Treat as if Cause #100 received
Start Timer T308
CC_RELEASE Indication
Release Indication (12)
CC_RELEASE Indication
Release Indication (12)
Release Request (11)
- 110 -
Process ProtocolControl
24(33)
Release Request (11) Event expiry T308
RELEASE COMPLETE
First expiry
RELEASE
AAL_ESTABLISH STATUS indication
Stop Timer T308
No
Yes
Cause #102
IPVC in maintenance
release IPVC
release call reference
release call reference
RELEASE
Release Request (11)
Restart Timer T308 Clearing initiated by
a CC_RELEASE request
Yes No
Release Request (11)
CC_RELEASE confirmation
CC_RELEASE indication
Null
Null
- 111 -
Process ProtocolControl
25(33)
Release Indication
CC_RELEASE response
AAL_ESTABLISHSTATUS indication
RELEASE COMPLETE
Release Call reference
Release IPVC
Null
Release Indication (12)
Indicating state other than Null
- 112 -
Process ProtocolControl
26(33)
Any State (except Null)
RELEASE COMP
Stop Any Timer running Release Call Reference
Release Any IPVC
Cause #31
CC_RELEASE Indication
Null
with missing or incorrect coded cause IE or unrecognized non-mandatory IE
- 113 -
Process ProtocolControl
27(33)
Any state (except Null) RELEASE with mandatory IE(s) missing
Treat as if Cause #96 received CC_RELEASE Indication
Release Indication (12)
Cause IE missing
- 114 -
Process ProtocolControl
28(33)
Any State (except 0)
RELEASE with Unrecognized Non-Mandatory IE
Use Cause # 99
when RELEASE COMPLETE sent
CC_RELEASE indication Release Indication (12)
- 115 -
Process ProtocolControl
29(33)
Any State (except Null)
STATUS
indicating NULL state
release IPVC
release call reference
CC_RELEASE indication
Null
- 116 -
Process ProtocolControl
30(33)
Call Present (6)
SETUP ACK
Stop Timer T303
Start Timer T304
CC_MORE_INFORMATION Indication Overlap Sending 2
- 117 -
Process ProtocolControl
31(33)
Overlap Sending (2)
CALL PROCEEDING
ALERTING
CONNECT
Stop Timer T304
Stop Timer T304
Stop Timer T304
Start Timer T310
PROGRESS
CC_PROGRESS Cause #102 Indication
CC_ALERTING CC_SETUP Indication Confirmation
RELEASE
CC_PROCEED Indication Call Proceeding Received (9)
Event_expiry T304
CC_INFORMATION Request
INFORMATION
Start Timer T304
Start Timer T308 Alerting Received (7)
Active (10)
Overlap Sending (2)
Release Request (11)
Overlap Sending (2)
- 118 -
Process ProtocolControl
32(33)
Null (0)
SETUP
Start Timer T302
SETUP ACK
CC_SETUP indication Overlap Receiving (25)
With called number information incomplete or not determined as complete
- 119 -
Process ProtocolControl
33(33)
Overlap Receiving (25) CC_Proceed Request
INFORMATION
CC_Information indication
Restart Timer T302
CC_Alerting Request
Stop Timer T302
Stop Timer T302
CALL PROCEEDING
CC_Setup Response
Event_expiry T302
Stop Timer T302
Cause #28
CONNECT
RELEASE
Stop any Timer running
ALERTING
Start Timer T308 Overlap Receiving (25)
Call Proceeding Sent (3)
Alerting Delivered (4)
Active (4)
Release Request (11)
- 120 -
D.2
Restart Initiation SDL diagrams Process restarti
1(2)
Any state
CC_Restart request
RESTART
Start Timer T316 Restart Request (Rest 1)
- 121 -
Process restarti
2(2)
Restart Request (Rest 1)
RESTART
RESTART ACKNOWLEDGE
Global RESTART ACKNOWLEDGECall Reference Flag = 1 ?
Event expiry T316
No
Yes Stop Timer T316
No RESTART
Cause #81
Release IPVCs
Yes Limit of restart attempt reached
Restart T316
STATUS
Release Call references
Restart Request (Rest 1)
Null (Rest 0)
Restart Request (Rest 1)
Restart Request (Rest 1)
Null (Rest 0)
- 122 -
D.3
Restart Response SDL diagrams Process restartr
1(2)
Any state
RESTART
Global Call Reference Flag = 0 ?
No
Yes Cause #81
Start Timer T317
STATUS
Initiate release of call/connections
Restart (Rest 2)
Remain in same state
- 123 -
Process restartr
2(2)
Restart (Rest 2)
Call/connections Event expiry RESTART T317 released
Release IPVCs
CC_notify indication
STATUS
Release Call references
Stop Timer T317
RESTART ACKNOWLEDGE
Null (Rest 0)
Null (Rest 0)
Null (Rest 0)
- 124 -
- 125 -
Annex E (informative)
Guidelines for the use of instruction indicators
Each message and information element contains a compatibility instruction indicator that can be used to force a particular action at a receiving PINX if the message is unrecognised or unexpected or if the information element is unrecognised, unexpected or incorrectly coded. This action replaces the default action for an unrecognised or unexpected message (6.5.6.4 of PNNI 1.0), a message containing insufficient information (6.5.6.5 of PNNI 1.0) or an unrecognised, unexpected or incorrectly coded information element (6.5.6.8 of PNNI 1.0). Although the default action is normally adequate if a receiving PINX determines any of the messages or information elements specified in this edition of this Standard to be unrecognised, unexpected or incorrectly coded, other messages and information elements may be defined either: − in subsequent editions of this Standard; or − in other Standards that add additional signalling capabilities to this signalling protocol (e.g., for the support of supplementary services); or − for manufacturer-specific use (see annex H). Such additional messages and information elements may require different actions if determined to be unrecognised, unexpected or incorrectly coded. Compatibility instruction indicators provide a means of instructing a receiving PINX how to behave on receipt of an unrecognised, unexpected or incorrectly coded message or information element.
E.1
Message compatibility instruction indicator Octet 2 of the Message type information element contains a message compatibility instruction indicator comprising a Flag (bit 5) , a Pass Along Request (bit 4) and a Message Action Indicator (bits 2 and 1). If the Flag has the value 0 (message instruction field not significant), the default action specified in 6.5.6.4 of PNNI 1.0 or 6.5.6.5 of PNNI 1.0 applies if the message is unrecognised, unexpected or contains insufficient information. If the Flag has the value 1 (follow explicit instructions), the behaviour indicated by the Message Action Indicator applies, as specified in 6.5.7.1 and 6.5.8 of PNNI 1.0 apply if the message is unrecognised, unexpected or contains insufficient information. The default action should normally be adequate for all messages defined in this first edition of this Standard, although a particular implementation can choose alternative actions in certain circumstances. When specifying a new message, consideration should be given to whether the default action is required if the message is determined to be unrecognised or unexpected, or whether an alternative action is required. The message compatibility instruction indicator should be specified accordingly. The required action may depend on the context in which the message is sent, e.g., different actions for different protocol control states. The use of the value "pass along request" in the Pass Along Request in conjunction with value "discard and report status" in the Message Action Indicator is not recommended. This is because a message that is passed on at a Transit PINX and then not recognised at a later PINX that is not a Transit PINX will cause a STATUS message to be sent by the later PINX. This STATUS message will not reach the PINX that generated the message and therefore will serve no useful purpose.
E.2
Information element compatibility instruction indicator Octet 2 of each variable length information element contains an information element compatibility instruction indicator comprising a Flag (bit 5) , a Pass Along Request (bit 4) and an Information Element Action Indicator (bits 3 to 1). If the Flag has the value 0 (information element instruction field not significant), the default action specified in 6.5.6.8 of PNNI 1.0 applies if the information element is unrecognised or unexpected or is a non-mandatory information element with content error.
- 126 -
If the Flag has the value 1 (follow explicit instructions), the behaviour indicated by the Information Element Action Indicator applies, as specified in 6.5.7.2 of PNNI 1.0 applies if the information element is unrecognised or unexpected or is a non-mandatory information element with content error. The default action should normally be adequate for all information elements defined in this first edition of this Standard, although a particular implementation can choose alternative actions in certain circumstances. When specifying a new information element, consideration should be given to whether the default action is required if the information element is determined to be unrecognised, unexpected or a non-mandatory information element with content error, or whether an alternative action is required. The information element compatibility instruction indicator (Information Element Action Indicator and Pass Along Request) should be specified accordingly. The required action may depend on the context in which the information element is sent, e.g., different actions for different messages. The use of the value "pass along request" in the Pass Along Request in conjunction with value "discard and report status" in the Information Element Action Indicator is not recommended. This is because an information element that is passed on at a Transit PINX and then not recognised at a later PINX that is not a Transit PINX will cause a STATUS message to be sent by the later PINX. This STATUS message will not reach the PINX that generated the information element and therefore will serve no useful purpose.
- 127 -
Annex F (informative)
Description of the capabilities supported by the protocol defined in this Standard
This annex provides a more detailed description of the capabilities listed in clause 1 as being provided by the protocol defined in this Standard.
F.1
Support of demand (switched) virtual channel and virtual path connections The purpose of this specification is to support on-demand (switched) virtual channel and virtual path connections. Demand connections are established in real-time using signalling procedures. Demand connections can remain active for an arbitrary amount of time but are not automatically re-established after a network failure. NOTE F.1 In contrast, permanent connections are those that are set up and cleared down via provisioning. Permanent connections generally remain established for long periods of time and should automatically be re-established in the event of network failure.
F.2
Support of point-to-point virtual channel and virtual path connections A point-to-point connection is a virtual channel or virtual path connection that connect two endpoints. The protocol specified in this Standard supports point-to-point virtual channel and virtual path connections.
F.3
Support of point-to-multipoint virtual channel connections A point-to-multipoint connection is a virtual channel connection that connects one endpoint (the root) to multiple endpoints (the leaves) for unidirectional transmission of information from the root to the leaves. The protocol specified in this Standard supports point-to-multipoint virtual channel connections as an option,
F.4
Support of virtual channel and virtual path connections with symmetric or asymmetric bandwidth The protocol specified in this Standard supports point-to-point, bi-directional virtual channel and virtual path connections that have bandwidth specified independently in the forward and backward directions.
F.5
Support of a single connection per call The protocol specified in this Standard supports one and only one connection per call. NOTE F.2 For this reason, the protocol specified in this Standard applies simultaneously to a connection and to that connection's call, and this is denoted by use of the term "call/connection".
F.6
Protocol support for basic signalling functions The signalling protocol supports the following basic functions: − call/connection set up This is the aspect of the protocol which supports the establishment of a call/connection between different users on different PINXs. It includes call/connection request and call/connection answer.
- 128 -
− call/connection request This protocol function allows an originating PINX to request the establishment of a call/connection to a certain destination. − call/connection answer This protocol function allows the Terminating PINX to accept an incoming call/connection request. − call/connection clearing This protocol function allows any PINX involved in a call/connection to initiate the clearing of a call/connection, either during or after establishment of that call/connection. − transport of notifications
F.7
Support of CBR, real-time VBR, non-real-time VBR, ABR and UBR service categories The signalling specified in this Standard supports the Constant Bit Rate (CBR), real time Variable Bit Rate (rt-VBR), non-real time Variable Bit Rate (nrt-VBR), Unspecified Bit Rate (UBR) and Available Bit Rate (ABR) service categories, as specified in the ATM Forum Traffic Management Specification version 4.0. ABR is applicable to pointto-point connections only.
F.8
Support of signalling parameter request and indication The protocol specified in this Standard supports the negotiation of some signalling parameters (e.g., broadband low layer information, AAL parameters).
F.9
IPVPI/IPVCI support The signalling specified in this Standard supports Inter-PINX virtual channels (IPVCs) for carrying user plane information between PINXs and the grouping of IPVCs into Inter-PINX virtual paths (IPVPs). The means of providing IPVPs and IPVCs depends on the means by which the two PINXs are connected and is outside the scope of this Standard. The signalling provides for the identification of IPVCs and IPVPs by means of IPVC identifiers (IPVCIs) and IPVP identifiers (IPVPIs) respectively, and provides for the negotiation of IPVPI and IPVCI at call/connection establishment time. For general use this Standard specifies "non-associated" signalling, whereby the IPVPI is explicitly identified. As an option for the case where the IPVP is the one in which the signalling virtual channel connection is carried, this Standard also specifies "associated signalling", whereby the IPVPI is not explicitly identified.
F.10 Out-of-band signalling Call/connection control information uses an inter-PINX virtual channel connection that is separate from the IPVPs and IPVCs used for user plane information. The means of providing the signalling virtual channel connection depends on the means by which the two PINXs are connected and is outside the scope of this Standard.
F.11 Support of error recovery The error recovery capabilities of the protocol specified in this Standard include: 1. Detailed error handling procedures, including means for one signalling entity to inform its peer when it has encountered a non-fatal error (i.e., insufficiently severe to force call clearing); examples of non-fatal errors are message format errors, message content errors and procedural errors (e.g., messages or message contents received in a state in which they are not expected). 2. Procedures for recovery from SAAL reset and failure.
- 129 -
3. Mechanisms for signalling entities to exchange state information for calls/connections, and to recover gracefully if there is a disagreement; these procedures are applicable at any time, including under error conditions (as part of 1 or 2). 4. Capability to force calls/connections and VCCs to an idle state. 5. Provision of cause and diagnostic information for fault resolution with call/connection clearing (see 9.3). 6. Mechanisms (e.g., timers and associated procedures) to recover from loss of individual messages.
F.12 Support of B-PISN addressing The signalling specified in this Standard supports a number of address formats to be used across an IPL to unambiguously identify the endpoints in an ATM connection.
F.13 Support of end-to-end compatibility parameters On a per-connection basis the following end-to-end compatibility parameters can be conveyed: 1. the AAL type (e.g., type 1, 3/4, or 5); 2. the identification of low layer protocols; 3. the identification of high layer protocols.
F.14 Signalling interworking with N-ISDN and provision of N-ISDN services The protocol specified in this Standard supports interworking with N-PISN and the support of N-PISN services in a BPISN environment. NOTE F.3 An N-PISN that interworks with a B-PISN can in turn interwork with other networks, e.g., public N-ISDNs, nonISDNs. Therefore the procedures in this Standard for interworking with N-PISNs implicitly include interworking with these other types of networks via N-PISNs. By combining the requirements of this Standard for interworking with N-PISNs with the requirements of other standards for interworking between N-PISNs and other types of network, requirements for direct interworking between a B-PISN and those other types of network can be derived.
F.15 Forward compatibility To support forward compatibility in the signalling protocol, a mechanism based on instruction indicators is specified in this Standard. This mechanism applies to both messages and information elements.
F.16 Call/Connection Handling (CCH) at different types of PINX This Standard specifies certain aspects of CCH at a Transit PINX, an Originating PINX, a Terminating PINX, an Incoming Gateway PINX, an Outgoing Gateway PINX and an Interworking PINX. The purpose is to ensure the correct use of the protocol by CCH at these types of PINX.
F.17 Signalling of individual QoS parameters This Standard specifies support for signalling acceptable cell delay, acceptable cell delay variation and acceptable cell loss ratio, and also for signalling cummulative cell delay cummulative and cell delay variation.
F.18 ATM anycast addresses This Standard specifies a means of requesting a point-to-point connection to a single ATM end system that is part of an ATM group.
- 130 -
F.19 Negotiation of ATM traffic descriptors This Standard specifies the negotiation of connection characteristics during the establishment of a point-to-point call/connection or the first party of a point-to-multipoint call/connection. A call/connection establishment request can contain, in addition to the ATM traffic descriptor indicating the preferred connection characteristics, either: 1. an alternative ATM traffic descriptor, containing an alternative set of parameter values for use in the event of the preferred set being unsupportable; or 2. a minimum ATM traffic descriptor giving minimum values for peak cell rates and/or ABR minimum cell rates, thereby allowing lower cell rates than the preferred cell rates to be used.
F.20 Soft PVPC and PVCC support This Standard specifies signalling for the establishment and release across a network of permanent virtual path connections and permanent virtual circuit connections. These connections are established and released by management action at the originating PINX, rather than by signalling across the user-network interface.
F.21 Generic identifier transport This Standards provides for the end-to-end transport of identifiers for indicating an object with which the call/connection is associated.
- 131 -
Annex G (informative)
Specification and Description Language (SDL) representation of CCH at a Transit PINX and at an Interworking PINX
G.1
Transit Call Control SDL Diagrams NOTE G.1 The provision of a transit PINX functionality is an option. When provided, the procedures contained in clause 12 are mandatory. This annex contains SDL diagrams in accordance with CCITT Recommendation Z.100 which reflect the Call Control procedures as described in clause 12. The procedures illustrated are not intended to be complete, merely an example of the procedures described in the text. Figure G.1 provides the key to the symbols used in this annex. The input symbols from the left hand side contain primitives from a number of sources, each identified by a prefix to the primitive name as indicated in table G.1. The output symbols to the left hand side contain primitives to the Incoming Side Protocol Control entity. The input/output symbols to the right hand side contain primitives which are sent from/to the Outgoing Side Protocol Control entity. Table G.1 - Key to primitive types in Call Control SDL diagram Prefix
Primitive from/to:
CC_
Protocol Control
Event_
An entity which provides Call Control with notification of call related events.other than receipt of primitives from Protocol Control
- 132 -
Process CCH
n
1(12)
Transit Call Control state n
Decision symbol
Incoming Primitive from Preceding side protocol control or event generator
Incoming Primitive from Succeeding side protocol control
Outgoing Primitive to Preceding side protocol control
Outgoing Primitive to Succeeding side protocol control
Task symbol
Figure G.1 - Key to symbols used in the transit Call Control SDL diagram
- 133 -
Process CCH
2(12)
TCC_Idle (0)
CC_SETUP Indication Yes
Yes Any More Digits Required? CC_MORE_INFORMATION Request Yes Sufficient digits to Route on? No TCC_Await Digits (1)
Call Processing Succesful
No
No
Determine Reason
CC_SETUP Request
CC_REJECT Request
CC_PROCEED Request
A
TCC_Incoming Call_Proceeding (4)
TCC_Idle (0)
- 134 -
Process CCH
3(12)
Any state (except 0,1)
CC_REJECT Indication
CC_RELEASE Request
CC_REJECT Indication
CC_RELEASE Request
Disconnect User Plane Virtual Channels
Disconnect User Plane Virtual Channels
Release Resources
Release Resources
TCC_Await Outgoing_Release (9)
TCC_Await Incoming_Release (8)
- 135 -
Process CCH
4(12)
Any state (except 0,1)
CC_RELEASE Indication
CC_RELEASE Indication
Any State except 0,1
CC_RELEASE Response
CC_Release Response
TCC_Abort
CC_RELEASE Request Disconnect User Plane Virtual Channel
CC_RELEASE Request Disconnect User Plane Virtual Channels
CC_RELEASE Request
CC_RELEASE Request Disconnect User Plane Virtual Channels
TCC_Await Outgoing_Release (9)
TCC_Await Incoming_Release (8) TCC_Await Two-Way_Release (10)
- 136 -
Process CCH
TCC_Await Outgoing_Release (9) CC_RELEASE confirmation
5(12)
TCC_Await Incoming_Release (8) CC_RELEASE Confirmation
Release Resources
Release Resources
TCC_Idle (0)
TCC_Idle (0)
TCC_Await Two-Way_Release (10) CC_RELEASE Confirmation
TCC_Await Outgoing_Release (9)
CC_RELEASE Confirmation
TCC_Await Incoming_Release (8)
- 137 -
Process CCH
6(12) TCC_Await Digits (1) CC_INFORMATION Indication
No
Call Processing Successful?
Event_expiry T302
CC_RELEASE Indication
Event_Call Abort
CC_Release Request
CC_Release Response
CC_Release Request
Release Resources
TCC_Await Incoming_Release (8)
TCC_Idle (0)
Determine Reason
Release Resources TCC_Await Incoming_Release (8)
CC_Release Request
Yes Sufficient Digits to Route on?
A
TCC_Idle (0)
No
Yes CC_SETUP Request No
Any More Digits Required? Yes
CC_PROCEED Request TCC_Await Incoming_Release (8)
CC_REJECT Indication
TCC_Incoming TCC_Await Call_Proceeding Additional_Digits (4) (2)
TCC_Await Digits (1)
- 138 -
Process CCH
7(12)
TCC_Await AdditionalDigits (2)
Event_expiry T302
CC_PROCEED Request
Address Information Complete
CC_MORE_INFORMATION Indication
CC_PROCEED Indication
Through Connect User plane VC
Through Connect User Plane VC
CC_INFORMATION Indication
Save INFO in buffer
CC_INFORMATION Request (empty buffer) TCC_Incoming Call_Proceeding (4)
TCC_Overlap (3)
TCC_Transit TCC_Await Call_Proceeding Additional_Digits (5) (2)
- 139 -
Process CCH
8(12)
TCC_Overlap (3)
CC_INFORMATION Indication
CC_INFORMATION Request
Address Information Complete
CC_PROGRESS Indication
CC_PROCEED Request
Progress Description 1 or 8? Yes
CC_PROCEED indication
No
Through Connect Backward CC_PROGRESS Request
TCC_Overlap (3)
TCC_Transit TCC_Transit Call_Proceeding Call_Proceeding (5) (5)
TCC_Overlap (3)
- 140 -
Process CCH
9(12) TCC_Overlap (3)
CC_ALERTING Indication Progress No Description 1 or 8? Yes Through Connect Backward
CC_SETUP Confirmation
Event_expiry T302
Through Connect
CC_PROCEED Request
CC_SETUP Response
CC_ALERTING Request TCC_Call Alerting (6)
TCC_Call Active (7)
TCC_Transit Call_Proceeding (5)
- 141 -
Process CCH
10(12)
TCC_Incoming Call_Proceeding (4) CC_MORE_INFORMATION Indication
CC_PROCEED Indication
Through Connect
No
Number information buffered?
Through Connect Backward
Yes
CC_INFORMATION Request (buffered information)
TCC_Transit Call_Proceeding (5)
TCC_Transit Call_Proceeding (5)
- 142 -
Process CCH
11(12)
TCC_Transit Call_Proceeding (5) Event_expiry T302
CC_PROCEED Request
No
CC_ALERTING CC_SETUP Indication Confirmation
CC_PROGRESS CC_PROCEED Indication Indication
Progress Description 1 or 8? Yes
Through Connect (if not already)
Progress Description 1 or 8? Yes
CC_SETUP Response
Through Connect Backward
Through Connect (iF not already) CC_ALERTING Request TCC_Transit Call_Proceeding (5)
TCC_Call Alerting (6)
No
CC_PROGRESS Request TCC_Call Active (7)
TCC_Transit TCC_Transit Call_Proceeding Call_Proceeding (5) (5)
- 143 -
Process CCH
12(12)
TCC_Call Alerting (6) CC_PROGRESS Indication Progress Description 1 or 8? Yes
No
Through Connect (if not already)
CC_SETUP Confirmation
CC_SETUP Response Through Connect (if not already)
CC_PROGRESS Request TCC_Call Alerting (6)
TCC_Call Active (7)
- 144 -
- 145 -
Annex H (informative)
Manufacturer specific information
B-QSIG permits the inclusion in messages of non-standardized information which is specific to a particular design of PINX, a particular network, etc. This information is known as Manufacturer Specific Information. This Standard also permits the use of non-standardized messages and information elements between adjacent PINXs. No procedures are defined in this Standard for the handling of these messages and information elements at PINXs, apart from the error procedures defined in clauses 6.5.6.4, 6.5.6.8 and 6.5.7 of PNNI 1.0, which will apply in the event of an unrecognized message or information element being received by a PINX. NOTE H.1 Ambiguity may arise when two implementations use the same message identifier or information element identifier for different purposes.
- 146 -
- 147 -
Annex I (informative)
Possible strategies for avoidance of IPVCI collisions
By default, the preceding side selects the IPVPI/IPVCI value when establishing a call/connection, and therefore IPVCI/IPVPI collisions may occur. As one method of avoiding collisions, this Standard offers the option of configuring a PINX as the selecting side or the non-selecting side of an IPL. How this is done is outside the scope of this Standard. The following strategies for avoiding collisions are suggested: − Pre-configuration − This is an option of this Standard, whereby one side of an IPL is configured as the selecting side and the other side is configured as the non-selecting side. How this is done (e.g., manual configuration or use of a management protocol) is outside the scope of this Standard. − Range − Each PINX on an IPL selects IPVPI/IPVCI values from a reserved range. Pre-configuration is required for this method. How this is done is outside the scope of this Standard. − Random selection − Each PINX selects the IPVPI/IPVCI value at random. Because of the large number of possible IPVPI/IPVCI values, a collision is very unlikely. In the case of a collision, no call/connection will be established, and each PINX will select a new value at random for a repeat attempt. In addition the time between attempts can be variable, making it even more unlikely that a further collision will arise.
- 148 -
- 149 -
Annex J (informative)
Differences between this Standard and PNNI 1.0
The signalling protocol specified in this Standard is based on the signalling protocol specified in PNNI 1.0. Whereas PNNI 1.0 also contains a routing specification that provides for the automatic construction of routing tables and the source routing of calls/connections, the signalling protocol specified in this Standard is intended for use without the PNNI routing specification, i.e., in PISNs employing hop-by-hop routing or non-standardized methods of source routing. The following list summarises the main technical differences between the signalling protocol specified in this Standard and the signalling protocol specified in PNNI 1.0. • Procedures, messages and information elements for point-to-multipoint calls, which are mandatory in PNNI 1.0, are optional in this Standard. • The Designated transit list and Crankback information elements and associated procedures are not applicable in this Standard. • This Standard assumes a SAAL as specified in ECMA-265. • This Standard uses the Broadband sending complete information element, as specified also in ITU-T recommendation Q.2931. • This Standard specifies messages and procedures for the support of overlap sending on calls from 64 kbit/s-based networks. • This Standard specifies additional progress descriptions for inclusion in the Progress indicator information element, and because of this also permits a greater number of occurrences of this information element in certain messages. • This Standard extends the use of the PROGRESS message and the Progress indicator information element to any call/connection (i.e., not just for 64 kbit/s-based services) for progress descriptions 16 and 21. • This Standard permits repetition of the Notification indicator information element in a message. • This Standard uses the OAM traffic descriptor information element, as specified also in ITU-T recommendation Q.2931. • This Standard allows additional combinations of "numbering plan identification" values and "type of number" values in the Called party number, Calling party number and Connected number information elements. It also allows additional AFI values in these information elements for ATM endsystem addresses encoded as an NSAP addresses. • This Standard permits the use of information from codesets other than codeset 0. • This Standard is applicable to a various types of IPL, and consequently does not specify a particular virtual channel for carrying the signalling protocol and specifies user information virtual paths and virtual channels as logical entities using the terms IPVP, IPVPI, IPVC and IPVCI. • A symmetrical method of IPVPI/IPVCI allocation is specified in this Standard, with optional configuration of a "selecting side" and a "non-selecting side" of an IPL to assist in avoiding collisions. • For the N-LLC information element, this Standard allows a maximum number of occurrences of four in certain messages. • This Standard allows the inclusion of the Cause information element in the PROGRESS message in certain cases.
- 150 -
- 151 -
Annex K (informative)
Specification and Description Language (SDL) representation of point-to-multipoint procedures
K.1
Architectural model for SDL diagrams This annex contains SDL diagrams in accordance with CCITT Recommendation Z.100 which reflect the point-tomultipoint procedures as described in clause 10 of this Standard. The procedures illustrated are not intended to be exhaustive, and several potential situations that may occur have been omitted from the SDL (e.g. some error conditions and procedures). The SDLs for point-to-multipoint procedures describe the actions of a party control state machine, based on the following architectural model:
Telecommunication service application (AP)
1) Party Control 2) Coordination function
3)
4)
Point-to-point call/connection Control
SAAL
Figure K-1 - Architectural model for the specification of SDLs for process "Party Control" The SDLs for the process "point-to-point call/connection control" are provided in annex C of this Standard.
K.2
List of Signals for Party Control (numbers correspond to the numbers in figure K-1) 1) (from AP): Add Party req., Add Party Ack. req., Add Party Rej. req., Party Alerting req., Drop Party req., DP Ack. req., Party Status Enquiry req. (from SAAL): ADD PARTY, ADD PARTY ACK., ADD PARTY REJ., PARTY ALERTING, DROP PARTY, DROP PARTY ACK., STATUS, STATUS ENQUIRY 2) (to AP): Add Party ind., Add Party Ack. ind., Add Party Rej. ind., Party Alerting ind., Drop Party ind., DP Ack. ind. (to SAAL): ADD PARTY, ADD PARTY ACK., ADD PARTY REJ., PARTY ALERTING, DROP PARTY, DROP PARTY ACK, STATUS, STATUS ENQUIRY
- 152 -
3) (from AP): Setup-req., Alerting req., Setup-resp., Release-req., Release-resp. (from SAAL): SETUP, ALERTING, CONNECT, RELEASE, RELEASE COMPLETE 4) - (none)
K.3
Detailed SDL specification of the process "Party Control" The specification of the process "Party-Control-N" of ITU-T Rec. Q.2971, clause 14 applies with the following modifications: • replace "Party-Control-N" by "Party-Control" throughout; • within state "PN1- Add Party Initiated", replace the incoming signal "Setup complete req. (#)" by the signal "CONNECT (#)"; • within state "PN4 - Party Alerting Received", replace the incoming signal "Setup complete req. (#)" by the signal "CONNECT (#)"; • in all states except PN0, replace the incoming signal "Status Enq. req. (ER)" by "Party Status Enquiry req. (ER)".
- 153 -
Annex L (informative)
Guidelines for interworking with ATM Forum PNNI 1.0
L.1
Introduction This annex contains guidelines for interworking at a gateway PINX between a network employing the signalling system specified in this Standard (B-QSIG) and a network employing the ATM Forum’s PNNI 1.0 specification (PNNI).. For the purposes of this annex, a gateway PINX is a PINX that provides interworking between B-QSIG and PNNI.
L.2 L.2.1
Basic Model Architectural reference model Figure L-1 is a reference model for a PINX that acts as a gateway between a network employing PNNI and a network employing B-QSIG. Such a PINX will have one or more interfaces that use PNNI signalling and routing and one or more interfaces that use B-QSIG signalling.
Routing protocol Route Determination
Topology Database
Topology Exchange
B-QSIG Signalling B-QSIG Signalling
Call/connection Handling
Cell Stream
PNNI Signalling
PNNI Signalling
Cell Stream Switching Fabric
Figure L-1 - Architectural reference model for a B-QSIG/PNNI gateway PINX
L.2.2
Signalling protocol model Figure L-2 shows the signalling protocol model for B-QSIG/PNNI interworking at a gateway PINX. Call/Connection Handling (CCH) provides mediation between the two signalling protocols. CCH gives the appearance of a B-QSIG CCH entity to the next B-QSIG PINX and of a PNNI Call Control entity to the next PNNI node.
- 154 -
Gateway PINX Call/Connection Handling (CCH) B-QSIG Layer 3
PNNI Layer 3 B-QSIG Layer 3 Protocol Control
PNNI Layer 3 Protocol Control
SAAL
SAAL
ATM Layer
ATM Layer
Physical Layer
Physical Layer
To next B-QSIG PINX
IPL
To next PNNI node
Physical Inter-Node Link
Figure L-2 - Signalling protocol model for B-QSIG/PNNI interworking
L.2.3
Interworking with other networks beyond the B-QSIG network B-QSIG provides for interworking with other networks, in particular public B-ISDNs via DSS2, public narrow-band networks via DSS1, and private narrow-band networks using QSIG. This annex therefore also allows interworking between a PNNI network and any of these other networks, via a B-QSIG network.
L.3
Routing interworking B-QSIG currently relies on hop-by-hop routing and the manual configuration of individual PINXs to achieve this. Therefore the gateway PINX is required to provide interworking between a PNNI routing domain and the B-QSIG network. The method of working is for the gateway PINX to operate PNNI routing protocols on PNNI interfaces and no routing protocol on B-QSIG interfaces, which are treated as exterior links. The gateway PINX should be configured with a list of exterior reachable addresses reachable via the B-QSIG network. This is in addition to any internal reachable addresses associated with end systems attached directly to the gateway PINX.
L.4
Signalling interworking for basic call/connection control Signalling interworking between a B-QSIG link and a PNNI link is carried out within the Call/Connection Handling (CCH) entity in the gateway PINX. It is the same as interworking between two PNNI links with the following exceptions.
L.4.1
Handling of the Designated transit list information element Because B-QSIG uses hop-by-hop routing, it does not use the Designated transit list information element.
L.4.1.1
Call/connection or party establishment in the direction PNNI to B-QSIG For a SETUP or ADD PARTY message in the direction PNNI to B-QSIG, all Designated transit list information elements should have been exhausted by the time the gateway PINX is reached. The B-QSIG SETUP or ADD PARTY message should contain no Designated transit list information element.
- 155 -
L.4.1.2
Call/connection or party establishment in the direction B-QSIG to PNNI A SETUP or ADD PARTY message in the direction B-QSIG to PNNI will contain no Designated transit list information elements. The gateway PINX acts as DTL originator by building its own stack of DTLs and including them in Designated transit list information elements in the PNNI SETUP or ADD PARTY message.
L.4.2
Handling of the Crankback information element Because B-QSIG uses hop-by-hop routing, it does not use the Crankback information element.
L.4.2.1
Call/connection or party establishment in the direction PNNI to B-QSIG A RELEASE, RELEASE COMPLETE or ADD PARTY REJECT message from the B-QSIG link during call/connection or party establishment will not contain a Crankback information element. It is an implementation matter for the gateway PINX whether to: • reroute the call/connection or party establishment to another exterior link; or • reroute the call/connection or party establishment within the PNNI routing domain and include one or more Designated transit list information elements, provided the gateway PINX is an entry border node or DTL originator; or • pass back the indication of failure by means of a PNNI RELEASE or ADD PARTY REJECT message. In the last case, the gateway PINX may include a Crankback information element.
L.4.2.2
Call/connection or party establishment in the direction B-QSIG to PNNI A RELEASE, RELEASE COMPLETE or ADD PARTY REJECT message from the PNNI link during call/connection or party establishment can contain a Crankback information element. In this case the gateway PINX is acting as DTL originator. Depending on the contents of the Crankback information element and other factors, the gateway PINX may either: • reroute the call/connection or party establishment within the PNNI routing domain; or • reroute the call/connection or party establishment outside the PNNI routing domain, i.e., to an exterior link different from the B-QSIG link on which the call/connection or party establishment arrived; or • pass back the indication of failure by means of a B-QSIG RELEASE or ADD PARTY REJECT message.
L.4.3
Handling of additional B-QSIG progress descriptions B-QSIG supports additional progress descriptions 16, 17, 18, 19 and 21 within the Progress indicator information element. These progress descriptions use the value "01" (ISO/IEC standard) in the coding standard field. In the case of a call/connection supporting a 64 kbit/s-based ISDN circuit mode service, any of these five additional progress descriptions can be received from a B-QSIG link in any message in which the Progress indication information element is permitted. Also the number of appearances of the Progress indicator information element in a B-QSIG message can exceed the maximum number of appearances of the Progress indicator information element in a PNNI message. A B-QSIG Progress indicator information element that contains a progress description not supported in PNNI or that would break the PNNI limit for the number of Progress indicator information elements in the message concerned should be included in the corresponding PNNI message with the IE action indicator field containing the value "discard information element and proceed" and the pass along request field containing the value "pass along request". NOTE The purpose of passing the information element on is that a further B-QSIG network may be encountered further along the path of the call/connection and may be able to use the information concerned. In the case of any other call/connection, additional progress descriptions 16 and 21 can be received from a B-QSIG link in a Progress indicator information element in a PROGRESS, SETUP, ALERTING or CONNECT message. A B-QSIG PROGRESS message should be passed on to the PNNI link with the message action indicator field containing the value "discard and ignore" and the pass along request field containing the value "pass along request". A B-QSIG Progress indicator information element that contains progress description 16 or 21 should be included in the corresponding PNNI message with the IE action indicator field containing the value "discard information element and proceed" and the pass along request field containing the value "pass along request".
- 156 -
NOTE The purpose of passing the PROGRESS message and/or information element on is that a further B-QSIG network may be encountered further along the path of the call/connection and may be able to use the information concerned.
L.4.4
Handling of overlap sending in B-QSIG (support of 64 kbit/s-based circuit mode services only) If a SETUP message from the B-QSIG link contains an incomplete number in the Called party number information element or a number that the gateway PINX cannot determine to be complete, the gateway PINX should await further called party number information (in INFORMATION messages) until it determines that the number is complete before sending a SETUP message on the PNNI link. Only a number that is believed to be complete should be sent in a PNNI SETUP message. A B-QSIG INFORMATION message should not be passed on to a PNNI link. NOTE A gateway PINX can determine that a number is complete by analysis of the received digits or if it receives a Broadband sending complete information element in the SETUP message or an INFORMATION message. In the event of failure to receive a further INFORMATION message within a certain time (B-QSIG timer T302), the gateway PINX can assume that the number is complete unless by analysis it knows that the number is incomplete.
L.4.5
Handling of B-QSIG Broadband sending complete information element If the Broadband sending complete information element is received in a B-QSIG SETUP message, the information element should be omitted from the SETUP message passed on to the PNNI link.
L.4.6
Handling of number formats not supported in PNNI in the Called party number information element If a number format (as indicated by the type of number and numbering plan identification fields) that is not supported by PNNI is received in a B-QSIG Called party number information element and the number can be translated into a format that is supported by PNNI, the translated number should be included in the PNNI Called party number information element. If the number cannot be translated, the call/connection establishment or party establishment should not be allowed to proceed into the PNNI network.
L.4.7
Handling of number formats not supported in PNNI in the Calling party number and Connected number information elements If a number format (as indicated by the type of number and numbering plan identification fields) that is not supported by PNNI is received in a B-QSIG Calling party number or Connected number information element and the number can be translated into a format that is supported by PNNI, the translated number should be included in the corresponding PNNI information element. If the number cannot be translated, the corresponding PNNI information element should not include a number and should have value "number not available" in the presentation indicator field.
L.4.8
Handling of the B-QSIG OAM traffic descriptor information element If an OAM traffic descriptor information element is received in a B-QSIG SETUP or CONNECT message, the information element should be included in the corresponding PNNI message with the IE action indicator field containing the value "discard information element and proceed" and the pass along request field containing the value "pass along request". NOTE The purpose of passing the information element on is that a further B-QSIG network may be encountered further along the path of the call/connection and may be able to use the information concerned.
L.4.9
Handling of B-QSIG information elements from codesets other than codeset 0 If a B-QSIG information element from a codeset other than codeset 0 is received in a message that is to be passed on to the PNNI link, the information element should be included in the PNNI message with the IE action indicator field containing the value "discard information element and proceed" and the pass along request field containing the value "pass along request". The corresponding Broadband locking shift and Broadband non-locking shift information element should also be passed on.
- 157 -
NOTE The purpose of passing the information element on is that a further B-QSIG network may be encountered further along the path of the call/connection and may be able to use the information concerned.
.
.
.
Printed copies can be ordered from: ECMA 114 Rue du Rhône CH-1204 Geneva Switzerland Fax: Internet:
+41 22 849.60.01 [email protected]
Files can be downloaded from our FTP site, ftp.ecma.ch, logging in as anonymous and giving your E-mail address as password. This Standard is available from library ECMA-ST as a compacted, self-expanding file in MSWord 6.0 format (file E266-DOC.EXE) and as an Acrobat PDF file (file E266-PDF.PDF). File E266-EXP.TXT gives a short presentation of the Standard. Our web site, http://www.ecma.ch, gives full information on ECMA, ECMA activities, ECMA Standards and Technical Reports.
ECMA 114 Rue du Rhône CH-1204 Geneva Switzerland This Standard ECMA-266 is available free of charge in printed form and as a file. See inside cover page for instructions