Technical Committee

B-ICI Specification, V 2.0 (Delta)

af-bici-0013.002

November, 1995

Editor:	Rajeev Sinha
		Bellcore
		331, Newman Springs Road, NVC 1H-218
		Red Bank, N.J. 07701, USA
		Phone:	+1-908-758-2422
		Fax:	+1-908-758-4131
		Email:	rsinha@notes.cc.bellcore.com

©1995 The ATM Forum. All Rights Reserved. No part of this publication may be reproduced in any form or by any means. 
The information in this publication is believed to be accurate as of its publication date. Such information is subject to change without notice and the ATM Forum is not responsible for any errors. The ATM Forum does not assume any responsibility to update or correct any information in this publication. Notwithstanding anything to the contrary, neither The ATM Forum nor the publisher make any representation or warranty, expressed or implied, concerning the completeness, accuracy, or applicability of any information contained in this publication. No liability of any kind shall be assumed by The ATM Forum or the publisher as a result of reliance upon any information contained in this publication. 
The receipt or any use of this document or its contents does not in any way create by implication or otherwise:
	•	Any express or implied license or right to or under any ATM Forum member company’s 		patent, copyright, trademark or trade secret rights which are or may be associated with the 		ideas, techniques, concepts or expressions contained herein; nor
	•	Any warranty or representation that any ATM Forum member companies will announce 		any product(s) and/or service(s) related thereto, or if such announcements are made, that 		such announced product(s) and/or service(s) embody any or all of the ideas, technologies, 		or concepts contained herein; nor
	•	Any form of relationship between any ATM Forum member companies and the recipient or 		user of this document.
Implementation or use of specific ATM standards or recommendations and ATM Forum specifications will be voluntary, and no company shall agree or be obliged to implement them by virtue of participation in the ATM Forum.
The ATM Forum is a non-profit international organization accelerating industry cooperation on ATM technology. The ATM Forum does not, expressly or otherwise, endorse or promote any specific products or services.

TABLE OF CONTENTS
SCOPE	1
6.	Common B-ICI Operations and Maintenance	2
6.2.2	ATM OAM Cell Formats	2
6.2.3	OAM Functions	6
6.2.3.1	ATM Fault Management Functions at the B-ICI	6
6.2.3.1.1	Alarm Surveillance	6
6.2.3.1.2	Connectivity Verification	8
6.2.3.1.2.1	Segment Loopback	8
6.2.3.1.2.2	End-to-End Loopback	9
6.2.3.1.3	Continuity Check	10
6.2.3.2	Performance Management Functions at the B-ICI	10
6.2.3.2.1	Performance Management Cell Payload Structure	10
6.2.3.2.2	Mechanism for VP/VC PM Cell Generation	11
6.2.3.2.2.1	Segment VP/VC Monitoring	12
6.2.3.2.2.2	End-to-End VP/VC Monitoring	15
6.2.3.3	OAM Activation/Deactivation Functions at the B-ICI	16
6.2.3.3.1	Activation/Deactivation Cell Payload Structure	17
6.2.3.3.2	PM Activation and Deactivation Procedures	18
6.2.3.3.2.1	PM Activation Procedure	19
6.2.3.3.2.2	PM Deactivation Procedure	19
6.2.3.3.2.3	Responses and Actions Resulting from a
	Deactivation Request	20
6.2.3.3.3	Performance Monitoring Activation/Deactivation
	Requirements	20
7.	B-ICI Signaling	23
7.1	B-ICI Requirements and Selection of B-ISUP	23
7.1.1	B-ICI Signaling Requirements	23
7.1.2	B-ICI Signaling Protocol Selection	24
7.2	Likely B-ICI Signaling Evolution	24
7.3	Relationship of the ATM Forum's B-ICI Signaling Requirements and the 		ITU-T Work	25
7.3.1	Interoperability Between ATMF B-ICI Spec 2.0 and ITU Versions of the 		BISUP and MTP Level 3	25
7.3.2	Differences Between ATMF B-ICI Spec 2.0 and ITU BISUP/MTP Level 3 		Standards	26
7.3.2.1	Signaling Functionality in ITU BISUP/MTP Level 3 Omitted in 
	ATMF B-ICI Spec 2.0	26
7.3.2.2	Additional Functionality of ATMF B-ICI Spec 2.0 Signaling, 
	Relative to ITU BISUP Standards	26
7.4	Signaling Network Topology	28
7.5	Signaling Network Configuration	31
7.6	Network Signaling Protocol Architecture	32
7.7	MTP Level 3 Subset for Associated Mode Signaling	32
7.7.1	Signaling Message Handling	33
7.7.2	Signaling Link Management	33
7.7.3	Signaling Route Management	33
7.7.4	Signaling Traffic Management	34
7.7.5	Requirements for MTP Level 3 for Associated Mode	34
7.8	Call and Connection Control Functions	36
7.8.1	Call and Connection Control Messages	36
7.8.2	Assignment Procedure of VPCI/VCI and Bandwidth	36
7.8.2.1	Management of VPCI/VCI Values and Bandwidth of Each VPC	36
7.8.2.2	Procedures for the Assigning BSS and Non-Assigning BSS	37
7.8.2.3	Abnormal Conditions	38
7.8.2.4	Monitoring of Assigning End Disagreements	39
7.8.3	Signaling Identifiers	39
7.8.4	Addresses and Address Formats	43
7.8.5	Successful Call Set Up	44
7.8.5.1	Forward Address Signaling	45
7.8.5.1.1	Actions Required at the Originating BSS	45
7.8.5.1.2	Actions Required at an Intermediate BSS - Originating
	Network	55
7.8.5.1.3	Actions Required at an Intermediate BSS - Transit
	Carrier	57
7.8.5.1.4 	Actions Required at an Intermediate BSS - Terminating
	Network	58
7.8.5.1.5 	Actions Required at the Destination BSS - Terminating
	Network	59
7.8.5.2	Address Complete Message	61
7.8.5.2.1	Actions Required at the Destination BSS	61
7.8.5.2.2	Actions Required at an Intermediate BSS	62
7.8.5.2.3	Actions Required at the Originating BSS	62
7.8.5.2.4	Through Connection and Answer Indication at the
	Destination BSS	62
7.8.5.3	Call Progress Message (Basic Call)	62
7.8.5.3.1	Actions Required at the Destination BSS	62
7.8.5.3.2	Actions Required at an Intermediate BSS	62
7.8.5.3.3	Actions Required at the Originating BSS	62
7.8.5.4	Answer Message	62
7.8.5.4.1	Actions Required at the Destination BSS	62
7.8.5.4.2	Actions Required at an Intermediate BSS	63
7.8.5.4.3	Actions Required at the Originating BSS	63
7.8.5.5	Storage and Release of Information	63
7.8.6	Unsuccessful Call and Connection Set Up	64
7.8.6.1	Lack of Resources at the Incoming Side	64
7.8.6.2	Lack of Resources at the Outgoing Side	64
7.8.6.3	Actions at a BSS Receiving an IAM Reject Message.	64
7.8.6.4	Actions at a BSS Receiving a Release Message	64
7.8.6.5	Address Incomplete	65
7.8.7	Normal Call Release	65
7.8.7.1	General	65
7.8.7.2	Release Initiated by a Calling Party	66
7.8.7.3	Release Initiated by a Called Party	67
7.8.7.4	Release Initiated by the Network	67
7.8.7.5	Suspend, Resume (Network Initiated)	67
7.8.8	Propagation Delay Determination	67
7.9	BISUP Maintenance Control Functions	68
7.9.1	Reset Procedure	68
7.9.1.1	Actions at Reset Initiating BSS	69
7.9.1.2	Actions at Reset Responding BSS	70
7.9.1.3	Abnormal Reset Procedures	71
7.9.1.4	Performance Monitoring Counts of Resets	71
7.9.2	Blocking and Unblocking of Virtual Paths	71
7.9.2.1	Initiating Blocking	72
7.9.2.2	Initiating Unblocking	72
7.9.2.3	Receiving Blocking	72
7.9.2.4	Receiving Unblocking	72
7.9.2.5	Abnormal Procedures	73
7.9.3	User Part Availability Procedure	73
7.9.4	Transmission Alarm Handling	73
7.9.5	Automatic Congestion Control	73
7.9.5.1	Receipt of a Release Message Containing an Automatic Congestion
	Level	73
7.9.5.2	Actions Taken by the Congested BSS During Overload	74
7.9.6	BISUP Signaling Congestion Control	74
7.9.7	Destination Availability	75
7.9.8	Consistency Check	75
7.9.8.1	Initiating Consistency Check Request	76
7.9.8.2	Receiving Consistency Check Request	76
7.9.8.3	Initiating Consistency Check End	77
7.9.8.4	Receiving Consistency Check End	77
7.9.8.5	Abnormal Procedures	77
7.10	BISUP Compatibility Functions	78
7.10.1	Introduction	78
7.10.1.1	Unrecognized Messages and Parameters	78
7.10.1.2	General Requirements on Receipt of Unrecognized Signaling
	Information	78
7.10.2	Procedures for the Handling of the Unrecognized Messages or Parameters	80
7.10.2.1	Unrecognized Messages	81
7.10.2.2	Unrecognized and Unexpected Parameters	81
7.10.2.3	Unrecognized Parameter Values	82
7.10.3	Procedures for the Handling of Responses Indicating Unrecognized		Information Has Been Sent	82
7.10.3.1	Originating, Destination, and Interworking BSSs	82
7.10.3.2	Intermediate BSSs	82
7.10.4	Protocol Monitoring Measurements for Unrecognized Messages and 		Parameters	83
7.11	Point-to-Multipoint Call and Connection Control	85
7.11.1	Call and Connection Control Functions	85
7.11.2	Successful Call and Connection Set-Up	85
7.11.2.1	Forward Address Signaling - Set-up of the First Leaf Party	88
7.11.2.1.1	Actions Required at the Originating BSS	88
7.11.2.1.2	Actions Required at an Intermediate BSS -
	Originating Network	90
7.11.2.1.3	Actions Required at an Intermediate BSS -
	Transit Carrier	91
7.11.2.1.4	Actions Required at an Intermediate BSS -
	Terminating Network	91
7.11.2.1.5	Actions Required at the Destination BSS	92
7.11.2.2	Forward Address Signaling - Addition of a New Leaf Party	92
7.11.2.2.1	Actions Required at the Originating BSS	92
7.11.2.2.2	Actions Required at an Intermediate BSS - 
	Originating Network	94
7.11.2.2.3 	Actions Required at an Intermediate BSS - 
	Transit Carrier	96
7.11.2.2.4	Actions Required at an Intermediate BSS - 
	Terminating Network	96
7.11.2.2.5	Actions Required at the Destination BSS	97
7.11.2.3	Address Complete Message	97
7.11.2.4	Call Progress Message (Basic Call)	97
7.11.2.5	Answer Message	97
7.11.2.6	Storage and Release of Information	97
7.11.3	Unsuccessful Call/Connection Set-up	97
7.11.3.1	Lack of Resources at the Incoming Side	97
7.11.3.2	Lack of Resources at the Outgoing Side	98
7.11.3.3	Actions at an BSS Receiving an IAR	98
7.11.3.4	Actions at an BSS Receiving a Release Message	99
7.11.3.5	Address Incomplete	99
7.11.4	Normal Call and Connection Release	100
7.11.4.1	General	100
7.11.4.2	Drop of a Leaf Party Requested by the Root Party	100
7.11.4.3	Drop of a Leaf Party Requested by the Leaf Party Itself	101
7.11.4.4	Drop of a Leaf Party Initiated by the Network	102
7.11.4.5	En-bloc Release of Call/Connection Requested by the Root Party
		102
7.11.5	Interaction	103
7.11.5.1	Interaction With a Leaf Party that does not Support Multipoint
	Procedures	103
7.11.5.2	Interaction with a Leaf Party that is not a Broadband User	103
7.11.6	Maintenance Control Functions	104
7.11.6.1	Reset	104
7.11.6.1.1	Actions at Reset Initiating BSS	105
7.11.6.1.2	Actions at Reset Responding BSS	105
7.11.6.1.3	Abnormal Reset Procedures	106
7.11.6.2	Blocking and Unblocking of Virtual Paths	106
7.12	BISUP Administration	107
7.12.1	Additional Management Requirements	108
7.12.1.1	Requirements for OPC/DPC Signaling Relationships	108
7.12.1.2	Requirements for VPCIs	109
10.	PVC-Based Inter-Carrier FRS Support on a B-ICI	110
11.	SMDS Support on a B-ICI	111
12.	Usage Measurement	112
12.1	Usage Measurement Framework	112
12.2	PVC Service-Independent Usage Information	112
12.3	PVC Service-Specific Usage Information	113
12.4	SVC Service-Independent Usage Information	113
12.4.1	Originating Carrier Network	113
12.4.2	Terminating Carrier Network	118
12.4.3	Point-to-Multipoint SVCs	122

ACRONYMS	125
REFERENCES	127
APPENDIX A - Initial Guidelines for FRS Traffic Characterization at the B-ICI	129
APPENDIX B - Mandatory/Optional Status of BISUP Parameters	130
APPENDIX C - Illustration of Use of VPCI	133

LIST OF FIGURES
Figure 6.4	Format of the Common Part of the OAM Cell	2
Figure 6.5	Fault Management-Specific Fields	5
Figure 6.6	Performance Management-Specific Fields	5
Figure 6.7	Activation/Deactivation Management-Specific Fields	6
Figure 6.8	Terminating and Intermediate Equipment at a B-ICI	7
Figure 6.9	The Loopback Function	9
Figure 6.10	A Performance Monitoring Block	12
Figure 6.11	Segment Performance Monitoring Across a B-ICI	14
Figure 6.12	End-to-End Performance Monitoring Across a B-ICI	15
Figure 6.13	Examples of Performance Monitoring of Connections and Segments	16
Figure 6.14	Handshaking Procedure for PM Activation and Deactivation	18
Figure 6.15	Responses to PM Deactivation Requests	21
Figure 7.1	An Example B-ICI Signaling Architecture - BISUP over ATM in the Associated Mode	29
Figure 7.2	An Example B-ICI Signaling Architecture - BISUP in the Quasi-Associated Mode	30
Figure 7.3	Network Signaling Protocol Stack for Transport of Signaling Messages at the B-ICI	31
Figure 7.4	Example of a Successful Call and Connection Set up Sequence	41
Figure 7.5	Example of an Unsuccessful Call and Connection Set up Sequence	42
Figure 7.6	An Example of B-ICI Reference Configuration Supporting SVC Services	44
Figure 7.7(a)  Set-up of a Unidirectional Point-to-Multipoint Call (Continued)	86
Figure 7.7(b)  Set-up of a Unidirectional Point-to-Multipoint Call (Concluded)	86
Figure 7.8	Drop of a Leaf Party by the Root or the Leaf Party Itself	87
Figure 7.9	En Bloc Release of the Call by the Root	88
Figure 12.8	Example Reference Configuration	113
Figure 12.9	Originating Carrier Network Usage Information	117
Figure 12.10  Terminating Carrier Network Usage Information	121
Figure 12.11  Point-to-Multipoint SVC	122
Figure 12.12  Point-to-Multipoint SVC in the Originating Carrier Network	123
Figure 12.13  Point-to-Multipoint SVC in the Terminating Carrier Network	123
LIST OF TABLES

Table 6.2	OAM Type/Function Type Identifier.....................................................4
Table 6.3	Message ID Field Values in the Activation/Deactivation Cell	.......................17
Table 6.4	PM Block Size Encodings................................................................18
Table 7.1	ATM Forum's B-ICI Signaling Capabilities, and the ITU-T Work.................27

The scope of the ATM Forum B-ICI Specification, Version 2.0, covers generation of an implementation agreement including principles, guidelines, Requirements (R)s and Options (O)s to support SVC-based inter-carrier services (CRS, CES, FRS) on a multi-service B-ICI. In general, the B-ICI specification to support SVC-based inter-carrier services builds upon the B-ICI specification (Version 1.1, September 1994) completed and published for the PVC-based inter-carrier services support.

Changes to The ATM Forum B-ICI Specification, Version 1.1, September 1994, Sections 6.2.2 and 6.2.3 are indicated with change bars in the text below. This text  entirely replaces the corresponding sections in Version 1.1.  

The Virtual Path (VP) operations information is carried via the F4 flow OAM cells. These cells have the same VPI value as the user-data cells but are identified by pre-assigned VCI values. Two unique VCI values are used for every VPC as shown in Figure 6.4. The VCI value = 3 is used to identify a connection between ATM layer management entities (LMEs) on both sides of the B-ICI (e.g., single link segment), and VCI value = 4 is used to identify a connection between end-to-end ATM LMEs.

The Virtual Channel (VC) operations information is carried via the F5 flow OAM cells. These cells have the same VPI/VCI values as the user-data cells but are identified by pre-assigned code points of the PTI field. Two unique PTI values are used for every VCC as shown in Figure 6.4. The PTI value = '100' (i.e., 4) is used to identify the connection between ATM LMEs on both sides of the B-ICI (e.g., single link segment) while the PTI value = '101' (i.e., 5) is used to identify connections between end-to-end ATM LMEs.

End-to-end OAM cells must be passed unmodified by all intermediate nodes. The contents of these cells may be monitored by any node in the path. These cells are only to be removed by the end point of the VPC (F4 flow) or VCC (F5 flow). Segment OAM cells shall be removed at the end of a segment. The format of the common part of the OAM cell is shown in Figure 6.4.

The Error Detection Code (EDC) field of all OAM cells carries a CRC-10 error detection code computed over the OAM cell Information Field excluding the EDC field. It shall be the remainder of the division (modulo 2) by the generator polynomial of the product of x10 and the content of the OAM cell information field (i.e., OAM Cell Type, Function Type, Function Specific Fields, Reserved Field, excluding the EDC Field (374 bits). Each bit of the concatenated fields mentioned above is considered as coefficient (modulo 2) of a polynomial of degree 373 using the first bit as coefficient of the highest order term. The CRC-10 generating polynomial is: G(x) = 1+x+x4+x5+x9+x10. The result of the CRC calculation is placed with the least significant bit right justified in the CRC field.

One example test cell, with its corresponding calculated CRC-10 value, is shown below to provide some measure of assurance of a correctly implemented EDC generation function.

Example: CRC-10 for an RDI cell. The OAM Cell Type is "0001", the OAM Function Type is '0001', and the next 45 octets are all coded 6A hexadecimal. The Reserved Field consists of six "0" bits. The calculated CRC-10 is AF hexadecimal (i.e., "00 1010 1111"). The 48 octet Information Field is transmitted as:

	1 1	6 A	6 A	6 A	6 A	6 A	6 A	6 A	6 A	6 A	6 A	6 A
	6 A	6 A	6 A	6 A	6 A	6 A	6 A	6 A	6 A	6 A	6 A	6 A
	6 A	6 A	6 A	6 A	6 A	6 A	6 A	6 A	6 A	6 A	6 A	6 A
	6 A	6 A	6 A	6 A	6 A	6 A	6 A	6 A	6 A	6 A	0 0	A F

Appendix A of I.610 contains an additional example.

The OAM Cell Type field and the Function Type fields, as specified in ITU-T Recommendation I.610[25] are shown in Table 6.2.

The format of the function-specific fields of the Fault Management OAM cell, as defined in I.610[25], is shown in Figure 6.5.

The format of the function-specific fields of the Performance Management OAM cell, as defined in ITU-T Recommendation I.610[25], is shown in Figure 6.6.

The format of the function-specific fields of the Activation/Deactivation cell, as defined in ITU-T Recommendation I.610[25], is shown in Figure 6.7.

OAM Cell Type	Value	OAM Function Type	Value	
Fault Management	0001	AIS	0000	
		RDI	0001	
		Continuity Check	0100	
		Loopback	1000	
Performance Management	0010	Forward Monitoring	0000	
		Backward Reporting	0001	
Activation/Deactivation	1000	Performance Monitoring	0000	
		Continuity Check	0001	
System Management	1111	Not Standardized		

	(R) 6-27	Network equipment at a B-ICI shall encode/interpret the OAM cells 			according to the format and encoding rules defined in ITU-T 				Recommendation I.610[25] for the OAM functions defined in Section 6.2.3.

Further discussion on each of these cell types may be found in ITU-T Recommendation I.610[25] and GR-1248-CORE[27].

This section discusses the Fault Management and Performance Management OAM functions to be 
supported over the B-ICI.

The Fault Management functions at the B-ICI are grouped into three categories: Alarm Surveillance, Connectivity Verification, and Continuity Check.

Alarm surveillance at the B-ICI involves detection, generation, and propagation of VPC/VCC failures (failure indications). In analogy with the SONET physical layer, the failure indication signals are of two types:  Alarm Indication Signal (AIS) and Remote Defect Indicator (RDI). These signals are carried via OAM cells as defined in Section 6.2.2. The VP/VC AIS (VP-AIS and VC-AIS) is generated by a VPC/VCC node at a connecting point to alert the downstream VPC/VCC nodes that a failure has been detected upstream. The VP-AIS/VC-AIS can be caused by the detection of a VPC/VCC failure or by the notification of a physical layer failure. Upon receiving a VP-AIS/VC-AIS, a VPC/VCC end point at the B-ICI will return a VP-RDI/VC-RDI to alert the upstream nodes that a failure has been detected downstream.

Network equipment at a B-ICI may terminate a connection, or act as an intermediate (i.e., connecting) node. This is shown in Figure 6.8.

The following requirements apply to network equipment at the B-ICI that terminates a connection.

	(R) 6-28	Network equipment terminating a VPC at the B-ICI shall detect incoming 			VP-AISs and shall generate VP-RDIs in the upstream direction (toward 			the other carrier's network) to alert the ATM nodes about the failure.

	(R) 6-29	Network equipment terminating a VCC at the B-ICI that detects an incoming 			VC-AIS shall generate a VC-RDI in the upstream direction (toward the other 			carrier's network).

The following requirements apply to equipment at the B-ICI that acts as an intermediate connection.

	(R) 6-30	Network equipment at a B-ICI, acting as an intermediate VP node, shall 			generate a VP-AIS upon detection of a VPC failure or upon receiving a 			physical layer failure notification.

	(R) 6-31	Network equipment at a B-ICI, acting as an intermediate VC node, shall 			generate a VC-AIS upon detection of a VCC failure or upon receiving a 			physical layer failure notification.

The following requirement applies to both intermediate and terminating nodes.

	(R) 6-32	Network equipment at a B-ICI inserting Alarm Surveillance cells shall do so 			at a nominal rate of 1 cell per second per VPC or VCC, as specified in 			Section 6 of ITU-T Recommendation I.610[25]. The release conditions 			shall be as specified in ITU-T Recommendation I.610.

More detail on alarm surveillance may be found in ITU-T Recommendation I.610[25] and GR-1248-CORE[27].

Connectivity verification is supported by the use of the OAM loopback capability for both VP and VC connections. More complete details on this loopback function can be found in I.610 [25]. The VCC or VPC being checked can remain in service while this loopback function is being performed. The OAM Cell Loopback function supported at the B-ICI includes the following four fields:

	•	Loopback Indication - This eight-bit field identifies, for the end point receiving the OAM 	cell, whether the incoming cell is to be looped back. A value of '00000001' indicates that 	the cell should be looped back. All other values indicate that the cell is to be discarded. 	Before the cell is looped back, the end point shall encode the Loopback Indication field as 	'00000000'.

	•	Correlation Tag - At any given time, multiple OAM Fault Management Loopback cells may 	be inserted in the same virtual connection. As a result, the OAM cell loopback mechanism 	requires a means of correlating transmitted OAM cells with received OAM cells. The node 	inserting the OAM cell may put any value in this 32-bit field, and the end point looping 	back the cell shall not modify it.

	•	Loopback Location ID (Optional) - This 16 octet field identifies the point(s) along a virtual 	connection where the loopback is to occur. The default value of all ones is used by the 	transmitter to indicate the end point.

	•	Source ID (Optional) - This 16 octet field can be used to identify the originator of the 	Loopback cell so the originator can identify the looped back cell when it returns. This may 	be encoded any way that enables the originating point to be certain that it has received the 	cell it transmitted. The default value is all ones.

	(R) 6-33	Network equipment terminating a connection at a B-ICI that receives OAM 			cells with a Loopback Indication value other than '00000001', OAM Cell 			Type = '0001', and Function Type = '1000' shall discard the cell.

	(R) 6-34	Network equipment terminating a connection at a B-ICI that receives OAM 			cells with a Loopback Indication value of '00000001', OAM Cell Type = 			'0001', and Function Type = '1000', shall encode the Loopback Indication 			value as '00000000' and then loopback the cell within one second.

Network equipment inserting loopback cells will do so at a rate low enough to ensure that loopback cells amount to less than one percent of the capacity of any link in the connection.

An ATM-level loopback can be performed across the B-ICI using segment loopback cells which are looped back by the end point of a VPC or VCC segment. The segment can be defined as the link between the ATM nodes on either side of the B-ICI. Segment end points must either remove these cells or loop them back depending on the value in the Loopback Indication field. That is, these cells must not travel beyond the segment in which they are generated. Segment loopback cells are indicated by a PTI value of '100' for VCCs and a VCI value of 3 for VPCs. An example of how the segment loopback cell is used is shown in Figure 6.9.

End-to-end loopback cells (i.e., those with a Loopback Location ID of all 1s) are only looped back by the end point of a VPC or VCC. These cells may be inserted by any node in the connection (intermediate or end point) and may be monitored by any node. However, only end points may remove these cells. End-to-end loopback cells are indicated by a Payload Type Indicator (PTI) value of '101' for VCCs and a VCI value of 4 for VPCs. An example of how the end-to-end loopback cell is used is shown in Figure 6.9.

The switch supporting the B-ICI shall support the insertion of end-to-end loopback cells. It shall also support the copying of received loopback cells to check for the return of loopback cells it initiated.

The need for Continuity Check is for further study. If used for a connection that crosses a B-ICI, it could be activated/deactivated using the activation/deactivation "handshaking" procedures of ITU-T Recommendation I.610[25] or through TMN, using management system commands at each side of the B-ICI.  More detail on the Continuity Check procedure, and its activation/deactivation, may be found in I.610.

Performance Management functions at the B-ICI consist of monitoring selected connections for lost or misinserted cells, bit errors, and (optionally) cell delays. A node needs to only support performance monitoring for a limited number of connections or segments that it terminates. When used across a B-ICI, it must first be activated, either by using Activation/Deactivation OAM cells, as specified below in Section 6.2.3.3, or through TMN procedures.

The Performance Management cell payload structure is specified in ITU Recommendation I.610[25], and its function-specific fields are shown in Figure 6.6. The fields of the Performance Management cell are described below.

	•	OAM Cell Type:  The OAM Type is "Performance Management," encoded as 0010.

	•	Function Type:  The Function Type field specifies whether the cell is to be used for 	Forward Monitoring (0000) or Backward Reporting (0001). Figure 6.6 shows which 	fields are used only for the forward monitoring function, and which are used only for the 	backward reporting function.

	•	Monitoring Cell Sequence Number (MCSN):  This field carries the sequence number of the 	Performance Management cell, modulo 256. This field allows for the detection of a lost or 	misinserted Performance Management OAM cell. 

	•	Total User Cell Number related to the CLP=0+1 user cell flow (TUC-0+1):  This field 	indicates the current value of a running counter related to the total number (modulo 65536) 	of transmitted user cells (i.e., CLP=0+1), when the Forward Monitoring PM cell is 	inserted.  In case of a Backward Reporting PM cell, this field contains the TUC-0+1 value 	copied from the paired Forward Monitoring PM cell.

	•	Total User Cell Number related to the CLP=0 user cell flow (TUC-0):  The use of this field 	is similar to the use of the TUC-0+1 field.  It is related to the transmitted user cells with a 	CLP value equal to '0'.

	•	Block Error Detection Code (BEDC):  This field contains the even parity BIP-16 error 	detection code computed over the information fields of the block of user-data cells 	transmitted after the last monitoring cell. In the Backward Reporting PM cell, this field is 	unused, and all octets are encoded as "6A" hexadecimal.

	•	Time Stamp:  This field is optional and may be used to represent the time at which the OAM 	cell was inserted. T1S1.5/94-004[26] specifies that the time is encoded in units of .01 	micro-seconds. However, the node does not need to be accurate to .01 micro-seconds. (A 	precision of at least one micro-second seems sufficient.)  If the field is not used, this field 	is set to all 1s.  In the backward reporting cell, procedures for use of the time stamp field 	have not been defined, and so the field should be set to all 1s.

	•	Unused:  Octets in this field are encoded as "6A" hexadecimal ('01101010').

	•	Total Received Cell Count related to the CLP=0 user cell flow (TRCC-0):  This field is 	used for Backward Reporting OAM cells only.  The use of this field is similar to the use of 	the TRCC-0+1 field.  It is related to the total number of received user cells with a CLP 	value equal to '0'.

	•	Block Error Result (BLER0+1):  This field is used for Backward Reporting OAM cells 	only.  It carries the number of errored parity bits detected by the BIP-16 code of the paired 	Forward Monitoring cell.  This number is only inserted in the corresponding Backward 	Reporting Cell if the following two conditions are met:
		(i) The number of user data cells (i.e., CLP=0+1) between the last two Forward 		Monitoring OAM cells equals the difference between the TUC of the last two 		Forward Monitoring OAM cells
		(ii) The MCSN of the last two PM OAM cells used for forward monitoring are 		sequential.
Otherwise the field shall be encoded as all 1s. In the case of Forward Monitoring OAM cells, this field is unused and coded as 6AH.

	•	Total Received Cell Count related to the CLP=0+1 user cell flow (TRCC-0+1):  This field 	is used for Backward Reporting OAM cells only.  All user cells are considered (i.e., 	CLP=0+1).  This field carries the current value of a running counter related to the total 	number (modulo 65536) of received user cells (CLP=0+1), read when a Forward 	Monitoring PM cell is received.

This section describes the procedure of generating Performance Management OAM cells at a B-ICI. A Performance Management cell contains information about a block of user-information cells of one connection; Performance Management and other OAM cells such as Fault Management cells are not part of the block. Figure 6.10 illustrates the concept of a block. The allowable nominal block sizes are 128, 256, 512, and 1024 cells.

A Performance Management cell may be a forward monitoring PM cell, or a Backward Reporting cell.

The steps for generating PM cells when performing segment VP/VC performance monitoring are listed below.

	1.	The originating VP/VC segment end point will generate a BIP-16 error detection code over 	the payloads of the user information cells in the block. Then the end point will place the 	following information in the payload of a Performance Management OAM cell: the 	Monitoring Cell Sequence Number of the PM cell (modulo 256), the TUC0+1, the TUC0 	(modulo 65536), the BIP-16, and an optional Time Stamp. This OAM cell will be 	transmitted before the next user-information cell of the VPC/VCC. Although the block size 	for a segment has a nominal value, the actual size of any given block may vary from that 	nominal value. This variation allows PM cells to be inserted without delaying the flow of 	user cells.

	2.	The far-end VP/VC segment end point will compare the number of the cells received in the 	block with the difference between the received Total User Cell 0+1 (TUC0+1) count and 	the TUC0+1 count at the end of the last received block. A mis-match in this comparison 	indicates lost or misinserted cells. If no cells have been lost or misinserted and the MCSN 	of the PM cell is consecutive, the end point will compare the BIP-16 in the forward 	monitoring cell with the result of an identical BIP-16 calculation it has performed over the 	same number of user-information cells. A mis-match in this comparison indicates bit errors 	in the block. The number of errored parity bits in the BIP-16 code, the running count of 	received 0+1 cells, the running count of received 0 cells, as well as the TUC0+1 and TUC0 	of the corresponding transmitted cell, are stored until the backward reporting cell is sent. If 	the BLER cannot be calculated, the Block Error Result in the backward report is coded as 	all 1s.

	3.	The far-end VP/VC segment end-point will report the results back to the originating (i.e., 	near-end) VPC/VCC end point, using a Performance Management OAM cell to send a 	backward report. This report may be used by monitor points along the VPC/VCC to 	monitor end-to-end performance.

More detailed discussion about this procedure may be found in GR-1248-CORE[27].

	(R) 6-35	Network equipment at a B-ICI that terminates a segment on which 				performance monitoring is active in the outgoing direction, shall generate 			PM cells containing forward monitoring information. These cells shall be 			generated according to the procedures specified in ITU-T Recommendation 			I.610[25], and described in this section.

	(R) 6-36	Network equipment at a B-ICI that terminates a segment on which 				performance monitoring is active in the incoming direction, shall generate 			PM cells containing backward reporting information. These backward 			reports shall be generated according to the procedures specified in ITU-T 			Recommendation I.610[25], and described in this section.

	(R) 6-37	Network equipment at a B-ICI that sends backward reports shall send those 			reports within one second after receiving the PM cell with the forward 			monitoring information. The end point shall send backward reports in the 			same sequence in which the corresponding forward monitoring OAM cells 			were received.

This procedure is performed symmetrically for both directions of VPC/VCC transmission if bidirectional PM has been activated. Figure 6.11 shows a connection segment in which PM is active in both directions. This provides each VPC/VCC node in the segment the capability to monitor the bidirectional VPC/VCC. In Figure 6.11, the left-most point collects history data for both the left-to-right and right-to-left directions of user data flow. In configurations in which there are intermediate points, the intermediate point can collect history data for both directions as well.

A user may wish to have only uni-directional performance monitoring. In this case, there is still a bi-directional flow of PM OAM cells, because the reporting flow is needed across a B-ICI. There is one pair of PM cell flows for each direction of user data flow that is being monitored.

Network equipment at a B-ICI that is an intermediate point of a connection/segment over which PM cells are being generated should be capable of monitoring (i.e., copying) the PM cells to read the backward report. This allows a carrier to monitor the performance of connection/segment from one switch, when desired.

	(R) 6-38	Network equipment at a B-ICI shall be capable of generating PM cells on a 			minimum number of simultaneous connections/segments. This minimum 			number depends on the rate of the interface.

In some cases, equipment at one end of a B-ICI may be at the end point of a connection on which end-to-end performance monitoring is desired. Thus equipment that terminates a B-ICI should support performance monitoring of end-to-end VP/VC connections. Figure 6.12 shows an end-to-end connection that terminates at a B-ICI at one end point. (For example, the network equipment supporting the B-ICI might provide SMDS service.) In this example, only one direction of user information cells is being monitored, and history data is collected only at the intermediate point.

The procedures for end-to-end VP/VC performance monitoring are essentially the same as the end-to-end procedure described earlier. One difference is that Performance Management OAM cells are inserted and extracted at the end points of the connection, instead of at end points of a segment. The second difference, as specified in ITU-T Recommendation I.610[25], is that PM cells are "forced" into the connection when necessary to ensure that a fixed average block size is maintained. However, the actual size of any given block may vary + 50% from that nominal value. This variation allows PM cells to be inserted without delaying the flow of user cells in most cases.

	(R) 6-39	Network equipment at a B-ICI shall support end-to-end performance 			monitoring for specified VPC/VCC connections. This entails following the 			same requirements as for segment performance monitoring, except that the 			generation of Performance Management cells occurs at connection end 			points, and an average block size is enforced.

This section presents the procedure for activating and deactivating the VP/VC level performance monitoring function across a B-ICI. The procedures presented here apply to equipment at a B-ICI activating the monitoring function for either end-to-end VP/VC connections or VP/VC segments,  as long as at least one connection/segment end point is at a B-ICI. The term "connection/segment" is used to refer to either the entire end-to-end VP/VC connection or a segment of it. One or both end points of the connection/segment may be at a B-ICI, as shown in Figure 6.13.

The activation/deactivation of VP/VC performance monitoring at a B-ICI is a system management function, initiated by the appropriate Management System through the Telecommunications Management Network (TMN). Initiation may be done entirely via TMN (in which case the different administrations must coordinate - see I.610 for more information), or by using Activation/Deactivation OAM cells.  Within an administration, TMN may be adequate, but OAM cell use is attractive across carrier boundaries.

The activation/deactivation cell format, as defined in ITU-T Recommendation I.610[25], is shown in Figure 6.7, and each field is briefly described below.

Message	Value	
Activate	000001	
Activation Confirmed	000010	
Activation Request Denied	000011	
Deactivate	000101	
Deactivation Confirmed	000110	
Deactivation Request Denied	000111	

	•	Message ID (6 bits):  This field indicates the message ID for activating or deactivating 	VP/VC functions. Code values for this field are shown in Table 6.3.

	•	Directions of Action (2 bits): This field identifies the direction(s) of transmission to activate 	or deactivate the OAM function. The A-B and B-A notation is used to differentiate between 	the direction of user data transmission away from or towards the activator/deactivator, 	respectively. This field value is used as a parameter for the "Activate" and "Deactivate" 	messages. This field shall be encoded as '01' for B-A, '10' for A-B, '11' for two-way 	action, and '00' (default value) when not applicable.

	•	Correlation Tag (8 bits):  A correlation tag is generated for each message so nodes can 	correlate commands with responses.

	•	PM Block Size A-B (4 bits): This field specifies the A-to-B PM block size required by the 	activator for Performance Monitoring. Currently defined values are shown in Table 6.4. 	This field value is used as a parameter for the "Activate" and "Activation Confirmed" 	messages. The default value for this field shall be '0000' for all other messages and when 	activating/deactivating Continuity Check.

	•	PM Block Size B-A (4 bits):  This field specifies the B-A block size required by the 	activator for the Performance Monitoring function. It is encoded and used in the same 	manner as the PM Block Size A-B field.

Message Type	PM Block Size	Coding	
Other	unused	0000	
Activate	1024	0001	
and 	512	0010	
Activate Confirmed	256	0100	
for performance monitoring	128	1000	

The performance monitoring activation and deactivation handshaking procedures are illustrated in Figure 6.14. In the figure, the vertical flows represent messages or stimuli provided by an external source, such as a Management System via the TMN, to activate performance monitoring over a particular VP/VC connection or segment. The horizontal flows represent operations messages internal to the VP/VC itself via OAM cells. For the purposes of this specification, at least one, and possibly both, of the end points are at a B-ICI. The message flows for activating and deactivating performance monitoring (PM) are specified in ITU-T Recommendation I.610[25].

The following two sections provide a verbal description of the figure, to clarify the actions implied by the "handshaking" figure.

Below is a verbal description of the activation "handshaking" procedure.

	•	Request for PM Activation:  An end user or Management System initiates a request at one 	end of the connection/segment. By definition, this end point is "A", and the other end point 	is "B". The initiation includes a specification of the direction(s) of PM to activate, and the 	requested block size in the A-B direction (if appropriate) and the B-A direction (if 	appropriate). If end point A can accept the request, then end point A starts a >= 5 second 	timer. If end point A can support the PM request, it sends an "Activate" message, including 	the block size value and directions of action, to end point B.

	•	Send "Activation Confirmed" message or "Activation Request Denied" message: End point 	B determines whether it can support the requested block size. If it can, it sends an 	"Activation Confirmed" message to end point A. End point B begins the following 	processes:  (1) it generates PM cells, if PM was activated in the B-A direction, and (2) it 	waits to receive PM cells, if PM was requested in the A-B direction.

		If end point B cannot support the PM activation request, it sends an "Activation Request 	Denied" message back to end point A. End point A informs the PM activation requester of 	the denial.

	•	Beginning of PM at End Point A:  When end point A receives the confirmation, it begins 	the same activities that end point B did, where appropriate, and notifies its Management 	System that performance monitoring activities have begun.

The performance monitoring deactivation handshaking procedure is described below.

	•	Request for PM Deactivation:  An end user or Management System initiates a request at one 	end of the connection/segment. By definition, this end point is "A", and the other end point 	is "B". The initiation includes a specification of the direction(s) of PM to deactivate. The 	two PM Block Sizes fields are not used, and hence are coded as '0000'. End point A first 	determines whether PM cells are being generated in the requested direction. If not, the 	request is denied, and the PM deactivation requester is informed. If end point A can accept 	the request, then end point A starts a >= 5 second timer. If end point A has no reason to 	deny the deactivation request, it relays a "Deactivate" message to end point B.

	•	Send "Deactivation Confirmed" message:  End point B sends a "Deactivation Confirmed" 	message to end point A. End point B makes sure that PM cells are not being generated for 	the appropriate directions, if the deactivation request included the B-A direction.

•	Deactivation of PM at End Point A:  When end point A receives the confirmation or when the timer expires, it ends the same activities that end point B did, where appropriate, and notifies the appropriate Management System that performance monitoring activities have ended. 

More details on the PM activation/deactivation procedures are specified in I.610[25].

The following matrix indicates the response that should be returned and the actions that should be taken when a deactivation request is received.

The matrix indicates the four possible PM states (across the top of the matrix) that the receiving switch can be in when  it receives the Deactivation request. These four states are:

	1.	PM is not active,

	2.	PM is active in the user data flow A-B,

	3.	PM is active in both user data flows A-B and B-A, and

	4.	PM is active in the user data flow B-A.

There are three possible deactivation requests that can be received at B. They are:

	1.	Deactivate PM flow A-B,

	2.	Deactivate PM flow  in both directions A-B and B-A, and

	3.	Deactivate PM flow B-A.

The matrix shown in Figure 6.15 shows all combinations of possible activation states and received deactivation messages. There are two items described in each location of the matrix: 1) the response to the deactivation request by B, and 2) the action taken by B.

	(R) 6-40	In support of on-demand VP/VC Performance Monitoring for connections 			and/or segments terminated at a B-ICI, network equipment at a B-ICI shall 			provide the capability of activating and deactivating the VP/VC Performance 			Monitoring function according to the procedures specified in I.610[25], and 			described in Section 6.2.3.3.2.

In order to provide for early interoperability, initially only one-way activation is required.

	
	(R) 6-41	Network equipment at a B-ICI that receives an "Activate" message for 			Performance Monitoring shall support requests for PM in the direction of A-			B (i.e., when the "Directions of Action" field = '10'). It may also support 			activation requests for the direction B-A or for bi-directional activation (both 			A-B and B-A).

	(R) 6-42	When network equipment at a B-ICI receives an "Activate" or "Deactivate" 			message for Performance Monitoring, it shall send the appropriate return 			message within 1 second.

(R) 6-43	Network equipment at a B-ICI shall disable Performance Monitoring even if no response is received from a deactivation request before the timer expires.  For interoperability, the network equipment at a B-ICI shall send the deactivation request before disabling Performance Monitoring.

Network equipment at a B-ICI may choose to collect data on any VP/VC it terminates or accesses, on which Performance Monitoring is active (i.e., when PM cells flow over the connection/segment). Data collection is performed when requested by the appropriate Management System; activation/ deactivation of data collection is separate from the activation/ deactivation procedure for PM cells. 

This section provides network signaling specification for the multi-service B-ICI supporting switched services between the two carriers networks.

To achieve timely implementations and availability of equipment, a phased approach has been adopted in developing the B-ICI specification in the ATM Forum. The objective is to align the B-ICI signaling specification with other ATM Forum signaling specifications and base it on available standards. In particular, this version (Version 2) of the B-ICI specification provides the functionality of the ATM Forum's UNI 3.1 while being aligned with relevant ITU-T and ANSI-T1 BISUP standards.

As currently specified in this document, procedures for the ATM Forum ATM End System Addresses (AESAs) based on the Data Country Code (DCC) and International Code Designator (ICD) formats are not fully supported. The reason for this is to maintain compliance with ITU-T and ANSI BISUP standards. It is the intention of the B-ICI Working Group to address increased support for DCC and ICD formats as soon as ANSI or ITU-T standards are formed.

Certain services may require that optional elements of this B-ICI specification are implemented. For example, end-to-end carriage of Calling Party Number (CgPN) is required by the P-NNI and LAN Emulation specifications.

The following network signaling requirements for a B-ICI supporting Switched Virtual Connection (SVC) inter-carrier services have been generated. These requirements have guided the selection of a suitable signaling protocol for the B-ICI.

(a)	Service and Call Control Aspects

B-ICI signaling  is required to provide the  capability for establishing, maintaining, and releasing ATM connections for information transfer. B-ICI signaling supports SVC Cell Relay Service as described by the ATM Forum UNI Version 3.1 Specification.

The following capabilities are included in Version 2.0:

•	Support of point-to-point connections and unidirectional point-to-multipoint network
	connections.
•	Support of symmetric and asymmetric connections.
•	Support of variable bit rate connections.
•	Support of ATM end system addresses.
•	Support of call rejection due to unavailable ATM resources.
•	Support of a minimum set of peer-to-peer signaling network OAM functions, e.g.,
	blocking, testing, and reset.

•	Support of an efficient mechanism for fast identification of control plane associations
	(assignment of signaling messages to their call/connection) between two nodes by means of signaling identifiers.
•	Support of the evolution of services, protocol reusability, and version compatibility.

(b)	Signaling Message Transfer Aspects

The following requirements apply to the transfer of signaling messages:

	(R) 7-1	The carriage of B-ICI SVC signaling messages across the interface shall 			meet or exceed these existing network signaling reliability and availability 			requirements:
			(1) a message loss rate of less than 1 message in 107,
			(2) message mis-sequencing less than 1 in 108,
			(3) unavailability of signaling message transfer capabilities between two 			      signaling entities is less than 10 minutes a year.

	(R) 7-2	B-ICI signaling shall provide procedures to handle signaling message 			overload. Procedures to handle this could include:
			(1) back pressure to reduce signaling traffic,
			(2) rerouting signaling messages over alternative signaling paths,
			(3) call rejection,
			(4) signaling traffic load sharing.

	(R) 7-3	Failure of any B-ICI signaling message transfer capability shall not affect 			existing calls that are in the active state.

	(R) 7-4	Recovery of B-ICI signaling message transfer capability shall not affect 			existing calls that are in the active state.

Considering the network signaling requirements established above for the multi-service B-ICI, the ITU-T defined BISUP/BISDN NNI signaling system has been selected as the basis of future work in the ATM FORUM B-ICI SWG. The B-ICI signaling requirements that follow will be generated on the basis of available and ongoing standards work on BISDN NNI signaling.

For ATM-based signaling networks, the need for access to remote nodes such as a Service Control Point (SCP) is likely to become a higher priority due to the desire to offer more sophisticated services. This implies in the longer term either an associated network with direct links between BSSs and SCPs, or development of a quasi-associated network capability through ATM/Broadband compatible Signaling Transfer Point (STP) nodes or adjuncts.

Transaction Capabilities Application Part (TCAP) and Signaling Connection Control Part (SCCP) will be added to the protocol stack for ATM-based high speed links, to support transactions between BSS and SCP, or between remote BSSs. No change is required to these protocols from the existing ITU-T specifications, except that the existing SCCP cannot take advantages of the longer message lengths supported by the SAAL. Modifications to the SCCP to support longer message lengths are now under study in ITU-T.

The BISUP call control protocol is expected to evolve to support additional functions such as leaf-initiated actions and third party control capabilities, beyond the initial step of Capability Set (CS)-2. Separation of call and connection control has been adopted by ITU-T for the support of the multi-connection capability in Capability Set 2, Step 1 (CS-2.1) Recommendations. These enhancements are defined by ITU-T as additional Application Service Elements (ASEs) for BISUP using TCAP.

ABR and parameterized QOS are ATM Forum UNI 4.0 capabilities that future B-ICI versions will consider.

As shown in the Table 7.1, most of the B-ICI signaling requirements generated by the ATM Forum are consistent with the ITU-T's initial (Release 1) BISUP Recommendations, while others are consistent with CS-2 extensions. In particular, CS-2.1 extensions support point-to-multipoint connections and VBR services. Support of ATM Forum UNI 3.1 QOS classes may require additional coding in ITU.  ANSI BISUP has reserved four code points to support the ATM Forum UNI 3.1 QOS classes.

The selection of signaling capabilities from ITU BISUP/MTP Level 3 standards for the B-ICI Spec 2.0 implementation agreement are such that interoperability is assured between a device conforming to the ATMF B-ICI Spec 2.0 and a device conforming to the ITU BISUP Recommendations Q.2761-Q.2764, Q.2722.1 (point-to-multipoint), Q.2723.1 (Additional traffic parameters), Q.2726.1 (ATM End System Address) and Q.2210 (Broadband MTP Level 3) for all functionality that is common to both signaling protocols. The differences in functionality between this ATMF B-ICI Spec 2.0 implementation agreement and ITU BISUP/MTP Level 3 standards are indicated below. 

Interoperability is required for connecting:

•	An originating or intermediate BSS with a ATMF B-ICI Spec 2.0 interface to an BSS with the interface of an incoming international or intermediate international BSS, as specified in ITU's BISUP standards.

•	An BSS with the interface of an outgoing international or intermediate international BSS, as specified in ITU's BISUP, to an intermediate or destination BSS with a ATMF B-ICI Spec 2.0 interface.

If any ambiguities or inconsistencies are present in the ATMF B-ICI Spec 2.0 text due to rephrasing of functionality in ITU's BISUP standards, the original ITU text takes precedence. If the ATMF B-ICI Spec 2.0 text resolves any ambiguities in the original ITU BISUP text, the ATMF B-ICI Spec 2.0 text takes precedence. 

ATMF B-ICI Spec 2.0's BISUP requirements and ITU's BISUP/MTP Level 3 Recommendations have the same functionality for a large part. However, some differences are present, which are indicated below from a high level view.

ATMF B-ICI Spec 2.0 deliberately leaves out the following BISUP/MTP Level 3 functionality contained in ITU standards:

•	Difference between national and international BSSs
•	Interworking with N-ISDN (including overlap operation, A-law/µ-law conversion, early through-connect to prevent speech clipping, tones and announcements, and network-initiated Suspend and Resume
•	Propagation delay determination
•	User part availability procedure
•	Segmentation of messages for use of narrowband signaling links
•	MTP Level 3 quasi-associated signaling
•	MTP Level 3 Restart procedure (optional in B-ICI)
•	MTP Level 3 user part availability control

The omitted MTP features are not part of the MTP subset that has been specified in this document. This subset will be discussed in Section 7.7.

ATMF B-ICI Spec 2.0 contains additional functionality relative to ITU BISUP standards, which originates from the ANSI T1S1 BISUP standards. These enhancements are marked as carrier options throughout this document and only apply to networks using ANSI BISUP procedures:

•	Use of an additional BISUP message: 
	Exit message
•	Use of additional BISUP parameters: 
	Carrier Identification Code
	Charge Number
	Carrier Selection Information
	Outgoing Facility Identifier, and 
	Originating Line Information
•	Additional procedures for use of the Transit Network Selection parameter

A few capabilities are unique to ATMF B-ICI Spec 2.0:

•	Support of QOS classes
•	Some administrative requirements related to assignment of VPCs and configuration of message content
•	Procedures for usage measurement
•	Transport of non-E.164 AESAs

ATM Forum B-ICI Signaling Capabilities	Corresponding State of ITU-T BISUP Work	
Service and Call Control Aspects		
1. B-ICI shall support SVC Cell Relay
    Service (ATM Forum UNI Spec 3.1)	CBR Cell Relay supported by BISUP CS-1 specifications (ITU-T Recommendations Q.2761-4).
VBR and QOS supported by BISUP CS-2.1.	
2. B-ICI shall provide the capability for 
    establishing, maintaining and releasing 
    ATM connections.	Supported as indicated for Item 1.	
3. Support of VBR connections	Supported by BISUP CS-2.1 (Q.2723.1)	
4. Support of AESAs	Supported by BISUP CS-2.1 for E.164 AESAs (Q.2726.1)	
5. B-ICI shall support point-to-point and
    point-to-multipoint network connections.	Point-to-point connections supported BISUP CS-1, point-to-multipoint supported by BISUP CS-2.1.	
6. B-ICI shall support symmetric and 
     asymmetric connections.	Supported by BISUP CS-1.	
7. B-ICI shall support call rejection due to 
    unavailable ATM resources.	Supported by BISUP CS-1.	
8. A minimum set of peer-to-peer signaling
    network OAM functions, e.g., blocking, 
    testing and reset, shall be supported.	Supported by BISUP CS-1.	
9. B-ICI shall allow for evolution of services, 
    protocol reusability, and version compatibility.	Supported by BISUP CS-1.	
10. An efficient mechanism for fast identification of
     control plane associations between two nodes
     shall be required.	Supported by BISUP CS-1.	
Signaling Message Transfer Aspects		
11. The carriage of signaling messages across the
     interface shall meet or exceed existing network
     signaling reliability and availability 
     requirements.	Should be satisfied by SAAL and MTP Level 3 protocols used to support BISUP.	
12. B-ICI shall provide procedures to handle 
     message overload, such as backpressure,
     message rerouting, call rejection, and signaling
     traffic load sharing.	Should be satisfied by SAAL and MTP Level 3, plus BISUP procedures such as Automatic Congestion Control and BISUP Signaling Congestion Control.	
13. Failure of any B-ICI signaling message transfer
     shall not affect existing calls that are in the 
     active state.	Supported by BISUP CS-1.	
14. Recovery of B-ICI signaling message transfer 
      capability shall not affect existing calls that are
      in the active state.	Supported by BISUP CS-1.	

Note: In general, the BISUP capabilities in this Table are applicable to the interface between any two BISUP nodes, including both gateways between carriers and BSSs within one carrier.

This section describes example topologies for B-ICI signaling. In the first case, shown in Figure 7.1, supported by the Version 2.0, ATM virtual channel connections are used to transport BISUP signaling messages directly between BSSs. This type of signaling architecture is called associated mode signaling. The BISUP protocol is used for call control between BSSs. Although associated signaling links are used, it is assumed that the MTP Level 3 protocol is still used for network layer functions above the SAAL layer. It routes the BISUP messages to the appropriate outgoing link and supports management functions such as changeover of signaling traffic from a failed signaling link to a backup signaling link. The link speed is determined by parameter settings for the ATM connection. The SAAL protocol is designed to operate over a range of link speeds from 64 Kb/s to at least 4 Mb/s. 

Access to centralized databases (e.g., SCPs), requiring SCCP and TCAP, is beyond the scope of Version 2.0. Figure 7.1 shows a BSS accessing SCPs via a conventional SS7 link that is independent of the B-ICI. Alternatively, if a BSS implements only associated mode signaling over SAAL/ATM links at the MTP Level, but implements the necessary SCCP and TCAP functions, it can access an SCP if a SAAL/ATM link is directly connected to the SCP or to an SCCP relay point that can forward messages to the SCP.

In the second case, shown in Figure 7.2, signaling between BSSs is routed via signaling transfer points. This configuration is not supported by Version 2.0 of the B-ICI specification, but it may be used by bilateral agreement between the carriers. In this architecture, BISUP is still used as the call control protocol between BSSs. If needed, this architecture can also support access to centralized databases in addition to call setup and release. This type of signaling architecture is called quasi-associated signaling. 

Note:	B-ICI is the subject of this specification. Other interfaces are shown only to illustrate their relationship to the B-ICI.

Note 1: B-ICI is the subject of this specification.
Note 2: CCS links may or may not be over ATM.

	(R) 7-5	For the B-ICI Specification, Version 2.0, connection related signaling shall 			be associated mode using the "BISUP/MTP Level 3/SAAL/ATM/Physical" 			protocol stack shown in Figure 7.3.

MTP = Message Transfer Part, SCCP = Signaling Connection Control Part, TCAP = Transaction Capabilities Application Part

Signaling messages among the Broadband Switching Systems (BSS) can be transported using a virtual channel connection and the Signaling ATM Adaptation Layer (SAAL) defined for the Network Node Interface (NNI). The SAAL for the NNI has the same structure as the SAAL for the UNI. It comprises the Type 5 Common Part protocol, the Service Specific Connection Oriented Protocol (SSCOP), a Service Specific Coordination Function (SSCF), which in this case enhances the services provided by SSCOP to provide the layer service expected by MTP Level 3, and a layer management entity. 

	(R) 7-6	The BSS shall support the SAAL as defined in the ITU Recommendations 			I.363 (Common Part), Q.2110 (SSCOP), Q.2140 (SSCF), and Q.2144 			(Layer Management).

MTP Level 3 provides a connectionless network service and includes extensive network management procedures to route around failures of network components while minimizing message loss and missequencing. MTP Level 3 protocol and procedures for use with SAAL links are specified in ITU-T Recommendation Q.2210, which relies heavily on Recommendations Q.704 and Q.707. Depending on the interconnecting carriers and their networks, the appropriate national specification (e.g., ANSI T1.111-1996) may be used, rather than Recommendation Q.2210. This B-ICI specification does not repeat specification of the MTP Level 3 protocols and procedures themselves. Section 7.7 does specify, however, which of the MTP Level 3 procedures must be implemented to meet the B-ICI Version 2.0 requirements for associated mode signaling.

The protocol stack shown in Figure 7.3 is based on SS7 which is a family of protocol parts for different service and signaling network functions. Various protocol parts and combinations are suitable for B-ICI signaling. 

SS7 is designed for complex signaling networking involving many nodes and multiple networks. The overall objective of the lower levels of the protocol stack shown in Figure 7.3 (physical, ATM, SAAL, and MTP Level 3) is to provide a reliable means of information transfer, in correct sequence and without loss or duplication. MTP Level 3 provides the signaling message handling functions and the signaling network management functions. The former are the functions that direct a signaling message to the proper signaling link or higher level functions. The latter functions control message routing and configuration of the signaling network facilities. 

The B-ICI signaling protocol architecture takes advantage of the routing and network management capabilities offered by MTP Level 3 [68], along with the robustness of BISUP as the call and connection control signaling protocol. BISUP is designed for efficient virtual ATM call and connection control and management. The flexibility of the ATM switching fabric using cell relay as transport makes the use of ATM-based B-ICI signaling attractive for ATM SVC services support on a common (ATM-based) platform. The SAAL is used to package the signaling information into the cells which the ATM layer transfers across the network and to extract the information from the cells and from signaling information frames for use by the signaling application. 

Associated Mode signaling allows for the deployment of an MTP Level 3 subset. This section provides a simplified version (i.e., subset) of the "Full MTP Level 3" (used for the Quasi-Associated Mode) when MTP Level 3 is used above the SAAL in an ATM network (this is called Associated Mode Signaling). This simplified version of MTP Level 3 is possible because associated mode signaling does not require any Signaling Transfer Point (STP) functions between the signaling nodes.

MTP Level 3 procedures can be separated into four categories:

1.	Signaling Message Handling

2.	Signaling Link Management

3.	Signaling Route Management

4.	Signaling Traffic Management

The following subsections examine the MTP Level 3 procedures and specify an MTP Level 3 subset for associated signaling. 

Signaling Message Handling procedures consist of message discrimination, distribution, and routing. All of these procedures will still be needed. The Signaling Link Selection (SLS) code will still be needed to ensure message sequencing for multi-link signaling link sets. Because multi-link link sets could be desirable for reliability reasons (with links of the same link set on diverse physical facilities), it is recommended that both the SLS code and load sharing capability be retained in the associated signaling mode.

Each signaling link is configured with exactly one Signaling Link Code (SLC). If a signaling link set contains multiple links, a set of SLCs is associated with the signaling link set, and there shall be load sharing among the signaling links of the signaling link set.

A BSS is capable of being configured so that at least one Signaling Point Code (SPC) is assigned to it. The signaling links of a signaling link set shall be configured to indicate the two associated SPCs. 

Signaling Link Management procedures consist of the following:

•	Activation / Restoration / Deactivation
•	Signaling Link Test
•	Automatic Allocation of Signaling Terminals and Signaling Data Links
•	False Link Congestion Detection (an ANSI network enhancement which detects false link 	congestion)
•	Link Oscillation Filter (an ANSI network enhancement which controls the maximum link 	oscillation rate)

Link Activation, Restoration, and Deactivation procedures are needed independent of the network configuration. Only basic link management procedures have been specified for SAAL links in ITU-T Recommendation Q.2210; so procedures for Automatic Allocation of Signaling Terminals or Signaling Data Links are not needed. 

It is recommended to retain both the Signaling Link Test and False Link Congestion Detection (for North American networks) for network reliability in associated signaling. The Signaling Link Test can detect link irregularities such as looped links and crossed links. 

Because the Link Oscillation Filter procedure is designed primarily to prevent STP overload caused by multi-link oscillations, it is not needed for associated signaling, although it is possible that the procedure can be useful for a very large associated signaling network.

The Signaling Route Management procedures are STP related procedures and are not needed for associated signaling.

Signaling Traffic Management procedures consist of the following:

•	Changeover / Changeback
•	Management Inhibit
•	Forced / Controlled Rerouting
•	MTP Restart
•	Signaling Traffic Flow Control

While Changeover / Changeback and Management Inhibit procedures are not needed for single-link link sets, they are useful procedures for networks with multi-link link sets (which could be desirable for reliability reasons). It is recommended to retain these procedures for associated signaling. Management Inhibit can be initiated through Management System commands. 

Forced / Controlled Rerouting are STP related procedures, and are not needed for associated signaling. 

MTP Restart is designed to protect the restarting node by giving the restarting node time to BSS routing data (regarding remote signaling points) with the adjacent available signaling points and to activate sufficient links. In an associated signaling network, there is no need for the restarting node to BSS routing data regarding remote signaling points with the adjacent available signaling points. While MTP Restart can still be desirable for a large associated signaling network by allowing a restarting signaling point sufficient time to activate its links, it may not be needed for initial specification. It is recommended to have MTP Restart as an optional procedure.

Signaling Traffic Flow Control notifies an MTP user (e.g., BISUP) of the availability, unavailability, and congestion of signaling route sets so that the user can control traffic for the affected destinations appropriately. It also notifies the user of the unavailability of a remote  peer (of the user) through user part availability control procedures. The capability to notify the user of the availability, unavailability, and congestion of signaling route sets is needed in any network configuration and is required in Version 2.0. The usefulness of the MTP user part availability control procedure, however, depends largely on whether MTP users can fail independently. This is not required for Version 2.0.

	(R) 7-7	In support of MTP Level 3 in associated mode, the BSS shall:

				•	Support the signaling message handling procedures of message
				discrimination, distribution, and routing.

			•	Support the signaling link management procedures of link 					Activation, Restoration, and Deactivation; and of Signaling Link 				Test. 

			•	Support Changeover / Changeback and Management Inhibit (for 				multi-link link sets only) 

			•	Support Signaling Traffic Flow Control procedures except for 				user part availability control.

	(R) 7-8	As a carrier option (see Section 7.3.2.2), in support of MTP Level 3 in 			associated mode, the BSS shall support the signaling link management 			feature of False Link Congestion Detection.

	(O) 7-1	In support of MTP Level 3 in associated mode, the BSS should support  			MTP Restart.

For the set up and release of basic point-to-point calls, the following BISUP call connection control messages are used: Initial Address Message (IAM), Address Complete Message (ACM), IAM Acknowledgment Message (IAA), IAM Reject Message (IAR), Exit Message (EXM), Release Message (REL), Release Complete Message (RLC), Answer Message (ANM), and Call Progress Message (CPG). Subsequent address and forward transfer messages are defined in the ITU-T BISUP recommendations, but are not used in this implementation agreement. First, the assignment procedures for Virtual Path Connection Identifier/ Virtual Channel Identifier (VPCI/VCI) and bandwidth and the assignment procedures for signaling identifiers are described because they are applicable to all types of BSSs - originating, intermediate and destination BSSs. Then, actions specific to each type of BSS are described. The call and connection control functions and procedures are based on, and are consistent with, the ITU-T BISUP Recommendations[69-88]. 

	(R) 7-9	BISUP timers and timer values defined in ITU-T Rec. Q.2764 shall be 		applicable.

On an interface, a given VPI that provides VC service is designated to provide one of the following possible functions:

	(a)	Only PVC VC connections are allowed,
	(b)	Only SVC VC connections are allowed, or
	(c)	Both PVC and SVC VC connections are allowed.

Support of Case (c) is not required, however, neither is it precluded. In cases (b) and (c), the VPC is assigned a VPCI, and in Case (c), it must be clearly specified which VCI range is under the control of BISUP (i.e., to support SVCs). Furthermore, for Case (c), SVC procedures (e.g., Reset) must only affect the SVC range of VCIs within the VPCI.

The one side selection method of VCI values for a given VPCI, which allows one BSS to be the assigning BSS for both outgoing and incoming calls for a specific VPCI, is adopted to completely prevent dual seizure. This method is described below.

	(R) 7-10	For proper operation of BISUP, the one side selection method shall apply 			for all VPCs (that support SVCs) between two BSSs whether the two BSSs 			are in the same or different networks.

Each BSS allocates its own bandwidth to a given VPCI/VCI as a result of a CAC calculation on the traffic descriptors in the IAM.

	(R) 7-11	Before a route between two BSSs can be put into service, the following 			is necessary:

		•	The VPCI to be used shall be assigned unambiguously and 				identically at both ends of each VPC between the two BSSs.

		•	The VPCI shall be associated with the two appropriate SPCs at the 		BSSs.

		•	For every VPCI, it shall be defined which BSS controls this VPCI, 			i.e., which BSS is responsible for assigning bandwidth and the 			VCIs for this VPCI.

	(R) 7-12	The following default mechanism for determining assigning/ non-assigning 			designation shall be supported by every BSS:

		Each BSS shall be the assigning BSS for one half of the VPCI values 		between two BSSs. The BSS with the higher signaling point code shall 		be the assigning BSS for all even numbered VPCI values, and the other 		BSS shall be the assigning BSS for all odd numbered VPCI values.

	(R) 7-13	For an outgoing call/connection (including an automatic repeat attempt), a 			BSS shall first use a VPCI which it controls; i.e., an IAM including the 			Connection Element Identifier parameter containing the selected VPCI/VCI 			values shall be sent. Only if there is not sufficient bandwidth of acceptable 			QOS, or VCIs related to the VPCIs which the BSS controls and which can 			fulfill the bandwidth requirement of the call, the BSS shall send an IAM 			without the Connection Element Identifier parameter. In this case, the far 			end BSS will be expected to assign a VPCI/VCI from the set of VPCIs it 			controls.

The assigning BSS assigns both VPCI/VCI and bandwidth (according to its CAC procedures) for outgoing and incoming calls. The non-assigning BSS does not assign but requests the assigning BSS to assign both VPCI/VCI and bandwidth.

(a)	Outgoing Calls from the Assigning BSS to the Non-Assigning BSS

	(R) 7-14	The assigning BSS shall perform the following actions:

•	Selection of a VPC (identified by a VPCI) from the available VPCs it controls which can allocate the bandwidth according to the requested ATM Cell Rate and acceptable QOS.

•	Assignment of bandwidth and a VCI value to the call/ connection. VCI values 0 to 15 shall not be used. 

•	Updating the bandwidth and VCI value per VPCI and sending an IAM including the selected VPCI/VCI values (in the Connection Element Identifier (CEI) parameter) towards the non-assigning BSS. The VPCI subfield (octets 1 and 2) of the CEI shall contain the code expressing in pure binary representation the identifier of the virtual path connection. Bit 8 of octet 1 is the most significant and bit 1 of octet 2 is the least significant. The VCI subfield (octets 3 and 4) shall contain the code expressing in pure binary representation the identifier of the virtual channel. Bit 8 of octet 3 is the most significant and bit 1 of octet 4 is the least significant. The value of this field shall be the same as the value used in the VCI field of the corresponding ATM cell header. 

	(R) 7-15	The non-assigning BSS shall allocate the VPCI/VCI values and				bandwidth (according to its CAC procedures) for the call and return an IAA 			to the assigning BSS. If this is not successful, an IAR is returned.

(b)	Outgoing Calls from the Non-Assigning BSS to the Assigning BSS

	(R) 7-16	The non-assigning BSS shall perform the following actions:

•	Sending the IAM without the CEI.
•	Allocating the VPCI/VCI values contained in the CEI for the call on receipt of IAA from the assigning BSS.

	(R) 7-17	The assigning BSS shall perform the following actions:

•	Selection of a VPC (identified by a VPCI) it controls that has enough bandwidth of acceptable QOS and a VCI value available on receipt of the IAM. VCI values 0 to 15 shall not be used. 

•	Updating the bandwidth and VCI value per VPCI and sending an IAA with the selected VPCI/VCI values (in the CEI) towards the non-assigning BSS. The coding of the CEI shall be as described in (a) above. 

(c)	Simultaneous Call Request from the Assigning BSS and the Non-Assigning BSS

As the assigning BSS assigns bandwidth and the VPCI/VCI value at the time of call acceptance at the assigning BSS, a dual seizure of bandwidth or VPCI/VCI value cannot occur. If enough bandwidth is not available at the receipt of the call request, the call will be released with the cause value 51 ("Cell Rate not available"). 

	(R) 7-18	For abnormal conditions of the one-side selection method, the following 			procedures shall apply:

•	If an IAM with VPCI/VCI is received at the assigning BSS for that virtual path, an IAR shall be returned with the cause value 36 ("VPCI/VCI assignment failure"). The BSS receiving the IAM shall initiate the blocking procedure for the concerned VPCI.

•	If an IAM without VPCI/VCI is received at a BSS which is non-assigning for all virtual paths between the sending and receiving BSSs, an IAR shall be returned with the cause value 36 ("VPCI/VCI assignment failure"). 

•	If an IAA with VPCI/VCI is received at the assigning BSS for that virtual path, the event shall be reported to maintenance. The BSS receiving the IAA shall initiate the blocking procedure for the concerned VPCI, and shall release the call using the cause value 36 ("VPCI/VCI assignment failure"). 

•	If an IAA without VPCI/VCI is received at a BSS which sent an IAM without the CEI, the event shall be reported to maintenance, and the call shall be released using cause value 36 ("VPCI/VCI assignment failure").

To monitor for disagreements between signaling entities regarding which end is the assigning end, the following is required:

	(R) 7-19	For each VPCI, the BSS shall count and threshold a count of the number of 			disagreements regarding which BSS is the assigning node for a VPCI, and 			which BSS is not. This count shall include the following:

• IAM messages received with VPCI/VCI values specified for a VPCI for which the BSS is the assigning node.

• IAA messages received with VPCI/VCI values specified for a VPCI for which the BSS is the assigning node.

• IAM messages received without VPCI/VCI values at a BSS which is the non-assigning BSS for all VPCIs associated with that SPC pair (i.e., signaling link set).

• IAA messages received without VPCI/VCI values at a BSS which is the non-assigning BSS for all VPCIs associated with that SPC pair (i.e., signaling link set).

A Broadband Switching System (BSS) manages Signaling Identifiers (SIDs). These identifiers identify a signaling association and remain constant for the life of the signaling association. The SIDs need to be established for each bearer or maintenance control association between two BSSs. The two BSSs may be in the same or different networks. The SIDs are independently assigned by each of two BSSs concerned, A and B, enabling each switch to uniquely identify the signaling association (i.e., bearer control association or maintenance control association) and associate the signaling information with this particular signaling association. Figure 7.4 illustrates how SIDs are assigned and released for a successful call set up and release. Figure 7.5 illustrates how SIDs are assigned and released for an unsuccessful call set up.

For the example shown in these Figures, SID value Ai is assigned by BSS A when it sends the first message of a signaling association to BSS B; it is used to identify the signaling association at BSS A. SID value Bi is assigned by BSS B when it receives that first message of the signaling association from BSS A; it is used to identify the signaling association at BSS B.

Origination Signaling Identifier (OSID) parameter and Destination Signaling Identifier (DSID) parameter are used in BISUP messages to establish and identify signaling associations between a pair of BSSs. These parameters are used to carry the SIDs.

	(R) 7-20	A BSS shall have the capability of assigning a SID for each signaling 			association (bearer and maintenance control association) between itself and a 			connected BSS. 

	(R) 7-21	The following requirements apply for bearer (connection) control 				associations when BSS A sets up a connection to BSS B. For proper 			operation of BISUP, these requirements shall be met whether the two 			BSSs are in the same or different networks.

•	The Initial Address message sent by BSS A to BSS B shall contain Ai (the SID value assigned by BSS A) in the OSID.

•	The IAM Acknowledgment message sent by BSS B to BSS A shall contain Bi (the SID value assigned by BSS B) in the OSID and Ai in the DSID in order to allow mapping between the sending and receiving directions.

•	The IAM Reject message sent by BSS B to BSS A shall contain Ai in the DSID but no OSID.

•	All subsequent call/bearer control messages (e.g., ACM) from BSS B to BSS A shall contain Ai in the DSID.

•	All subsequent call/bearer control messages (e.g., REL) from BSS A to BSS B shall contain Bi in the DSID.

Example of a scenario for assigning and releasing of the signaling associations; only the DSID and OSID of the messages are shown in Figure 7.4.

SID:	Signaling Identifier
Ai:	Signaling ID assigned by BSS A
Bi:	Signaling ID assigned by BSS B
DSID:	Destination Signaling Identifier (Parameter)
OSID:	Origination Signaling Identifier (Parameter)

	(R) 7-22	The BSS at the B-ICI shall:

				•	accept the E.164 address structure for the Called Party Number 				(CdPN) and Calling Party Number (CgPN) parameters

				•	accept the three formats of the AESA structure as defined in UNI 				3.1 (Section 5.1.3.1) for the transparent transport via AESA for 				Called Party and AESA for Calling Party parameters.

As an option, a carrier may support DCC and ICD AESAs in the CdPN IE of the incoming SETUP message at the UNI. It is the responsibility of the carrier to produce a valid IAM to be propagated across the B-ICI. If the Transit Network Selection (TNS) IE is present in the SETUP message, it will be used for routing purposes as specified in (R) 7-24.

The ATM Forum's UNI Specification supports only the International Format of the E.164 address structure. To be consistent and ease the interoperability, the B-ICI will also support only the International Format of the E.164 address structure.

Figure 7.6 shows an example of the reference configuration for the B-ICIs supporting SVC service. Calling party is the user that sends a DSS2 SETUP message to the ATM network to request a switched virtual connection. Originating BSS is the ATM switch that receives and processes the SETUP message. When the originating BSS has received a valid DSS2 SETUP message from the calling party and has determined that the call is to be routed to another BSS, route and virtual channel selection take place. If the call needs to be routed to another carrier, it will be set up either on a direct connection from the originating BSS to a BSS in the other carrier's network or on a connection through an intermediate BSS. In the former case, the originating BSS provides the connection to the BSS belonging to the other carrier's network via the B-ICI. In the latter case, the intermediate BSS provides the connection to the BSS belonging to the other carrier's network via the B-ICI.

The call may be handled by one or more transit carriers before reaching the terminating carrier. In some cases, the call may not be handled by a transit carrier at all. The call may pass to the terminating BSS on a direct connection from the preceding carrier or via an intermediate BSS belonging to the terminating carrier. In the former case, the terminating BSS provides the B-ICI and, in the latter case, the intermediate BSS provides the B-ICI. Terminating BSS is the ATM switch that processes the incoming call request (IAM) and sends a DSS2 SETUP message to the called party. The called party is the destination UNI identified in the calling party's SVC request.  It is assumed that both the calling and the called parties use public UNIs and all carriers involved are public carriers.

(a)	Route and Virtual Channel Selection - Assigning BSS

Appropriate routing information is stored either at the originating BSS or at a remote database to which a request is made. Route selection will depend on the information contained in the SETUP message (e.g., Called Party Number, Broadband Bearer Capability, ATM Cell Rate, QOS, and TNS), subscription parameters applicable to the originating interface and the applicable network resources and their status.

Example codings of the message and parameter compatibility information are given in Appendices I and II of Q.2764, respectively.

When a call needs to be routed to another carrier, it will be set up either on a direct connection from the originating BSS to a BSS in the other carrier's network or on a connection through an intermediate BSS. In the latter case, the intermediate BSS provides the connection to the BSS belonging to the other carrier via the B-ICI.

The BSS shall deliver a valid E.164[55] address in the CdPN parameter across the B-ICI.

The selection of the route can depend on the Called Party Number, Broadband Bearer Capability, ATM Cell Rate, QOS, TNS, and the outcome of the virtual channel assignment procedure (see Section 7.8.2.2 (a)). The selection process may be performed at the BSS or with the assistance of a remote database.

	(R) 7-23	The originating BSS that acts as an assigning BSS for the call shall 			assign VPCI/VCI values and bandwidth as described in Section 7.8.2.2 (a).

Currently, carriers in the U.S. (e.g., IECs) are identified by 3-digit carrier identification codes (XXX codes). Starting in 1995, these codes are allowed to be expanded to 4-digit codes (XXXX). Therefore, the requirements in this document take into account the possibility of both 3- and 4-digit carrier identification codes.

	(R) 7-24	As a carrier option (See Section 7.3.2.2), if a Transit Network Selection IE 			is included in the SETUP message, and the call is accepted by the network, 			the call shall be routed to the carrier indicated in the Transit Network 			Selection IE. The mandatory Called Party Number IE may contain no 			address digits or a valid set of address digits.

If a Transit Network Selection IE is not included, routing is based on the analysis of the Called Party Number in the Called Party Number IE in the SETUP message.

	(R) 7-25	As a carrier option (See Section 7.3.2.2), if a Transit Network Selection IE 			is not included and the Called Party Number IE indicates that the call needs 			to be routed to another carrier, the call shall be routed to the carrier identified 			by subscription at the Calling Party interface.

(b)	Route and Virtual Channel Selection - Non-assigning BSS

	(R) 7-26	For the originating BSS that acts as a non-assigning BSS for the call, 			the route and virtual channel selection  procedures shall be as defined in (a) 			Route and Virtual Channel Selection - Assigning BSS above for an 				assigning BSS except that the VPCI/VCI and bandwidth assignment 			procedures shall be according to Section 7.8.2.2 (b) Outgoing Calls from 			the Non-Assigning BSS to the Assigning BSS.

(c)	Address Information Sending Sequence

	(R) 7-27	The sending sequence of address information shall be the country code 			followed by the national (significant) number. 

(d)	IAM - Sent by the Assigning BSS

The IAM in principle contains all the information that is required to route the call to the destination BSS and connect the call to the called party (see Section 7.8.5.1.1 (a)). 

	(R) 7-28	The originating BSS that acts as an assigning BSS for this call shall 			include the CEI (containing the selected VPCI/VCI values) in the IAM as 			described in Section 7.8.2.2 (a).

	(R) 7-29	The originating BSS shall include the OSID (containing the selected SID) 			as described in Section 7.8.3. 

Broadband Bearer Capability Information Element (IE) is received in the SETUP message from the user. This IE indicates the broadband connection oriented bearer service requested by the calling user.

	(R) 7-30	The originating BSS shall include the Broadband Bearer Capability (BBC) 			parameter in the IAM. The coding of the coding standard subfield shall be 			identical with the corresponding subfield coding in the received IE. The 			contents of the parameter starting from octet 2 shall be identical with the 			contents of the IE starting from octet 5. 

The ATM Traffic Descriptor IE in the SETUP message from the user indicates the required traffic parameters for the requested call. Traffic parameters include peak forward and backward cell rates with Cell Loss Priority (CLP) = 0 and 0+1, sustainable cell rate, etc. Requirements in the current version of this document support symmetric and asymmetric switched connections characterized by forward and backward peak cell rate, sustainable cell rate, and maximum burst size with CLP = 0 and 0+1. Symmetric connections are characterized by identical sets of traffic parameters for the forward and backward directions. Asymmetric connections are characterized by two sets of traffic parameters, one each for the forward and backward directions.

	(R) 7-31	The originating BSS shall include the ATM Cell Rate parameter in the IAM. 			The coding of this parameter shall be based on the ATM Traffic Descriptor  			IE in the SETUP message from the user. The only allowed codings of the 			cell rate identifier subfields shall be forward and backward peak cell rate, 			forward and backward sustainable cell rate, and forward and backward 			maximum burst size for CLP = 0 and 0+1. The cell rate subfields shall be 			coded according to the cell rates requested by the user. Symmetric and 			asymmetric cell rate connections for CLP = 0 and 0+1 shall be supported.

The Quality of Service IE in the SETUP message from the user indicates the requested quality of service class for the call. Quality of Service includes the QOS class forward and QOS class backward. Requirements in the current version of this document support connections with five possible QOS classes as defined in the ATM Forum UNI 3.1 specification (Unspecified, Class 1, Class 2, Class 3 and Class 4).

	(R) 7-32	The originating BSS shall include the Quality of Service parameter in the 			IAM. The coding of this parameter shall be based on the Quality of Service 			IE in the SETUP message from the user. The allowed codings of the QOS 			class forward and backward include Unspecified, Class 1, Class 2, Class 3 			and Class 4.  If information about the requested QOS Class is not available 			at the destination BSS, the destination BSS shall generate the default 			value ("unspecified QOS Class") for the QOS parameter IE in the SETUP 			message to the called user.

	(R) 7-33	The originating BSS shall include the Calling Party's Category parameter 			coded as "ordinary calling subscriber" in the IAM.

	(R) 7-34	The originating BSS shall include the Called Party Number parameter in the 			IAM. In addition, AESA for Called Party Number parameter shall be 			included if the received Called Party Number IE in the SETUP message 			contains AESA (as indicated by the code "0010" in the 					Addressing/Numbering Plan Identification subfield).

Inclusion of an AESA for Called Party Number parameter does not preclude the inclusion of the optional Called Party Subaddress parameter.

	(R) 7-35	The address digits in the Called Party Number IE in the SETUP message 			shall determine the coding of the address digits and the nature of address in 			the Called Party Number parameter. 

	(R) 7-36	The Called Party Number parameter shall be formulated as follows:

			Octet 1:  

			Bit 8 (the odd/even bit) shall be coded as follows:

		0	If an even number of address digits or no address digits are included 			in the address information field (beginning with octet 3)

		1	If an odd number of address digits are included in the address 			information field.

			Bits 7654321 (nature of address indicator) shall be codes 0000100 				(international number).

			Octet 2:

		Bit 8 (the internal network number indicator) shall be coded 0 indicating that 		routing to an internal network number is allowed.

		Bits 765 (the numbering plan indicator) shall be coded 001 (ISDN 			numbering plan - E.164).

		Bits 4321 are spare and shall be coded 0s.

			Octets 3-n:

			The address digits shall be mapped from the address digits in the Called 			Party Number IE (if Addressing/Numbering Plan Identification = 0001) or 			from the IDI of the AESA in the Called Party Number IE (if 				Addressing/Numbering Plan Identification = 0010). The coding of the 			address digits within the address information field shall be in Binary Coded 			Decimal (BCD) form. The first octet of this field shall contain the BCD code 			of the first address digit in bits 4321, and the BCD code of the second 			address digit in bits 8765. If an odd number of digits are sent, bits 8765 of 			the last octet of this field shall be set to 0000. 

	(R) 7-37	If the Called Party Number IE received by the originating BSS carries an 			E.164 AESA, the originating BSS shall map the E.164 part of the AESA 			(i.e., IDI) from the Called Party Number IE into the Called Party Number 			parameter as described in the preceding requirement. The called party 			number, containing only the E.164 part of the AESA, can be used together 			with other parameters (see Section 7.8.5.1.1 a), for routing the call through 			public networks. The entire AESA (20 octets) shall be carried in the AESA 			for Called Party parameter. 

The Calling Party Number (CgPN) parameter can be sent from the originating BSS towards the destination BSS as part of the IAM. If the call is to be routed to another carrier, the CgPN is included provided the originating carrier and the other carrier have made a prior agreement to transfer it across the B-ICI. The call may be routed from the originating BSS to the other carrier on a direct connection or on a connection to an intermediate BSS for a subsequent routing to the other carrier. 

	(R) 7-38	The originating BSS shall have the capability to be set to include or not 			include in the IAM the CgPN on a per connecting carrier basis. 

	(R) 7-39	If the call is to be routed to another carrier, the CgPN shall be included in 			the IAM if allowed for the specific carrier selected to route the call further. 

	(R) 7-40	The originating BSS shall include the CgPN in the outgoing IAM if its 			inclusion is allowed. If the Calling Party Number IE is provided by the 			calling party in the SETUP message, the BSS shall verify the validity of 			the E.164 address in this IE (if Addressing/Numbering Plan Identification = 			0001) or the E.164 part of the AESA in this IE (if Addressing/Numbering 			Plan Identification = 0010) by screening it against the set of addresses 			assigned to the interface. If the user provided calling number is valid, it 			shall be used to code the CgPN. The default address applicable to the 			originating interface shall be used when either no Calling Party Number IE 			is included in the SETUP message or the Calling Party Number information 			in the SETUP message is invalid (i.e., it does not pass screening).

	(R) 7-41	The coding of the CgPN shall be as follows:

			Octet 1:

			Bit 8:  Odd/Even Indicator - Coded as for the CgPN Parameter

			Bits 7654321 - Nature  of Address Indicator. Allowable codings are as 			follows:

			0000100 	(unique) international number
			1110100 	(non-unique) international number

			The type of number and numbering plan identification information in the 			Calling Party Number IE in the received SETUP message shall be used to 			code the nature of address indicator and numbering plan indicator subfields 			of the CgPN. If a user provided number that has passed screening is to be 			included in the CgPN, then a coding indicating unique shall be used. If a 			default  number is included in the CgPN, then the determination of unique 			or non-unique is based on whether the number is associated with a unique 			calling party. 

			Octet 2:

			Bit 8:  Calling Party Number incomplete indicator. Code as “0” if a user 			provided number is included (that is, the number has passed screening) or if 			a default number is provided. Code as “1” if neither a user supplied nor a 			default calling party number is available, and the CgPN is to be included in 			the IAM. 

			Bits 765:  Numbering Plan Indicator. 
			This indicator shall be coded 001 (ISDN numbering plan - E.164).

			Bits 43:  Address presentation restricted indicator. This field is coded based 			on information received in the calling party number IE or from subscription 			information associated with the default number. Expected codings are:
			00 - presentation allowed
			01 - presentation restricted (default)

			Bits 21:  Screening indicator.  Expected codes are:
			01 - user provided, verified and passed
			11 - network provided

			Octets 3-n:

			When the address digits are derived from the received Calling Party Number 			IE, the address digits shall be mapped from the address digits in the calling 			party number IE (if Addressing/Numbering Plan Identification = 0001) or 			from the IDI of the AESA in the calling party number IE (if 					Addressing/Numbering Plan Identification = 0010).The coding of the 			calling party address digits within the address information field shall be in 			Binary Coded Decimal (BCD) form. The first octet of this field shall contain 			the BCD code of the first address digit in bits 4321, and BCD code of the 			second address digit in bits 8765. If an odd number of digits are sent, bits 			8765 of the last octet of this field shall be set to 0000.

	(R) 7-42	If the received Calling Party Number IE in the SETUP message contains an 			AESA (as indicated by the code "0010" in the Addressing/Numbering Plan 			Identification subfield), the AESA for Calling Party parameter will be 			included in the IAM provided its inclusion is allowed by subscription or 			prior arrangement.  The entire AESA (20 octets) shall be carried in the 			AESA for Calling Party parameter.  The inclusion of the AESA for Calling 			Party parameter in the IAM is in addition to the inclusion of the Calling 			Party Number parameter. 

The Calling Party Subaddress, Called Party Subaddress, Broadband High Layer Information, Broadband Low Layer Information and ATM Adaptation Layer (AAL) parameters can be transparently sent (i.e., without processing in the network) from the originating BSS towards the destination BSS using the IAM. The transfer of this information is based on meeting the following two conditions:

1.	The transfer is allowed by the subscription parameters applicable to the originating user access interface. The originating BSS uses these subscription parameters to determine the applicability of call requests and services. 

2.	The originating carrier and the connecting carrier have made a prior agreement to transfer this information across the B-ICI if the call is to be routed to that carrier. The call may be routed from the originating BSS to the connecting carrier on a direct connection or on a connection to an intermediate BSS for a subsequent routing to that carrier. 

	(R) 7-43	The originating BSS shall have the capability to be set to include or not 			include in the IAM the Calling Party Subaddress, Called Party Subaddress, 			Broadband High Layer Information, Broadband Low Layer Information 			and AAL parameters based on the subscription parameters applicable to the 			originating UNI and on a per connecting carrier basis. 

	(R) 7-44	If the call is to be routed to another carrier, the parameters mentioned in the 			preceding requirement shall be included in the IAM provided the transfer of 			this information is allowed both by the user subscription and the specific 			connecting carrier selected to route the call further. 

	(R) 7-45	The originating BSS shall include the Calling Party Subaddress parameter 			in the outgoing IAM if its inclusion is allowed and the Calling Party 			Subaddress IE is received in the SETUP message from the calling user. The 			coding of the standard subfield shall be identical with the corresponding 			subfield coding in the received IE. The contents of the parameter starting 			from octet 2 shall be identical to the contents of the IE starting from octet 5. 

Inclusion of an AESA for Calling Party Number parameter does not preclude the inclusion of the Calling Party Subaddress parameter.

	(R) 7-46	The originating BSS shall include the Called Party Subaddress parameter 			in the outgoing IAM if its inclusion is allowed and the Called Party				Subaddress IE is received in the SETUP message from the calling user. The 			coding of the standard subfield shall be identical with the corresponding 			subfield coding in the received IE. The contents of the parameter starting 			from octet 2 shall be identical to the contents of the IE starting from octet 5. 

	(R) 7-47	The originating BSS shall include the Broadband High Layer Information 			parameter in the outgoing IAM if its inclusion is allowed and the 				Broadband High Layer IE is received in the SETUP message from the 			calling user. The coding of the standard subfield shall be identical with the 			corresponding subfield coding in the received IE. The contents of the 			parameter starting from octet 2 shall be identical to the contents of the IE 			starting from octet 5. 

	(R) 7-48	The originating BSS shall include the Broadband Low Layer Information 			parameter in the outgoing IAM if its inclusion is allowed and one or more 			Broadband Low Layer IEs are received in the SETUP message from the 			calling user. Based on the user subscription only the first or all the 				Broadband Low Layer information IEs are accepted by the BSS for 			transfer. The repeat indicator shall be coded 0 if only one IE is included and 			1 if more than one IEs are included in the Broadband Low Layer 				Information parameter. The priority subfield shall be coded according to the 			priority (ascending, descending or no prioritized order) of the IEs included 			in the parameter. The parameter field starting at octet 2 contains all 				Broadband Low Layer Information IEs as received in the SETUP message. 			The order of the IEs is not changed. 

	(R) 7-49	The originating BSS shall include the AAL parameter in the outgoing 			IAM if its inclusion is allowed and the AAL parameter IE is received in the 			SETUP message from the calling user. The coding of the standard subfield 			shall be identical with the corresponding subfield coding in the received IE. 			The contents of the parameter starting from octet 2 shall be identical with the 			contents of the IE starting from octet 5. 

	(R) 7-50	As a carrier option (See Section 7.3.2.2), the originating BSS shall include 			the Transit Network Selection (TNS) parameter in the IAM if it needs to 			indicate to a succeeding BSS the carrier selected for subsequent routing of 			the call. 

	(R) 7-51	As a carrier option (See Section 7.3.2.2), when included, the TNS shall 			include either 3-digit carrier identification code (XXX) or 4-digit carrier 			identification code (XXXX) identifying a succeeding carrier. 

	(R) 7-52	As a carrier option (See Section 7.3.2.2), the Charge Number and 				Originating Line Information (OLI) parameters, as a pair shall be 				configurable to be included, or not, in the IAM based on the connecting 			carrier and the subscribed service. 

The Charge Number and OLI parameters are used to transfer information about the number to be charged for the call and about the calling party. 
	(R) 7-53	As a carrier option (See Section 7.3.2.2), when included in the IAM, the 			Originating Line Information parameter shall be coded according to the 			service characteristics of the originating line. These codes are the binary 			equivalents of the decimal codes used in the II digits of inband BSS access 			signaling.

The coding of the OLIP is presented in ANSI-T1.113.

If included in the IAM, the Charge Number parameter provides an Automatic Number Identification (ANI) to the succeeding carrier.

	(R) 7-54	As a carrier option (See Section 7.3.2.2), when the Charge Number 			parameter is included in the IAM, it shall contain the NPA+NXX+XXXX 			address digits of this ANI in the address information field of the parameter. 			The odd/even indicator bit shall be coded “even number of address digits,” 			and the nature of address shall be coded “ANI of the calling party; national 			number.” If the ten address digits are not available, but the NPA digits are 			available, then only the three NPA digits shall be sent in the address 			information field. The odd/even indicator bit shall be coded “odd number of 			address digits,” and the nature of address field should be coded “ANI of the 			calling party; national number.”  The numbering plan field shall be coded 			“ISDN numbering plan (Recommendation E.164)” when either three or ten 			digits are sent.

If no ANI address digits are available, the odd/even bit shall be coded “even number of address digits” and the nature of address field shall be coded “ANI not available or not provided.” In this case, the octet containing the nature of address code shall be the last octet of the charge number parameter.

	(R) 7-55	As a carrier option (See Section 7.3.2.2), if the CgPN parameter is included 			in the IAM, the Charge Number parameter shall be omitted from the IAM if 			the following conditions are met:

			•	The Originating Line Information parameter and the charge number 				address digits are to be provided to the selected carrier.

			•	The CgPN parameter is included in the IAM.

			•	The charge number address digits agree with CgPN address digits.

			The presence of the Originating Line Information parameter together with 			the absence of the Charge Number parameter will inform a succeeding 			carrier that the charge number address agrees with the calling party address. 

The Carrier Identification Parameter (CIP) code is included in the IAM on a per carrier identification code (XXX or XXXX) basis provided the originating carrier and the connecting carrier have made a prior agreement to transfer it across the B-ICI if the call is to be routed to that carrier. The call may be routed from the originating BSS to the connecting carrier on a direct connection or on a connection to an intermediate BSS for a subsequent routing to that carrier.  Note that multiple carrier identification codes may be assigned to a carrier. Such a carrier may choose to receive the CIP only for a selected subset of the carrier identification codes assigned to it.

	(R) 7-56	As a carrier option (See Section 7.3.2.2), the originating BSS shall have the 			capability to be set to include or not include in the IAM the CIP on a per 			carrier identification code (XXX or XXXX) basis. 

	(R) 7-57	As a carrier option (See Section 7.3.2.2), the originating BSS shall include 			the CIP in the outgoing IAM if its inclusion is allowed. When included, the 			CIP shall be coded as follows:

			Octet 1:

			Bits 765 - Type of network identification 
			010 national network identification

			Bits 4321 - Network identification plan
			0001 3-digit carrier identification code
			0010 4-digit carrier identification code

			The carrier identification code digits XXX (XXXX) shall be coded in octets 			2 and 3 in BCD form starting with the first digit (most significant) in bits 			4321 of octet 1, digit 2 in bits 8765 of octet 2, digit 3 in bits 4321 of octet 			3, etc.  For 3-digit carrier identification code, bits 8765 of octet 3 shall be 			coded 0s.

The Carrier Selection Information parameter allows a carrier to determine whether a call is routed to that carrier (1) because of pre-subscription, or (2) because the end user provided a carrier identification code in the Transit Network Selection IE. 

	(R) 7-58	As a carrier option (See Section 7.3.2.2), an originating BSS shall be able 			to include or not include the Carrier Selection Information parameter in the 			IAM based on the connecting carrier to which the call is routed. 

	(R) 7-59	As a carrier option (See Section 7.3.2.2), when included, the Carrier 			Selection Information parameter shall be coded as follows:

			The “selected carrier identification code pre-subscribed and not input by 			calling party” code shall be used to inform the selected carrier that the 3/4-			digit (XXX/XXXX) carrier identification code used for delivering the call to 			that carrier is the pre-subscribed code associated with the originating access 			for the call, and that XXX/XXXX was not input to the BSS during call 			setup by the calling party. (A Transit Network Selection IE was not 			included in the SETUP message).

			The “selected carrier identification code pre-subscribed and input by calling 			party” code shall be used to inform the selected carrier that the 3/4-digit 			(XXX/XXXX) carrier identification code used for delivering the call to that 			carrier is the pre-subscribed code associated with the originating access for 			the call, and that XXX/XXXX was input to the BSS during call setup. (A 			Transit Network Selection IE with XXX/XXXX was included in the 			SETUP message).

			The “selected carrier identification code not pre-subscribed and input by 			calling party” code shall be used to inform the selected carrier that the 3/4-			digit (XXX/XXXX) carrier identification code used for delivering the call to 			that carrier is not the pre-subscribed code associated with the originating 			access for the call, and that XXX/XXXX was input to the BSS during 			call setup. (A Transit Network Selection IE with XXX/XXXX was 			included in the SETUP message).

The Originating ISC Point Code parameter is used for statistical purposes, e.g., accumulation of the number of incoming call/connections on an originating inter-carrier switching center basis.

	(R) 7-60	If the originating BSS has been assigned an Originating ISC Point Code, 			it shall have the capability to be set to include or not include in the IAM the 			Originating ISC Point Code parameter.

	(R) 7-61	On sending the IAM, timer T40b shall be started. Timer T40b shall be 			stopped on receipt of an IAA or an IAR. If neither an IAA nor an IAR has 			been received when timer T40b expires, then the reset procedure described 			in Section 7.8.1 shall be followed, the management system shall be alerted, 			and the VPCI/VCI and bandwidth shall be released. 

The received IAA will have the OSID containing the SID value, say Bi, selected by the succeeding BSS. The originating BSS will use the SID assigned by it and Bi to establish the bearer control association as described in Section 7.8.3. As explained in that section, all subsequent messages from the originating to the succeeding BSS will contain Bi in the DSID. 

Refer to Section 7.8.2.3 for procedures applicable to abnormal conditions related to assignment of VPCI/VCI and bandwidth. Refer to Section 7.8.6 for unsuccessful call and connection set up procedures. 

	(O) 7-2	On receipt of IAR, the call should be re-attempted. The call can be re-			attempted on a different route. 

	(R) 7-62	On sending the IAM, the originating BSS shall start timer T7b.  T7b shall 			be stopped on receipt of an ACM, ANM or receipt of an indication of 			release from the calling party. If an ACM, ANM , or calling party release is 			received before timer T7b expires, the originating BSS shall stop timer 			T7b and process the received message or indication. If timer T7b expires 			before receipt of the ACM, ANM, or calling party release, then the call shall 			be released using the procedures described in Section 7.7.7. The cause 			indicators parameter shall be coded as:
		General location: public network serving the local user
		Cause value: 102 "recovery on timer expiry"

(e)	IAM - Sent by the Non-Assigning BSS

	(R) 7-63	The originating BSS that acts as a non-assigning BSS for this call shall 			follow the procedures described in (d) above for the assigning BSS with 			the exception that the CEI shall not be included in the IAM. 

(f)	Completion of Transmission Path

	(R) 7-64	Through connection in both directions shall be completed on receipt of an 			ANM. 

The current version of this document does not support narrowband bearer capabilities including voice over ATM. To support such capabilities, the BSS will have to support different cut-through requirements. 

In this case, the IAM is received from the originating BSS.

7.8.5.1.2.1	Incoming Side of the BSS

(a)	Assigning BSS

	(R) 7-65	After receiving the IAM, the intermediate BSS that acts as an assigning 			BSS for this call shall perform the assignment procedure for VPCI/VCI 			and bandwidth as described in Section 7.8.2.2 (b). If this is successful, the 			IAA shall be sent immediately without waiting for further call processing. 

The received IAM will have the OSID containing the SID value, say Ai, selected by the originating BSS. The intermediate BSS will use the SID assigned by it and Ai to establish the bearer control association as described in Section 7.8.3. As explained in that section, all subsequent messages from the intermediate to the originating BSS will contain Ai in the DSID. 

	(R) 7-66	The IAA shall include the DSID containing the SID assigned by the 			originating BSS and OSID containing the SID assigned by the 				intermediate BSS. 

	(R) 7-67	The IAA shall include the CEI (containing the selected VPCI/VCI values) .

Refer to Section 7.8.2.3 for procedures applicable to abnormal conditions related to assignment of VPCI/VCI and bandwidth. Refer to Section 7.8.6 for unsuccessful call and connection set up procedures. 

(b)	Non-Assigning BSS

	(R) 7-68	After receiving the IAM, the intermediate BSS that acts as a non-assigning 			BSS shall perform the assignment procedure for VPCI/VCI and 				bandwidth as described in Section 7.8.2.2 (a). If this is successful, the IAA 			shall be sent immediately without waiting for further call processing. 

	(R) 7-69	Further procedures shall be as for the assigning BSS described in (a) 			above except that CEI shall not be included in the IAA. 

7.8.5.1.2.2	Outgoing Side of the BSS

(a)	Virtual Channel Selection 

	(R) 7-70	After sending the IAA, an intermediate BSS shall analyze the called party 			number and the other routing information (see Section 7.8.5.1.1) to 			determine the routing of the call. If the intermediate BSS can route the call 			using the ATM Cell Rate, QOS, and BBC parameters specified to the 			selected carrier, it shall send an IAM to that carrier. The BSS shall follow 			the assignment procedure for VPCI/VCI and bandwidth as described in 			Section 7.8.2.2.

(b)	Parameters in the IAM Sent by the Assigning BSS

	(R) 7-71	The intermediate BSS that acts as an assigning BSS for this call shall 			include the CEI (containing the selected VPCI/VCI values) in the IAM for 			the outgoing connection as described in Section 7.8.2.2 (a).

	(R) 7-72	The intermediate BSS shall include in the IAM the OSID (containing the 			selected SID) as described in Section 7.8.3. 

	(R) 7-73	The intermediate BSS shall include in the IAM the ATM Cell Rate, 				Broadband Bearer Capability, Called Party Number, AESA for Called Party 			Number if received, and Calling Party's category parameters. This signaling 			information will be identical with that in the IAM received from the 				preceding BSS.
 
	(R) 7-74	As a carrier option (See Section 7.3.2.2), if the call is to be routed to a 			connecting carrier and the TNS would be needed by this carrier for further 			routing of the call, the TNS included in the IAM received from the 				preceding BSS is passed on transparently in the IAM for the outgoing 			connection. Otherwise, the TNS in the IAM received from the preceding 			BSS shall be discarded. 

	(R) 7-75	If the call is to be routed to another carrier, the IAM shall include the 			received Called Party Subaddress, Calling Party Subaddress, AESA for 			Called Party Number if received, AAL parameter, Broadband High Layer 			Information, Broadband Low Layer Information, CgPN, CIP, Charge 			Number, OLI, and Carrier Selection Information parameters based on prior 			agreements between the connecting carriers. The BSS shall transfer these 			parameters transparently (i.e., without any processing) from the incoming 			IAM to the outgoing IAM. See Section 7.8.8 - "Propagation Delay 				Determination" for an exception. 

	(R) 7-76	If the intermediate BSS has been assigned an Originating ISC Point Code, 			it shall have the capability to be set to include or not include in the IAM the 			Originating ISC Point Code parameter.

	(R) 7-77	The procedures to be followed after sending the IAM shall be as described 			in Section 7.8.5.1.1 (d) for the originating BSS except that the timer T7b 			related procedures shall not be applicable. 

(c)	Parameters in the IAM Sent by the Non-Assigning BSS

	(R) 7-78	The intermediate BSS that acts as a non-assigning BSS for this call shall 			follow the procedures described in (b) above for the assigning BSS with 			the exception that the CEI shall not be included in the IAM. 

(d)	Sending of Exit Message

An Exit Message (EXM) is needed for a call routed to another carrier. It is generated at an outgoing gateway BSS in a network and sent in the backward direction to notify preceding BSSs that call set up information has successfully progressed to the succeeding network. This message generally does not cross a network boundary. 

	(R) 7-79	As a carrier option (See Section 7.3.2.2), after sending the IAM to a 			connecting carrier, the intermediate BSS shall await the IAA, or IAR from 			that carrier. If an IAA is received for the outgoing connection, the 				intermediate BSS shall formulate and send an EXM to the originating 			BSS. The sending of an EXM shall precede any ACM or ANM for the 			call sent to the originating BSS.

	(R) 7-80	As a carrier option (See Section 7.3.2.2), if an IAR is received and an 			automatic re-attempt is made by the intermediate BSS, the procedure 			described in the preceding requirement shall be repeated when the IAM 			associated with the re-attempt is sent.

The Outgoing Facility Identifier parameter  carries the identification of the outgoing facility on which the call attempt to the connecting carrier was made by the intermediate BSS. This parameter consists of the VPCI used for the outgoing call attempt and the signaling point code of the BSS at the far-end of this VPCI.  

	(R) 7-81	After sending the IAM to a connecting carrier, the intermediate BSS shall 			send an REL towards the originating BSS in response to the received IAR 			(when no re-attempt is made) or T40b expiry. As a carrier option (See 			Section 7.3.2.2), the REL shall include the Outgoing Facility Identifier 			parameter if the intermediate BSS can identify the outgoing facility on 			which the call attempt to the connecting carrier was made.

	(R) 7-82	As a carrier option (See Section 7.3.2.2), the EXM shall include the DSID 			containing the SID assigned by the originating BSS.  

	(R) 7-83	As a carrier option (See Section 7.3.2.2), the EXM shall include the 			Outgoing Facility Identifier parameter. 

(e)	Completion of Transmission Path

	(R) 7-84	Through connection in both directions shall be completed on receipt of an 			ANM. The B-ICI Version 2.0 does not support narrowband bearer 				capabilities including voice over ATM. To support voice over ATM, the 			BSS will have to support different cut-through requirements which are for 			further study.

A transit carrier would be any carrier between the originating and terminating carriers. A call may be handled by one or more transit carriers. In some cases, a call may be routed directly from the originating carrier to the terminating carrier without passing through a transit carrier. 

	(R) 7-85	An intermediate BSS in a transit carrier shall meet the same requirements 			described above for the intermediate BSS in the originating carrier. 

	(R) 7-86	If the intermediate BSS has been assigned an Originating ISC Point Code, 			it shall have the capability to be set to delete the Originating ISC Point Code 			parameter from the outgoing IAM.

This section gives requirements for an intermediate BSS that receives a call from another carrier and routes it to a terminating BSS serving the called party. As an example, a call can originate in a LEC, pass through a transit carrier (e.g., an IEC) and is routed to a (possibly another) LEC serving the called party. 

7.8.5.1.4.1	Incoming Side of the BSS

(a)	Assigning BSS

	(R) 7-87	Same requirements as in Section 7.8.5.1.2.1 (a) shall be applicable except 			that the preceding BSS in this case is the BSS belonging to the carrier 			routing the call to the terminating carrier.

(b)	Non-Assigning BSS

	(R) 7-88	The requirements in Section 7.8.5.1.2.1 (b) shall apply.

7.8.5.1.4.2	Outgoing Side of the BSS

(a)	Virtual Channel Selection 

	(R) 7-89	If the intermediate BSS receives the TNS from the preceding carrier, it 			shall release the call as described in Section 7.8.7. The cause indicators 			parameter shall be coded as:

			General location: public network serving the remote user
			Cause value: 111 "protocol error - unspecified"

	(R) 7-90	After sending the IAA to the preceding carrier, an intermediate BSS shall 			analyze the Called Party Number. If the intermediate BSS can route the call 			using the ATM Cell Rate, QOS, and BBC parameters specified to the 			destination, it shall send an IAM to the destination BSS. The BSS shall 			follow the assignment procedure for VPCI/VCI and bandwidth as described 			in Section 7.8.2.2.

(b)	Parameters in the IAM Sent by the Assigning BSS

	(R) 7-91	The intermediate BSS that acts as an assigning BSS for this call shall 			include the CEI (containing the selected VPCI/VCI values) in the IAM for 			the outgoing connection as described in Section 7.8.2.2 (a).

	(R) 7-92	The intermediate BSS shall include in the IAM the OSID (containing the 			selected SID) as described in Section 7.8.3. 

	(R) 7-93	The intermediate BSS shall include in the outgoing IAM the ATM Cell 			Rate, BBC, Called Party Number, AESA for Called Party Number if 			received, and Calling Party's Category parameters as in the received IAM.
 
	(R) 7-94	The business arrangement between the terminating and the preceding 			networks shall determine whether the CgPN and AESA for CgPN 				parameters (if received), the information whose transfer is governed by user 			subscription parameters (if received), described in Section 7.8.5.1.1 (d) or 			other parameters are accepted and included (as received) in the outgoing 			IAM. (See Section 7.8.8 - "Propagation Delay Determination" for an 			exception). The BSS shall have the capability to be set to include or not 			include any of the above parameters in the outgoing IAM. 

	(R) 7-95	The preceding requirement shall take precedence over the compatibility 			instructions included in such parameters and the instructions 				notwithstanding, the intermediate BSS may discard these parameters or 			any unrecognized parameter or a parameter with unrecognized value. In 			other words, the screening (policing) functions specified in the preceding 			requirement shall take precedence over compatibility instructions. 

	(R) 7-96	If the intermediate BSS has been assigned an Originating ISC Point Code, 			it shall have the capability to be set to delete the Originating ISC Point Code 			parameter from the outgoing IAM.

	(R) 7-97	The procedures to be followed after sending the IAM shall be as described 			in Section 7.8.5.1.1 (d) for the originating BSS except that the timer T7b 			related procedures shall not be applicable. 

(c)	Parameters in the IAM Sent by the Non-Assigning BSS

	(R) 7-98	The intermediate BSS that acts as a non-assigning BSS for this call shall 			follow the procedures described in (b) above for the assigning BSS with 			the exception that the CEI shall not be included in the IAM. 

(d)	Completion of Transmission Path

	(R) 7-99	The requirements in Section 7.8.5.1.2.2 (e) shall apply.

The terminating BSS may receive a call from another carrier either on a direct connection or via an intermediate BSS. The requirements in this section are applicable for both of these cases. 

(a) 	Incoming Side - Assigning BSS

	(R) 7-100	After receiving the IAM, the destination BSS that acts as an assigning 			BSS for this call shall perform the assignment procedure for VPCI/VCI 			and bandwidth as described in Section 7.8.2.2 (b). If this is successful, the 			IAA shall be sent immediately without waiting for further call processing.

The received IAM will have the OSID containing the SID value, say Ai, selected by the preceding BSS. The destination BSS will use the SID assigned by it and Ai to establish the bearer control association as described in Section 7.8.3. As explained in that section, all subsequent messages from the destination to the preceding BSS will contain Ai in the DSID. 

	(R) 7-101	The IAA shall include the DSID containing SID assigned by the preceding 			BSS and OSID containing the SID assigned by the destination BSS. 

	(R) 7-102	The IAA shall include the CEI (containing the selected VPCI/VCI values). 

Refer to Section 7.8.2.3 for procedures applicable to abnormal conditions related to assignment of VPCI/VCI and bandwidth. Refer to Section 7.8.6 for unsuccessful call and connection set up procedures. 

(b)	Incoming Side - Non-Assigning BSS

	(R) 7-103	After receiving the IAM, the destination BSS that acts as a non-assigning 			BSS shall perform the assignment procedure for VPCI/VCI and 				bandwidth as described in Section 7.8.2.2 (a). If this is successful, the IAA 			shall be sent immediately without waiting for further call processing. 

	(R) 7-104	Further procedures shall be as for the assigning BSS described in (a) 			above except that CEI shall not be included in the IAA. 

(c)	Call Processing

	(R) 7-105	If the call is coming in on a direct connection from another carrier, the 			business arrangement between the terminating carrier and the preceding 			carrier (the carrier routing the call to the terminating carrier) shall determine 			whether the Calling Party Number and AESA for Calling Party Number 			parameters (if received), the information whose transfer is governed by user 			subscription parameters (if received), described in Section 7.8.5.1.1 (d) or 			other parameters are accepted. The BSS shall have the capability to be set 			to accept and process or not accept any of the above parameters. 

	(R) 7-106	The preceding requirement shall take precedence over the compatibility 			instructions included in such parameters and the instructions 				notwithstanding, the destination BSS may discard these parameters or any 			unrecognized parameter or a parameter with unrecognized value. In other 			words, the screening (policing) functions specified in the preceding 			requirement shall take precedence over compatibility instructions. In 			particular, if the BSS receives the TNS from the preceding carrier, it shall 			release the call as described in Section 7.8.5.1.4.2 (a). 

	(R) 7-107	If the destination BSS has been assigned an Originating ISC Point Code, 			it shall have the capability to be set to delete the Originating ISC Point Code 			parameter from the SETUP to the called party.

	(R) 7-108	After sending the IAA, the destination BSS shall analyze the called party 			number to determine to which party the call should be connected. It shall 			also check the called party's access condition and perform various checks to 			determine whether or not the called party is allowed to receive the call. 

If the connection is allowed, the destination BSS will proceed to offer the call to the called party by sending a DSS2 SETUP message. 

	(R) 7-109	On sending the SETUP message, the BSS sets timer T303. If a DSS2 			ALERTING, a CONNECT or a RELEASE COMPLETE message is 			received before this timer expires, an ACM, an ANM or an REL, 				respectively, shall be sent to the preceding BSS. If timer T303 expires, the 			SETUP message is sent again, T303 is restarted and an ACM is sent. If a 			CALL PROCEEDING message is received before expiry of T303, timer 			T310 is set awaiting ALERTING, CONNECT or a RELEASE message. 

	(R) 7-110	If the IAM contains information from the originating access (in the SETUP 			message) carried in the parameters mentioned in Section 7.8.5.1.1 (d), it 			shall be transferred unaltered in the SETUP message sent to the called user.

	(R) 7-111	If the destination BSS receives the AESA for Called Party in the IAM, it 			shall map the AESA into the Called Party Number IE to be included in the 			SETUP message. 

Both the CgPN parameter and the AESA for Calling Party parameter may be present in the IAM. The selection between the two parameters for mapping into the CgPN IE in the SETUP message shall depend on the services operating at the destination local BSS. 

	(R) 7-112	An ACM shall be sent from the destination  BSS as soon as it has been 		determined that the complete called party number has been received and to 		convey indications of the called party's status. 

	(R) 7-113	The called party's status indicator in the called party's indicators parameter 		included in the ACM shall be coded as follows.
			(a) "No indication" if the ACM is sent because of T303 expiry. 
			In this case, the indication that the destination user is being alerted is 		transferred in a Call Progress Message (see Section 7.8.5.3).
			(b) "Alerting" if an ALERTING message is received. 
	(R) 7-114	The called party's category indicator in the called party's indicators 			parameter shall be set as "ordinary subscriber".

	(R) 7-115	The ACM shall include the DSID containing the SID assigned by the 		preceding BSS.

	(R) 7-116	On receipt of the ACM, an intermediate BSS shall send the corresponding 		ACM towards the preceding BSS.

	(R) 7-117	On receipt of the ACM at the originating BSS, timer T7b shall be stopped.

	(R) 7-118	The destination BSS shall through connect after receiving the CONNECT 		message from the called party and before sending the ANM.

For a basic call, the Call Progress Message (CPG) is sent only after the ACM. The CPG is sent from a BSS in the backward direction indicating that an event has occurred during call set-up which should be relayed to the calling party. 

	(R) 7-119	The CPG shall be sent from the destination BSS if the ACM has been sent 		and subsequently:
			- an ALERTING message is received from the called party. The CPG shall 		contain the called party's Indicators parameter with the called party's status 		set to "alerting". The called party's category indicator in the called party's 		indicators parameter shall be set as "ordinary subscriber". 

	(R) 7-120	The CPG shall include the DSID containing the SID assigned by the 		preceding switch. 

	(R) 7-121	On receipt of the CPG, an intermediate BSS shall send the corresponding 		CPG to the preceding BSS. 

	(R) 7-122	On receipt of the CPG at the originating BSS, no call state change shall 		occur.

	(R) 7-123	When the DSS2 CONNECT message is received from the called party, the 		destination  BSS shall send an ANM to the preceding BSS. 
	(R) 7-124	The ANM shall include the DSID containing the SID assigned by the 		preceding BSS.  
The ANM can transport AAL-parameters parameter and broadband low layer information parameter transparently from the terminating access to the originating BSS. 
	(R) 7-125	The destination BSS shall include the AAL-parameters parameter and 		Broadband Low Layer Information parameter in the ANM if their inclusion 		is allowed and the AAL-parameters IE and Broadband Low Layer 			Information IE are received in the CONNECT message from the called user. 		The coding of these parameters shall be as described in Section 7.8.5.1.1 		(d). The AAL- parameters IE and only one Broadband Low Layer 			Information IE will be transferred.
Through connection: see Section 7.8.5.2.4.

	(R) 7-126	Upon receipt of the ANM, the intermediate BSS shall through connect the 		virtual connection in both directions and send the corresponding ANM 		towards the preceding BSS. 

	(R) 7-127	When the originating BSS receives the ANM indicating that the required call 	and connection have been completed, the following occurs:
			- the timer T7b shall be stopped if it is still running, 
			- the virtual connection to the calling party shall be connected in both
	 		  directions, and
			- a DSS2 CONNECT message shall be sent to the calling party. 
If the ANM contains information from the terminating access carried in the parameters mentioned in Section 7.8.5.4.1, it shall be transferred in the CONNECT message to the calling user.

	(R) 7-128	During the call and connection set-up itself, each relevant BSS shall store 	information contained in the IAM sent by the originating BSS or 	received at the intermediate or destination BSS. The information that must 	be stored shall include all parameters within the IAM.
	(R) 7-129	The IAM information shall not be released from memory:
		(a) in the originating or intermediate BSS, before the ACM or ANM has 		been received.
		(b) in the destination BSS, before the ACM or ANM has been sent.
		The IAM information can be released from memory in all BSSs  when 		the call is released prematurely and no automatic repeat attempt is to be 		made. 

	(R) 7-130	If at any time a call or connection leg cannot be completed due to a lack of 			resources at the incoming side (e.g., SIDs, VPCI/VCI or bandwidth), the 			BSS receiving the IAM shall immediately start the release of the call and 			connection and send an IAR towards the preceding BSS. The IAR shall 			contain the DSID and cause indicators parameter. Cause value 47 (resource 			unavailable - unspecified) shall be included if no SIDs were available; cause 			value 45 (no VPCI/VCI available) shall be included in the case of a lack of 			VPCI/VCI; and cause value 37 (ATM Cell Rate not available) shall be 			included in the case of a lack of bandwidth. The incoming signaling 			association shall be deleted.

	(R) 7-131	If at any time a call or connection leg cannot be completed due to a lack of 			resources at the outgoing side (e.g., SIDs, VPCI/VCI or bandwidth), the 			BSS shall immediately start the release of the call and connection and shall 			send an REL towards the preceding BSS. The REL shall contain the 			DSID and cause indicators parameter. Cause value 47 (resource unavailable 			- unspecified) shall be included if no SIDs were available, cause value 45 			(no VPCI/VCI available) shall be included in the case of a lack of 				VPCI/VCI; and cause value 37 (ATM Cell Rate not available) shall be 			included in the case of a lack of bandwidth.  Further procedures shall be as 			in Section 7.8.7.1.

	(R) 7-132	On receipt of an IAR, a BSS shall release the VPCI/VCI and the 				bandwidth (if applicable), and shall terminate the outgoing signaling 			association, i.e., it shall release the SID assigned to the outgoing 				connection. The BSS may re-attempt the call on an alternate route.

	(R) 7-133	If all attempts to route the call have failed, the BSS shall:
			(a)	Immediately start the release of the call and connection.
			(b)	If this is an intermediate BSS, it shall send an REL with the received 				cause value towards the preceding BSS.  Further procedures shall 				be as in Section 7.8.7.1.
			(c)	If this is an originating BSS, it  shall send a  DSS2 RELEASE 				message with the received cause value to the calling user.

	(R) 7-134	On receipt of an REL from the succeeding BSS after receipt of the IAA, 			but before receipt of the ACM or ANM, the BSS shall release the 				VPCI/VCI and the bandwidth, and shall send an RLC. The outgoing 			signaling association shall be terminated, i.e., it shall release the SID 			assigned to the outgoing connection.

			(a)	If this is the controlling BSS (i.e. the BSS controlling the call), 				it may attempt to re-route the call.

			(b)	If this is not the controlling BSS or if all attempts to re-route the 				call have failed:
				(i)	If this is an intermediate BSS, it shall send an REL with the 					received cause value towards the preceding BSS. Further 					procedures shall be as in Section 7.8.7.1.
				(ii)	If this is an originating BSS, it shall send a  DSS2 						RELEASE message with the received cause value to the 					calling user.

	(R) 7-135	If a BSS determines that the proper number of digits for routing the 			connection has not been received, an REL shall be sent towards the 			preceding BSS with cause "address incomplete".

The release procedure is a confirmed operation. The REL initiates release of the call and virtual channel connection, and the RLC signifies completion of the release. The same procedures are used in the network irrespective of whether they are initiated by the calling party, the called party or the network.

	(R) 7-136	The REL shall include the DSID and cause indicators parameter coded with 			the appropriate cause value and location. These are specified in ITU-T 			Recs. Q.850 and Q.2610.  On sending an REL, a BSS shall start timer 			T1b and await receipt of an RLC.  If an RLC is received before timer T1b 			expires, the timer shall be stopped and the requirements listed in this section 			shall be followed. If timer T1b expires before receipt of an RLC, the BSS 			shall alert the management system and reset the VPCI/VCI using the 			procedures given in Section 7.9.1.

	(R) 7-137	Any BSS receiving an REL shall perform the following actions in the 			order shown:
			- the associated VPCI/VCI shall be made available for new traffic,
			- the bandwidth shall be made available for new traffic (applicable for an 			   assigning BSS),
			- an RLC shall be returned,
			- the signaling association (SIDs) shall be terminated.

	(R) 7-138	A BSS that has initiated the release procedure by sending an REL shall 			perform the following actions on receipt of the RLC:
			- stop timer T1b 
			- the associated VPCI/VCI shall be made available for new traffic,
			- the bandwidth shall be made available for new traffic (applicable for an 			   assigning BSS),
			- the signaling association (SIDs) shall be terminated.

The following sections describe additional required actions.

(a) 	Actions Required at the Originating BSS

	(R) 7-139	On receipt of a request to release the call from the calling party, the 				originating BSS shall immediately start the release of the ATM 				connection. An REL shall be sent towards the succeeding BSS with the 			cause indicators parameter. The cause indicators parameter shall be coded 			as:
			general location: user
			cause value: 16 "normal clearing".

In case of a premature release by the calling party, a release indication is received from the calling party before the call is established. 

	(R) 7-140	In case of a premature release by the calling party, the BSS shall 				immediately release the resources towards the calling party, but shall delay 			the release of the connection towards the succeeding BSS until receipt of 			the IAA.

(b) 	Actions at an Intermediate BSS

	(R) 7-141	On receipt of the REL, an intermediate BSS shall send an REL towards 			the succeeding BSS with the received cause indicators parameter. The 			release of the connection towards the succeeding BSS shall not occur until 			after the receipt of the IAA. 

(c) 	Actions Required at the Destination BSS

	(R) 7-142	On receipt of the REL from the preceding BSS, the destination BSS 			shall immediately release the resources towards the called party by sending 			the DSS2 RELEASE message including a cause IE. The cause IE shall be 			mapped from the received cause indicators parameter.

(d)	Collision of Release Messages

	(R) 7-143	If two points in a connection initiate release of a call, an REL may be 			received at a BSS from a succeeding or preceding BSS after the release 			of the call is initiated.  In this case, the BSS shall return an RLC towards 			the BSS from which it received the REL.  The RLC shall be sent when the 			call and connection have been cleared.

	(R) 7-144	The procedures in Section 7.8.7.2 shall apply, except that the functions at 			the originating  and destination  BSSs are transposed.

	(R) 7-145	The procedures in Section 7.8.7.2 shall apply, except that they can be 			initiated at any BSS. To initiate release of incoming and outgoing 				connections, RELs shall be sent to the preceding and succeeding BSSs 			with the cause indicators parameter coded with the appropriate cause value.  			When the originating and destination BSSs receive the RELs, they shall 			send DSS2 RELEASE messages to the calling and called users, 				respectively. The cause IEs in the RELEASE messages shall be mapped 			from the cause indicators parameter in the corresponding REL. 

The suspend and resume (network initiated) procedures are only applicable in the case of interworking with N-ISDN User Part.  An interworking BSS is defined as the switch performing interworking between B-ISDN User Part and N-ISDN User Part (N-ISDN interworking switch).  The suspend and resume procedures will be invoked only by a destination BSS when the called party has a non-ISDN access. Suspend and resume messages will be received by an ATM switch only through an interworking BSS, i.e., these messages will be generated by N-ISUP and simply passed through by BISUP.

The current version of this document does not address BISUP requirements to support interworking with N-ISDN. Therefore, requirements for suspend and resume (network initiated) procedures are not provided in the current version of this document.  

The propagation delay determination procedure using BISUP is defined in ITU-T Rec. Q.2764.  This procedure provides a means to determine the total propagation delay for a connection. 

A propagation delay value would be measured and pre-stored for each virtual path going out of every BSS for which the BSS is the assigning BSS. 

The propagation delay information is accumulated during call set up in the forward direction by increasing the propagation delay counter parameter contained in the IAM. The cumulative delay value is sent in the backward direction as call history information parameter in the ANM before the active phase of a call. 

The ATM Forum UNI Specification Version 3.1 does not provide access protocol requirements for supporting end-to-end propagation delay determination. Therefore, the current version of this document does not address BISUP requirements to support end-to-end propagation delay determination. 

This subsection contains the description of the maintenance control functions relating to:
•	The reset of resources
•	The blocking of virtual paths
•	Remote User Part availability procedure
•	Transmission alarm handling
•	Automatic congestion control
•	Signaling congestion control procedure
•	Destination unavailability control
•	VPCI/VPI consistency check procedure
The BISUP messages associated with maintenance control functions are: Blocking (BLO), Blocking Acknowledgment (BLA), Unblocking (UBL), Unblocking Acknowledgment (UBA), Reset (RSM), Reset Acknowledgment (RAM), User Part Test (UPT), User Part Available (UPA), Consistency Check Request (CCR), Consistency Check Request Acknowledgment (CCRA), Consistency Check End (CCE), and Consistency Check End Acknowledgment (CCEA).

The reset procedure is used to return signaling identifiers and connection elements (virtual channel links/path connections) to the idle condition.  The procedure is invoked under abnormal conditions when the current status of the Signaling Identifiers (SIDs) or the Connection Element Identifiers (CEIs) is unknown or ambiguous.  For example, a switching system that has suffered memory mutilation will not know the status of SIDs and virtual channel connections, e.g., idle, busy incoming, busy outgoing, etc.  The identifiers and virtual channel links/path connections (and any associated bandwidth) between the two adjacent nodes should therefore be reset to the idle condition and the resources made available for new traffic.
In order to indicate what resources are to be reset, the Reset message contains a Resource Identifier parameter. This parameter consists of two subfields: "Resource Indicator" and "Resource Value". The resource indicator identifies the resource type to be reset (e.g., VPCI) and the resource value identifies the specific instance of the resource to be reset. If the resource indicator in this parameter is set to "remote SID" the resource value will indicate the local SID reference at the sending node ( the remote reference at the receiving node). If the resource indicator is set to "local SID" then the resource value will indicate the remote SID reference at the sending node (the local reference at the receiving node).  If the resource indicator is set to "VPCI," or "VPCI/VCI" the resource value will indicate the virtual channel/path link common to both the sending and receiving nodes.

(R) 7-146	The reset procedure shall be initiated for the following signaling anomalies 		detected by the B-ISDN signaling system.  These anomalies are detected by 		the protocol procedures, reported to the BSS management functions, and 		thus initiate the reset procedure:

			An unexpected message is one which contains a message type code that is 			within the set supported by the BSS but is not expected to be received in 			the current state of the call. 

				An unexpected message for the following requirement is any message other 			than an IAA or IAR.

			•	If an unexpected message is received while awaiting the IAM 			Acknowledge message, the BSS shall send a reset message to 			reset the remote SID.

				An unexpected message for the following requirement is any message other 			than an ACM, ANM, or REL.

			•	If an unexpected message is received while awaiting the Address 			Complete message, the BSS shall send a reset message to reset the 			local SID.
			•	On the expiry of Timer T1b, "Await Release Complete", the BSS 			shall send a reset message to reset the VPCI/VCI.

			•	If an unexpected message is received relating to an unallocated SID, 			the BSS shall send a reset message to reset the remote SID.

			•	On the expiry of Timer T40b, "Await IAM Acknowledgment", an 			assigning BSS shall send a reset message to reset the VPCI/VCI and 			remove the VPCI/VCI and bandwidth from service; a non-assigning 			BSS shall send a reset message to reset the remote SID.

			•	If the BSS detects a missing mandatory parameter, then the BSS 			shall send a reset message to reset the local SID.

			•	If a maintenance action is invoked due to memory mutilation, e.g., 			losing the association information between a signaling ID and a 			Connection Element identifier, the BSS shall send a reset message 			to reset each affected VPCI.

			•	If a maintenance action is invoked involving start-up and restart of a 			BSS and/or a signaling system, the BSS shall send a reset message 			to reset each affected VPCI.

	(R) 7-147	To initiate reset procedures, a RSM message shall be sent. The message 			shall contain the resource identifier parameter.

	(R) 7-148	On sending the RSM message, the BSS shall stop sending ATM cells on 			the connection, if applicable.
	(R) 7-149	On sending the RSM message, the BSS shall start timers T16b and T17b, 			and wait for the RAM message.  Timers T16b and T17b shall be stopped on 			receipt of the RAM message.  If timer T16b expires before receipt of RAM, 			the procedure in Section 7.9.1.3 shall be followed.

	(R) 7-150	On receiving the RAM, the affected BSS (the reset initiating BSS) will 			place the referenced resource it controls in the "idle" state, and return all 			associated bandwidth on the virtual path which the BSS controls to the 			"available" state (i.e., send indication to resource control mechanism). 

	(R) 7-151	If the resource reset was "VPCI," the BSS shall idle all associated 				signaling identifiers, i.e., delete all signaling associations related to that 			VPCI.
The Virtual Path blocking conditions are affected by reset of "VPCI" as follows:

	(R) 7-152	Any local blocking condition related to the reset VPCI shall be removed 			when the RAM is received.
	(R) 7-153	Any remote blocking condition related to the reset VPCI shall be removed 			when the RAM is received, unless a BLO message has been received since 			the sending of the RSM message relating to the concerned VPCI, in which 			case the remote blocking condition shall be reinstated.
	(R) 7-154	The blocking conditions shall be unaffected by other types of reset.
	(R) 7-155	The BSS shall notify the management system of the outcome of the VPCI 			reset procedure when blocking is active on that VPCI.

	(R) 7-156	On receiving a RSM message, the receiving (unaffected) BSS shall:
			(a)	If it is the incoming or outgoing BSS on a connection in any 			call/connection state, the BSS shall accept the message as a request 			to idle resources it controls. It shall respond by sending a RAM after 			the indicated resource, the bandwidth if it is the controlling BSS 			for the virtual path affected, and all associated identifiers (SIDs, 			VPCI/VCIs, where applicable) on the concerned link have been 			made available for new traffic.
				If a "CEI: VPCI" is reset, then all VCIs and SIDs associated with 			the virtual path link shall be released;
			(b)	If the received resource (SID, VPCI/VCI, VPCI) is not allocated 			(idle condition), the BSS shall accept it as a release request and 			therefore respond by sending a RAM message;
			(c)	Any interconnected virtual path/channel links and all associated 			resources shall be released by an appropriate method (e.g., Release) 			except in the case of call/connections that are currently awaiting the 			IAM Acknowledgment; in this case, an automatic repeat attempt is 			applicable.
			(d)	If the RSM message is received after having sent a RSM message, 			the BSS shall respond with a RAM.  The associated identifiers and 			the bandwidth, if applicable, shall be made available for service.
			(e)	If the Resource indicator is set to "CEI: VPCI" and if the affected 			virtual path is in the locally blocked state, the RSM message shall be 			accepted as a request to idle all resources (signaling identifiers, 			VPCI, VPCI/VCI). The affected virtual path shall be returned to the 			locally blocked state.  A BLO message with a Resource indicator set 			to "CEI: VPCI" indicating the affected virtual path shall be sent.  A 			RAM message shall be sent following the BLO message.
			(f)	If the Resource indicator is set to "CEI: VPCI" and if the affected 			virtual path is in a remotely blocked state, the remotely blocked state 			shall be removed.

	(R) 7-157	If a RAM is received which is not a correct response to a sent RSM 			message, it shall be discarded.

	(R) 7-158	If a RSM message is received requesting reset of a resource (e.g., 				connection element identifier) that is not controlled by the B-ISDN User 			Part, it shall be discarded.

	(R) 7-159	If the RAM is not received before expiry of T16b, the RSM shall be sent 			again and T16b shall be restarted.  If T17b expires before receipt of the 			RAM, T16b shall be stopped, T17b shall be restarted, management system 			shall be notified and RSM shall be sent again.  Subsequently, RSM shall be 			sent at intervals of T17b until the RAM is received or maintenance 				intervention occurs.

Note: There is an agreement to include a count of resets performed by the BSS, but no text is proposed for the requirement at this time.

The virtual path blocking procedure is provided to prevent a virtual path from being selected for carrying new non-test call/connections. This procedure can be initiated automatically, e.g., under fault conditions, or manually, to permit testing or other BSS management functions, e.g., to perform the VPCI Consistency Check procedure.
Blocking can be initiated by the BSS at either end of a virtual path.  The virtual path is put into a blocked state at both ends and the bandwidth becomes unavailable.  A blocked virtual path cannot be selected for new non-test traffic by either BSS; however, test call/connections can be completed in either direction independent of the blocking state.  Test calls must not return a virtual path to service. 

	(R) 7-160	An Acknowledgment message shall be required for each blocking and 			unblocking request.  The Acknowledgment is not sent until the appropriate 			action, blocking or unblocking, has been taken.

	(R) 7- 161	Unblocking shall only be initiated by the same BSS which initiated the 			blocking by sending an UBL or RSM (VPCI) message (see Section 7.8.1.1 			also). At either end of a virtual path, the blocked state is removed and the 			bandwidth becomes available again.

	(R) 7-162	When the assigning or non-assigning BSS initiates the blocking procedure 			it shall send the BLO message with the Resource identifier set to "CEI: 			VPCI," indicating the affected VPCI.  The virtual path shall be put into the 			locally blocked state, and no new non-test call/connections can be completed 			over this virtual path, in either direction.

	(R) 7-163	On sending the BLO message, the BSS shall start timer T12b awaiting the 			BLA message. When the BLA message is received, timer T12b shall be 			stopped. If the BLA message is not received before timer T12b expires, 			then the management system shall be informed.

	(R) 7-164	When the BLA message is received, the management system shall be 			informed of the completion of the blocking.

	(R) 7-165	When the BSS initiates the unblocking procedure, it shall send the UBL 			message with the Resource identifier set to "VPCI," indicating the 				affected VPCI.

	(R) 7-166	On sending the UBL message, the BSS shall start timer T14b and wait for 			the UBA message.  When the UBL Acknowledgment message is received, 			timer T14b shall be stopped.  If the UBA message is not received before 			timer T14b expires, then the management system shall be informed.

	(R) 7-167	When the UBA message is received, the local blocking condition for the 			virtual path shall be removed. The management system shall be informed.

	(R) 7-168	When the BSS receives the BLO message indicating the affected VPCI, 			the virtual path shall be put into the remotely blocked state and the 				bandwidth shall become unavailable.  No new non-test calls/connections 			can be completed over this virtual path in either direction.  A BLA message 			shall then be sent.

	(R) 7-169	When the BSS receives the UBL message indicating the affected VPCI, 			the remotely blocked state for the virtual path shall be removed, the 				bandwidth shall become available again for traffic, and the UBA message 			shall be sent.

	(R) 7-170	(a)	If a BLO message is received for a virtual path connection which is 				already in a remotely blocked state, a BLA message shall be sent.
			(b)	If an UBL message is received for a virtual path connection which is 			not in a remotely blocked state, an UBA message shall be sent.
			(c)	If a BLO message is received for a virtual path connection which is 			not under the control of the B-ISDN User Part, it shall be discarded.

User part availability procedure is not supported.

	(R) 7-171	Since fully digital transmission systems are provided between two BSSs, 			which have some inherent fault indication feature giving an indication to the 			switching system when faults on transmission path level and/or virtual path 			level are detected, the switching system shall inhibit selection of the virtual 			paths concerned for the period the fault conditions persist.  No special 			actions are required for active call/connections.

Automatic congestion control is used when a BSS is in an overload condition. Two levels of congestion are distinguished, a less severe congestion threshold (congestion level 1) and a more severe congestion threshold (congestion level 2). These congestion levels are dependent on the implementation of the BSS.
	(R) 7-172	The call control and maintenance control functions shall be able to 				communicate to meet the following requirements.
	(R) 7-173	If either of the two congestion thresholds is reached, an Automatic 				Congestion Level parameter shall be included in all Release messages. This 			parameter indicates the level of congestion (congestion level 1 or 2) to the 			adjacent switches. 
	(R) 7-174	The adjacent switches, when receiving this Automatic Congestion Level 			parameter, shall reduce their traffic to the overloaded BSS.
	(R) 7-175	If the overloaded BSS returns to a normal traffic load, it shall no longer 			include the Automatic Congestion Level parameters in Release messages.
	(R) 7-176	The adjacent switches, after a predetermined time, shall then automatically 			return to their normal status.

		Parameter
	(R) 7-177	When a Release message is received containing an Automatic Congestion 			Level (ACL) parameter, the BISUP shall pass the appropriate information to 			the signaling system-independent network management/overload control 			function within the BSS. This information shall consist of the received 			congestion level information and the node identification to which the 			congestion level applies.
	(R) 7-178	Automatic congestion level actions are only applicable to switches adjacent 			to the congested switch. Therefore, a BSS that receives a Release message 			containing an Automatic Congestion Level parameter shall discard that 			parameter (i.e., not pass it in any REL message sent to a preceding or 			succeeding switch) after notifying the network management/overload 			control function.

	(R) 7-179	Whenever a BSS is in an overload state (congestion level 1 or 2), the 			signaling system-independent network management/overload control 			function shall direct the B-ISDN User Part to include an Automatic 				Congestion Level parameter in every Release message sent by the BSS.
	(R) 7-180	The network management/overload control function shall indicate which 			congestion level (1 or 2) to code in the Automatic Congestion Level 			parameter.
	(R) 7-181	When the overload condition has ended, the network management/overload 			control function shall direct the B-ISDN User Part to cease including the 			Automatic Congestion Level parameter in the Release messages.

On detection of signaling network congestion (local transmit buffer congestion), a BSS reduces signaling traffic load in a step-wise manner.  The signaling congestion control procedures currently implemented for CCS networks in the U.S. are based on message priorities.  On the other hand, ITU-T BISUP Rec. Q.2764 defines signaling congestion control procedures based on stepwise reduction and increase of total BISUP traffic load. The ITU-T procedures do not make use of message priorities.  

The BISUP message priorities are currently under discussion. Provisional BISUP message priorities for use with MTP congestion control procedures are accepted for inclusion in ANSI T1.111.  Message priorities are not intended to indicate which messages should be processed first, but are instead used to determine which messages should be discarded in the event of signaling network congestion.  Four priority levels (0, 1, 2, and 3) are defined, 0 being the lowest and 3 the highest priority level.  

	(R) 7-182	Based on network provider preference, the Broadband Switching System 			(BSS) shall support one of the MTP congestion control procedures 				specified in Sections 3.8 and 11.2.3-11.2.5 in ITU-T Recommendation 			Q.704. For U. S. networks, the BSS shall support the MTP congestion 			control procedures specified in Section 3.8 and 11.2.4 of ANSI T1.111.4.

	(R) 7-183	The BSS shall support the passing of the appropriate congestion status 			information in MTP-STATUS primitives to the MTP users.

	(R) 7-184	When the B-ISUP in a BSS receives an MTP-STATUS primitive indicating 			MTP congestion toward an affected point code, the B-ISUP shall control 			generation of signaling messages as follows:

			For the international network, the BSS shall control signaling messages as 			specified in Section 3.7 of ITU-T Recommendation Q.2764.

			For U. S. networks, the BSS shall only generate signaling messages with 			priorities greater than or equal to the congestion status toward the affected 			point code.

	(R) 7-185	On receipt of a Destination Unavailable indication via MTP-PAUSE 			primitive, the BISUP shall take the following action: 
			If the affected destination Signaling Point is not known by the BISUP (not 		connected by virtual paths/channels to the BSS), no action shall be taken.
			If the affected destination Signaling Point is known by the BISUP, all 		virtual paths/channels to that destination shall be blocked for new 			call/connections.

Call/connections in progress (already set up) need not be released even though signaling messages cannot be sent to the affected BSS. (While it may not be technically necessary to release call/connections in progress, a carrier may choose to release such call/connections, perhaps after some time interval, if there is a concern about over charging due to the inability of the BSS to completely clear the call/connection when either the calling or called party disconnects.)
	(R) 7-186	On receipt of a Destination Available indication via MTP-RESUME 			primitive, the BISUP shall take the following action:

			If the affected destination Signaling Point is not known by the BISUP (not 		connected by virtual paths/channels to the BSS), no action shall be taken.

			If the affected destination Signaling Point is known by the BISUP, the 		virtual paths/channels shall be unblocked and any of them in the idle state 		can be used for call/connections immediately. Normal call/connection 		release procedures that may have started during the period of signaling 		isolation shall continue and will ensure that affected virtual paths/channels 		shall be returned to idle state. 

The VPCI Consistency Check is provided to verify the consistent and correct allocation of a logical VPCI to a Virtual Path on an interface in both connected switches. The check is performed to guarantee that a user plane information flow is possible between the two adjacent switches using the bi-laterally agreed upon logical VPCI.  The consistency of the logical VPCI is checked at the far end by monitoring the receipt of a user plane test flow in the Virtual Path at a particular interface that is indicated by the VPCI. After the performance of the check, the result of the Loopback test (continuity at the Virtual Path level) is available in the initiating node. The result of the monitoring function (receipt of Loopback cells at the Virtual Path Connection level) is available at the adjacent node and is sent back to the initiating BSS. The procedure can be initiated automatically (i.e., by the BSS) or manually (i.e., by the management system). 
	(R) 7-187	The VPCI Consistency Check shall be initiated for only one Virtual Path 			Connection to any adjacent node at a time.
	(R) 7-188	A BSS at either end of a Virtual Path Connection shall be able to initiate 			the VPCI Consistency Check. 
	(R) 7-189	The Virtual Path Connection to be tested shall be blocked when the 				procedure is initiated. 
	(R) 7-190	The CCR and CCE are confirmed operations. The CCRA or CCEA shall 			not be sent until the appropriate action - start or stop of the management 			plane test flow supervision procedure - has been taken.
	(R) 7-191	The end of the VPCI Consistency Check can only be initiated by the same 			BSS which initiated the procedure and shall be accomplished by sending a 			CCE message.

	(R) 7-192	When the BSS initiates the Consistency Check procedure, it shall send the 			CCR message. The Resource Identifier parameter in the CCR shall be set to 			"Connection element identifier: VPCI" and the affected VPCI shall be 			included. 
	(R) 7-193	On sending the CCR message, the BSS shall start timer T41b and wait for 			the CCRA message.  When the CCRA message is received, timer T41b 			shall be stopped.  If the CCRA message is not received before timer T41b 			expires, then the management system shall be informed.
	(R) 7-194	When the CCRA message is received, the management system shall be 			informed about the completion of the VPCI Consistency Check connection 			setup and the management plane test flow (i.e., OAM cell(s) such as 			Loopback) shall be initiated on the VPCI using VCI = 4 (the standard 			identifier for F4 flows; see ITU-T I.610).

	(R) 7-195	When the BSS receives the CCR message indicating the affected Virtual 			Path Connection, the message shall be accepted as a request for a VPCI 			Consistency Check connection set-up and the management system shall be 			informed.  The BSS shall monitor for receipt of an OAM cell (e.g., 			Loopback) on VCI = 4 of the expected VPCI. The BSS shall also send a 			CCRA message. 

	(R) 7-196	When a BSS initiates the end of the Consistency Check procedure, the 			user plane test flow shall be stopped and the CCE message shall be sent. 
	(R) 7-197	On sending the CCE message, the BSS shall start timer T42b and wait for 			the CCEA message.  When the CCEA message is received, timer T42b shall 			be stopped.  If the CCEA message is not received before timer T42b 			expires, then the management system shall be informed.

	(R) 7-198	When the CCEA message is received, it shall contain the Consistency 			Check Result Information parameter.  The VPCI Check Result Indicator in 			this parameter shall be set to the result of the user plane test flow monitoring 			function at the logical Virtual Path Connection level. The maintenance 			system shall be informed about the completion and the result of the check 			and the VPCI Consistency Check connection shall be released.

	(R) 7-199	When a BSS receives the CCE message, the user plane test flow 				monitoring function shall be disconnected. The management system shall be 			informed about the completion of the test. The VPCI Consistency Check 			connection shall be released and the CCEA message shall be sent. The 			CCEA message shall contain the consistency check result information 			parameter. The VPCI check result indicator in this parameter shall be set to 			"VPCI check successful" or "VPCI check not successful" depending on the 			result of the user plane test flow monitoring function at the logical Virtual 			Path Connection level.  If, due to any reason, the monitoring function could 			not be performed properly, the VPCI check result indicator shall be set to 			"virtual path connection identifier check not performed". 

	(R) 7-200	(a)	If a CCRA message is received which is not a correct response to a 				sent CCR message, it shall be discarded.
			(b)	If a CCEA message is received which is not a correct response to a 			sent CCE message, it shall be discarded.
			(c)	If a CCR message is received requesting a VPCI Consistency Check 			for a Virtual Path Connection that is not controlled by the B‑ISDN 			User Part, it shall be discarded. 
			(d)	If a CCR message is received requesting a VPCI Consistency Check 			for a Virtual Path Connection for which a CCR message has been 			sent, it shall be discarded.

Unrecognized messages are those having a message type code that is not recognized by a BSS.  The processing of an unrecognized message is specified by the contents of the Message Compatibility Information field.

Unrecognized parameters are parameters having a parameter name coding that is not recognized by a BSS.  Unrecognized parameters can appear in any message, and the handling of such parameters is specified by the contents of the Parameter Compatibility Information field.

Every message will contain a Message Compatibility Information field. Every parameter will contain a Parameter Compatibility Information field. Compatibility information will be received in the same message/parameter as the unrecognized information.

It may happen that a BSS receives unrecognized signaling information, i.e., messages, parameter types or parameter values.  This can typically be caused by the upgrading of the signaling system used by other switches in the network. In these cases the following compatibility procedures are invoked to ensure predictable network behavior.

The procedures to be used on receipt of unrecognized information make use of the compatibility information received in the same message as the unrecognized information and the following messages and cause indicators:
	- the Confusion (CFN) message,
	- the Release (REL) message,
	- the Release Complete (RLC) message,
	- the IAR message
	- the Cause Indicators parameter.

The following cause values are used:
	- "message type non-existent or not implemented, discarded"
	- "parameter non-existent or not implemented, discarded"
	- "message with unrecognized parameter, discarded"

	(R) 7-201	For the above cause values, a diagnostic field shall be included that 				contains the unrecognized parameter name(s), the message type code, or the 			message type code and the unrecognized parameter name(s), depending on 			the cause value.

The procedures are based on the following assumptions:

	(a)	The forward compatibility information contains different instructions for different 		switches. There are two classifications of switches:  (1) originating, destination, or 		interworking and (2) intermediate switches. The mapping of originating, 			destination, or interworking and intermediate switches to the function a BSS may 		perform is listed below. It is determined on a per call/connection basis. 

	(b)	If a switch receives a Confusion message, or a Release or Release Complete 		message indicating an unrecognized message or parameter was received, it assumes 		that an interaction with a switch at a different functional level has occurred.

	(c)	When handling recognized information, an intermediate switch acting as a transit 		node passes on the compatibility information unchanged.

Definitions of the Switch (BSS) Types:

•	Originating switch, i.e., the switch in which the call/connection is generated from a public network point of view.
•	Destination switch, i.e., the switch to which the call/connection is destined from a public network point of view.
•	Interworking switch, i.e., the switch in which interworking is performed between the BISUP and the N-ISDN User Part.
•	Intermediate switch, i.e., a switch that acts as a transit node.

When an unrecognized parameter or message is received, the BSS  will find the corresponding instructions contained in the parameter compatibility information or message compatibility information  field,  respectively.  The message compatibility information  contains the instructions specific for handling of the complete message.

The instruction indicators are a set of Boolean indicators. The following requirement applies to the examination of these instruction indicators:

	(R) 7-202	(a)	Depending on the role of the BSS in the call/connection, i.e., (1) 				originating, destination, or interworking and (2) intermediate, and 				the settings of the indicators, only a subset of the indicators shall be 				examined and the rest shall be ignored.

		Only intermediate BSSs shall examine the "Transit at Intermediate 		BSS indicator." If it is set to  "Transit Interpretation," the other 		indicators shall be ignored. If it is set to "End Node Interpretation," 		the intermediate BSS shall examine all instruction indicators.

		Originating, destination and interworking BSSs shall always 		interpret the remaining indicators, i.e., all indicators except the 		"Transit at Intermediate BSS indicator."

		(b)	Instruction indicators marked as "spare" shall not be examined. 		They may be used by future phases of the BISUP; in this case, the 		future phase of the BISUP will set the currently defined instruction 		indicators to a reasonable value for the current phase. This rule 		ensures that more types of instructions can be  defined in the future 		without creating a backward  compatibility problem.

	(c)	When a BSS receives an unrecognized parameter, it shall decide what 	BSS type it is for the call/connection before performing the compatibility 	actions.

		(d)	At an intermediate BSS, the unrecognized information shall  be passed on 	unchanged if the "Transit at Intermediate BSS indicator" is set to "Transit 	Interpretation."

		(e)	At an originating, destination, or interworking BSS, the "Transit at 	Intermediate BSS indicator" shall not be applicable.

		(f)	At an intermediate BSS that has not been instructed to pass on the 	unrecognized information, i.e., if the "Transit at intermediate BSS 	indicator" is not set to "Transit interpretation," or at an originating, 	destination, or interworking BSS,  if the "Release Call indicator" is set to 	"Release Call,"  the call/connection shall be released.

	(g)	At an intermediate BSS that has not been instructed to pass  on the 	unrecognized information or at an originating, destination, or interworking 	BSS, the following shall be applicable if the "Release  Call indicator" is 	set to "Do Not Release Call":
		•	if the "Discard Message indicator," or the "Discard Parameter 		indicator" is set to "Discard Message/Discard Parameter," the 		message or parameter shall be discarded,
		•	and then, if the "Send Notification indicator" is set to "Send 		Notification," a Confusion message shall be sent towards the BSS 		that  sent the unrecognized information.

	(h)	For the case of an unrecognized parameter it shall be possible for the 	instruction to require that either the unrecognized parameter or the whole 	message be discarded.  This provides for the case where the sending BSS  	determines that it is not acceptable for the message to  continue being 	processed without this parameter.

	(i)	In case a message is used for more than one procedure simultaneously and 	the codings of the instruction indicator of the message compatibility 	information required from these procedures are different, the instruction 	indicator shall be set according to the most stringent combination of the 	possible codings  (i.e., the coding "1" of a bit in the instruction indicator is 	dominant).

	(j)	At an originating, destination, or interworking BSS where "pass on" has 	been specified  for a message or parameter and "pass on" is not possible,  	then the "pass on not possible indicator" and "send  notification indicator" 	shall be examined.

	(R) 7-203	BSS A shall not send a Confusion message to BSS B in response to a 			received Confusion message, Release message or Release Complete 			message from BSS B. Any unrecognized parameters received in a 				Confusion message or Release complete message shall be discarded by 			BSS A.

	(R) 7-204	Depending on the instructions received in the "Message Compatibility 			Information field," an originating, destination, or interworking BSS 			receiving an unrecognized message shall either:
			•	transfer the message transparently,
			•	discard the message,
			•	discard the message and send a Confusion message, or
			•	release the call/connection.

	(R) 7-205	A Release, an IAM Reject or a Confusion message in response to an 			unrecognized message shall include the cause  "message type non-existent 			or not implemented - discarded," followed by a diagnostic field containing 			the message type code. 

Unexpected parameters (a parameter in the "wrong" message) are handled like unrecognized parameters.

	(R) 7-206	Depending on the instructions received in the "Parameter Compatibility 			Information sub field ," a BSS receiving an unrecognized parameter shall 			either:
• transfer the parameter transparently,
• discard the parameter,
• discard the message,
• discard the parameter and send a Confusion message,
• discard the message and send a Confusion message, or
• release the call/connection.

	(R) 7-207	A Confusion message shall include the cause "parameter non-existent or not 			implemented - discarded" followed by a diagnostic field containing the 			parameter name, or "message with unrecognized parameter discarded," 			followed by a diagnostic field containing the parameter name, or the 			message and parameter name and the name of the first detected 				unrecognized parameter which caused the message to be discarded. A 			Confusion message may refer to multiple unrecognized parameters.

	(R) 7-208	A BSS receiving a message including multiple unrecognized parameters 			shall process the different instruction indicators, associated with those 			parameters, according to the following order:
	1. release the call/connection,
	2. discard the message and send a Confusion Message,
	3. discard the message.

	(R) 7-209	A Release or IAM Reject message in response to an unexpected parameter 			shall include the cause "parameter non-existent or not implemented - 			discarded" (in response to an unrecognized message) followed by a 			diagnostic field containing the parameter name. 

	(R) 7-210	If a Release message is received containing an unrecognized parameter, 			depending on the instructions received in the parameter compatibility 			information sub field the BSS shall either:
	•  transfer the parameter transparently, 
	•  discard the parameter, or
	•  discard the parameter and send a cause "parameter non-existent or not 
	    implemented - discarded," in the Release Complete message.

Any parameter values marked as "spare" or "reserved" may be regarded as unrecognized, unless otherwise specified in this document.

	(R) 7-211	If a BSS receives and detects a recognized parameter, but the contents are 			unrecognized, then the procedures as stated for unrecognized parameters 			shall apply. There is no specific compatibility information sub field for each 			parameter value.  For any unrecognized parameter value contained in a 			parameter, the compatibility information of the parameter shall apply.

Action taken on receipt of messages at an originating, destination, or interworking BSS indicating that unrecognized information has been sent will depend on the call/connection state and the affected service.

The definition of any procedure that is outside the basic call/connection set-up protocol, as defined in these requirements, will include procedures for handling responses that indicate that another BSS has received, but not recognized, information belonging to that procedure. 

	(R) 7-212	The default action taken on receipt of a Confusion message shall be to 			discard the message without disrupting normal call/connection processing.

	(R) 7-213	Action taken on receipt of a Release, a Release Complete, or an IAM Reject 			message with a cause indicating unrecognized information shall be as for the 			normal procedures for these messages.

(a)	Confusion message (message type non-existent or not implemented - discarded) 

	(R) 7-214	A BSS receiving a Confusion message (message type non-existent or not 			implemented - discarded) shall determine the appropriate subsequent action 			as described above for originating, destination, or interworking BSSs.

(b)	Confusion message (parameter non-existent or not implemented - discarded, or passed on)

	(R) 7-215	The actions taken at an intermediate BSS on receipt of a Confusion 				message with cause "parameter non-existent or not implemented - 				discarded, or passed on" shall depend on whether the BSS has the 				functionality to generate the parameter identified in the diagnostic field:

			(1)	If the BSS does not have the functionality to generate the 					parameter, the decision on what action should be taken shall be 				deferred to a BSS that does contain this functionality. This is 				achieved by passing the Confusion message transparently through 				the intermediate BSS.

			(2)	If this BSS does have the functionality to generate the parameter, 				the procedural element that created or modified the information shall 				determine any subsequent actions, as described for originating, 				destination, and interworking BSSs above.

(c)	Release message, Release Complete message, or IAM Reject message

	(R) 7-216	Action taken on receipt of a Release, a Release Complete, or an IAM Reject 			message with a cause indicating unrecognized information shall be as for the 			normal procedures for these messages.

The BSS needs to monitor unrecognized BISUP messages and parameters.  The BSS shall keep separate counts for each unique OPC/DPC combination ("OPC/DPC signaling relationship") to allow quick identification of the signaling entities that are involved.

	(R) 7-217	For each OPC/DPC signaling relationship, the BSS shall count the number 			of calls/connections that it releases  due the following:

•	Unrecognized BISUP message 

•	Unrecognized parameter(s) in a BISUP message 

Note that, as discussed earlier, whenever it releases a call/connection due to unrecognized information, the BSS generates an IAM Reject message or Release message.

	(R) 7-218	For each OPC/DPC signaling relationship, the BSS shall count the 				following events (none of the following results in clearing the 				call/connection):

•	It discards a BISUP message  due to unrecognized BISUP message 

•	It discards a BISUP message due to one or more unrecognized parameter(s)  

•	It discards one or more parameter(s) in a BISUP message due to unrecognized parameter(s) in the message  (Note that in this case the counter is incremented by one, regardless of the number of parameters that are discarded.)

In addition to making the above counts, it is desirable for the BSS to be capable of logging BISUP messages on a given OPC/DPC signaling relation. When active, all messages sent and received over that OPC/DPC signaling relation should be logged. Such a capability should be activated/deactivated by Management System requests. 

This section specifies the BISUP procedures for establishing, maintaining, and clearing of network point-to-multipoint connections at the B-ICI. This section is based on the basic B-ISDN User Part signaling procedures for point-to-point connection specified in Sections 7.8 to 7.10. The procedures described in this section are based on, and are consistent with, the ITU-T Recommendation  Q.2722.1.  The access signaling procedures are contained in UNI Specification Version 3.1.

This section specifies the following interactions:
	-	interaction with a leaf party that does not support multipoint procedures.
	-	interaction with a leaf party that is not a Broadband user.

The procedures described in this section support the following capabilities. Root is the source of the point-to-multipoint connection. Leaf is one of the destinations of the point-to-multipoint connection.

(i)	Establishment of a call containing one point-to-multipoint network connection requested by 	the root party of the network connection.

(ii)	Addition of one  new party, requested by the root party of the network connection.

(iii)	Drop of a leaf party from an existing call, requested by the root party.

(iv)	Drop of a leaf party from an existing call, requested by the leaf party itself.

(v)	Release of the call, requested by the root party (en bloc release).

The capabilities above will not be combined with narrowband emulation services. Only unidirectional (forward), single connection point-to-multipoint calls are supported.

Refer to Section 7.8.2 for the management of VPCI/VCI value and bandwidth of each VPC, assignment procedure of VPCI/VCI and bandwidth, and related error conditions. Figures 7.7 show BISUP message flows for the set up and release of point-to-multipoint call and connections.

This section describes procedures for a successful point-to-multipoint call establishment where user plane information is multicasted unidirectional from one root party to a set of leaf parties.  These procedures are activated on receipt of a call request from the B-ISDN access indicating, "point-to-multipoint" in the user plane configuration field of the Broadband Bearer Capability parameter.

Section 7.11.2.1 specifies the signaling procedures for the setup of the first leaf party of the point-to-multipoint call initiated by the root party. Section 7.11.2.2 specifies the signaling procedures for the addition of one new leaf party and for the attachment of the party to the point-to-multipoint (Type 2) network connection.  This can only be requested by the root party.

(a)	Route and Virtual Channel Selection - Assigning BSS

When the originating BSS has received the complete information from the root party of the point-to-multipoint connection and has determined that the call/connection is to be routed to another BSS, route and virtual channel selection takes place.

Appropriate routing information is either stored at the originating BSS or at a remote database. Refer to Section 7.8.5.1.1 (a) for the requirements on selection of the route and virtual channel.

(R) 7-219	In addition, the BSS shall assign a connection link identifier to identify 		the outgoing connection link. 

(b)	Route and Virtual Channel Selection - Non-assigning BSS

(R) 7-220	For the originating BSS that acts as a non-assigning BSS for the 			connection, the route and virtual channel selection procedures shall be as in 		(a) above for an assigning BSS except that the VPCI/VCI and bandwidth 		assignment procedures shall be according to Section 7.8.2.2 (b).

(c)	Address Information Sending Sequence

Refer to Section 7.8.5.1.1 (c).

(d)	IAM - Sent by the Assigning BSS

The IAM will contain all the information required to route the call/connection to the destination BSS, and  to connect the call/connection to the leaf party.

Refer to Section 7.8.5.1.1 (d) for the parameters included in the IAM by the originating BSS and related requirements.  In addition, the following requirements apply.

(R) 7-221	The Endpoint reference information element received from the access shall 		be mapped into the Leaf Party Type parameter.  If the Endpoint reference 		information element has the value 0, then the Leaf Party Type parameter 		shall be set to 0 ("First endpoint of Type 2 connection"), else it shall be set 		to 1 ("Subsequent endpoint of Type 2 connection").

(R) 7-222	The IAM shall include the Origination Connection Link Identifier parameter 		(OCLI) containing the CLI assigned by this BSS.

(R) 7-223	For a point-to multipoint connection, the Broadband Bearer Capability 		parameter shall indicate "point-to-multipoint" in the user plane connection 		configuration field. The ATM Cell Rate, Additional ATM Cell Rate, 		Broadband Bearer Capability and Quality of Service parameters shall be 		stored at the requesting serving node or associated data base so that identical 		copies of these parameters can be sent in the subsequent IAMs for the 		addition of leaf parties.

(R) 7-224	If the call request from the access contains a Broadband Bearer Capability 		indicating "point-to-multipoint" in the user plane connection configuration 		field and contains an ATM traffic descriptor information element containing 		any backward cell rate field which specifies a non-zero value, the 			call/connection shall be rejected with cause #73, "unsupported combination 		of traffic parameters".

After sending the IAM, a response is awaited, i.e., an IAA or an IAR. 

(e)	IAM - Sent by the Non-Assigning BSS

(R) 7-225	The originating BSS that acts as a non-assigning BSS for this 			connection shall follow the procedures described in d) above for the 		assigning BSS with the exception that the CEI shall not be included in the 		IAM. 

(f)	Completion of Transmission Path

Refer to Section 7.8.5.1.1 (f).

7.11.2.1.2.1	Incoming Side of the BSS

(a)	Assigning BSS

(R) 7-226	After receiving the IAM, the intermediate BSS shall assign a connection 		link identifier to identify the incoming connection link.  The intermediate 		BSS that acts as an assigning BSS for this connection shall perform the 		assignment procedure for VPCI/VCI and bandwidth as described in Section 		7.8.2.2 (b).  If this is successful, the IAA shall be sent immediately without 		waiting for further call processing. 

Refer to Section 7.8.5.1.2.1 (a) for the parameters included in the IAA by the intermediate BSS and related requirements.  In addition, the following requirements apply.

(R) 7-227	The IAA shall include the origination connection link identifier parameter 		containing the connection link identifier assigned by this BSS.

(b)	Non-Assigning BSS

(R) 7-228	After receiving the IAM, the intermediate BSS that acts as a non-assigning 		BSS shall perform the assignment procedure for VPCI/VCI and 			bandwidth as described in Section 7.8.2.2 (a).  If this is successful, the 		IAA shall be sent immediately without waiting for further call processing. 
(R) 7-229	Further procedures shall be as for the assigning BSS described in (a) 		above except that CEI shall not be included in the IAA. 

7.11.2.1.2.2	Outgoing Side of the BSS

(a)	Virtual Channel Selection
(R) 7-230	After sending the IAA, an intermediate BSS shall analyze the called party 		number and the other routing information (see Section 7.8.5.1.1) to 		determine the routing of the connection. If the intermediate BSS can route 		the connection, it shall assign a connection link identifier to identify the 		outgoing connection link, establish a logical association between the 		incoming and outgoing connections and send an IAM to the selected carrier.  		The BSS shall follow the assignment procedure for VPCI/VCI and 		bandwidth as described in Section 7.8.2.2.

(b)	Parameters in the IAM Sent by the Assigning BSS

Refer to Section 7.8.5.1.2.2 (b) for the parameters included in the IAM and related requirements.  In addition, the following requirements apply.

(R) 7-231	The IAM shall include the Origination Connection Link Identifier parameter 		containing the connection link identifier assigned by this BSS.

After sending the IAM, a response is awaited, i.e., an IAA or an IAR.

(c)	Parameters in the IAM Sent by the Non-Assigning BSS

(R) 7-232	The intermediate BSS that acts as a non-assigning BSS for this call shall 		follow the procedures described in (b) above for the assigning BSS with 		the exception that the CEI shall not be included in the IAM. 

(d)	Sending of Exit Message

Refer to Section 7.8.5.1.2.2 (d) for related requirements.

(e)	Completion of Transmission Path

Refer to Section 7.8.5.1.2.2 (e).

(R) 7-233	An intermediate BSS in a transit carrier shall meet the same requirements 		described above for the intermediate BSS in the originating carrier.  

7.11.2.1.4.1	Incoming Side of the BSS

(a)	Assigning BSS

(R) 7-234	Same requirements as in Section 7.11.2.1.2.1 (a) shall be applicable except 		that the preceding BSS in this case is the BSS belonging to the carrier 		routing the call to the terminating carrier.

(b)	Non-Assigning BSS

(R) 7-235	The requirements in Section 7.11.2.1.2.1 (b) shall apply.
7.11.2.1.4.2	Outgoing Side of the BSS

(a)	Virtual Channel Selection
(R) 7-236	After sending the IAA to the preceding carrier, an intermediate BSS shall 		analyze the Called Party Number to determine the routing of the connection.  		If the intermediate BSS can route the connection, it shall assign a 			connection link identifier to identify the outgoing connection link, establish 		a logical association between the incoming and outgoing connections and 		shall send an IAM to the destination BSS. The BSS shall follow the 		assignment procedure for VPCI/VCI and bandwidth as described in Section 		7.8.2.2.

(b)	Parameters in the IAM Sent by the Assigning BSS

Refer to Section 7.8.5.1.4.2 (b) for the parameters included in the IAM and related requirements.  In addition, the following requirements apply.

(R) 7-237	The IAM shall include the Origination Connection Link Identifier parameter 		containing the connection link identifier assigned by this BSS.

After sending the IAM, a response is awaited, i.e., an IAA or an IAR.

(c)	Parameters in the IAM Sent by the Non-Assigning BSS

(R) 7-238	The intermediate BSS that acts as a non-assigning BSS for this call shall 		follow the procedures described in (b) above for the assigning BSS with 		the exception that the CEI shall not be included in the IAM. 

(d)	Completion of Transmission Path

Refer to Section 7.8.5.1.2.2 (e).

(a)	Incoming Side - Assigning BSS

	(R) 7-239	Same requirements as in Section 7.11.2.1.2.1 (a) shall be applicable.

(b)	Incoming Side - Non-Assigning BSS

(R) 7-240	The requirements in Section 7.11.2.1.2.1(b) shall apply.

(c)	Call Processing

(R) 7-241	After sending the IAA, the destination BSS shall analyze the Called Party 		Number to determine to which party the call should be connected.  It shall 		also check the called (leaf) party's access condition and perform various 		checks to determine whether the connection is allowed. If the connection is 		allowed, the destination BSS shall proceed to offer the call/connection 		to the leaf party.  Refer to Section 7.8.5.1.5 (c) for further requirements.

Case 1 is where a new network connection needs to be established to another BSS because no connection link to that BSS exists for this point-to-multipoint call. Case 2 is where the network connection needs to be routed to another BSS to which there already is a connection link established for this point-to-multipoint call.

(R) 7-242	Connection for a new leaf party shall not be routed over a connection link 		used for previous leaf parties if the connection link is on a blocked virtual 		path.  Alternative routing may be done using another virtual path.  Refer to 		Section 7.11.6.2.

(a)	Route and Virtual Channel Selection - Assigning BSS

When the originating BSS has received the complete information from the root party for the addition of a new leaf party to the existing point-to-multipoint network connection and has determined that the connection is to be routed to another BSS, route and virtual channel selection takes place.

Appropriate routing information is either stored at the originating BSS or at a remote database. Refer to Section 7.8.5.1.1 (a) for the requirements on selection of the route.  Note that the relevant information (e.g., called party number, transit network selection, etc.) for the new leaf party will be in the ADD PARTY MESSAGE instead of the SETUP MESSAGE.

(R) 7-243	The ATM Cell Rate, Broadband Bearer Capability, Quality of Service and 		Additional ATM Cell Rate (if present) parameters shall be retrieved from the 		call information stored when the connection to the first party of the point-to-		multipoint call was established by this BSS.

(R) 7-244	It shall be determined whether the connection is to be routed to another 		BSS to which a connection has already been established for this call.

(R) 7-245	In Case 1, the procedures defined in section 7.11.2.1.1 (a) shall apply.

(R) 7-246	In Case 2, the existing Outgoing Connection Link identifier shall be used 		and an IAM shall be sent.  No VPCI/VCI and bandwidth assignment 		procedures shall take place because no new user plane connection is 		established.  The Destination Connection Link Identifier parameter 			associated with the Outgoing Connection Link shall be included in the IAM.

(b)	Route and Virtual Channel Selection - Non-Assigning BSS

(R) 7-247	The route and virtual channel selection procedures shall be as in (a) above 		for an assigning BSS except that, if required, the VPCI/VCI and 			bandwidth assignment procedures shall be according to Section 7.8.2.2 (b).

(c)	Address Information Sending Sequence

Refer to Section 7.8.5.1.1 (c).

(d)	IAM - Sent by the Assigning BSS

Refer to Section 7.8.5.1.1 (d) for the parameters included in the IAM by the originating BSS and related requirements.  Note that information from the calling user comes in the ADD PARTY Message instead of the SETUP MESSAGE.  In addition, the following requirements apply.

(R) 7-248	In Case 1, the IAM shall contain the Origination Connection Link Identifier 		and the Connection Element Identifier parameters. 

(R) 7-249	In Case 2, the IAM shall contain the Destination Connection Link Identifier 		parameter and shall not contain the Connection Element Identifier parameter.

(R) 7-250	The IAM shall include the stored values of the ATM Cell Rate, Broadband 		Bearer Capability, Quality of Service and additional ATM Cell Rate (if 		present) parameters as used for the initial Set-up.

(R) 7-251	The IAM shall include the Calling Party Number, Calling Party Subaddress, 		Called Party Subaddress, Broadband High Layer Information, Broadband 		Low Layer Information, and AAL-parameters parameter if the 			corresponding IEs are received in the ADD PARTY MESSAGE from the 		root and the transfer of this information is allowed by subscription and for 		the specific carrier selected to route the connection for the leaf party. The 		AESA for Called Party and AESA for Calling Party parameters are included 		in the IAM if they were generated because the CdPN and/or CgPN IE 		contained an AESA. This information shall not be retrieved from stored 		data.

(R) 7-252	As a carrier option (See Section 7.3.2.2), the IAM shall include the CIP, 		Charge Number, OLI and Carrier Selection Information parameters based 		on prior agreements between the connecting carriers involved in routing the 		connection for the leaf party. 

(R) 7-253	The IAM shall include the Leaf Party Type parameter set to 1 ("Subsequent 		end point of Type 2 connection").

(R) 7-254	If the add party request from the access contains a Broadband Bearer 		Capability indicating "point-to-multipoint" in the user plane connection 		configuration field and contains an ATM traffic descriptor information 		element containing any backward cell rate field which specifies a non-zero 		value, the addition of a new party shall be rejected with cause #73, 			"unsupported combination of traffic parameters".

After sending the IAM, a response is awaited, i.e., an IAA or an IAR.

(e)	IAM - Sent by the Non-Assigning BSS

(R) 7-255	The originating BSS that acts as a non-assigning BSS for this 			connection shall follow the procedures described in (d) above for the 		assigning BSS with the exception that the CEI shall not be included in the 		IAM.

(f)	Completion of Transmission Path

(R) 7-256	The completion of the transmission path is only applicable for Case 1 (a 		new user plane connection is established) and the procedures defined in 		Section 7.8.5.1.1 (f) shall apply.  Furthermore, a cell replication function 		shall be invoked.

7.11.2.2.2.1	Incoming Side of the BSS

(R) 7-257	If the received IAM contains the origination connection link identifier (i.e., 		an incoming connection link does not exist), the procedures shall continue 		as in Section 7.11.2.1.2.1.

(R) 7-258	If the received IAM contains the Destination Connection Link  Identifier 		parameter, the associated Connection Link and virtual channel already exist 		for the incoming point-to-multipoint connection.  The following procedures 		shall apply for both the assigning and non-assigning BSSs:
		The IAA shall be sent immediately.  The IAA shall contain the OSID and 	DSID, but not the Connection Element Identifier parameter.
7.11.2.2.2.2	Outgoing Side of the BSS
(a)	Route and Virtual Channel Selection
(R) 7-259	After sending the IAA, an intermediate BSS shall analyze the called party 		number and the other routing information (see Section 7.8.5.1.1 a) to 		determine the routing of the call. 

(R) 7-260	The procedures shall continue as in Section 7.11.2.1.2.2 (a)-(c) if the 		connection for the additional party needs to be routed to another BSS 		not currently the far end for any of the existing outgoing connection links 		for the call. (This is Case 1.)

(R) 7-261	If the additional party connection needs to be routed to an BSS that is 		already the far end of an existing Outgoing Connection Link for this point-		to-multipoint call, the following procedures shall apply.  (This is Case 2.)

			(a)	The BSS shall assign a SID, establish a logical association 				between the incoming and outgoing SIDs used for this connection 			establishment, and send an IAM.  The BSS shall not perform 			the assignment procedure for VPCI/VCI and bandwidth.  The 			Connection Element identifier (VPCI/VCI) used for the new party 			shall correspond to the stored values for the Outgoing Connection 			Link.  In case the Destination Connection Link Identifier is not yet 			known at the BSS, the BSS shall wait for the IAA in response to the 			first IAM sent for this Outgoing Connection Link.

		(b)	Parameters in the IAM sent by the Assigning BSS
			Refer to Section 7.8.5.1.2.2 (b) for the parameters included in the 			IAM and related requirements except that the CEI shall not be 			included.  In addition, the IAM shall include the destination 				connection link identifier parameter.
			After sending the IAM, a response is awaited, i.e., an IAA or an 			IAR.

		(c)	Parameters in the IAM sent by the Non-Assigning BSS
			Refer to (b) above. 

(b)	Sending of Exit Message

Refer to Section 7.8.5.1.2.2 (d) for related requirements.

(c)	Completion of Transmission Path

(R) 7-262	The completion of the transmission path is only applicable for Case 1 (a 		new user plane connection is established) and the procedures defined in 		Section 7.8.5.1.2.2 (e) shall apply.  Furthermore, a cell replication function 		shall be invoked.

(R) 7-263	An intermediate BSS in a transit carrier shall meet the same requirements 		described above for the intermediate BSS in the originating carrier. 

7.11.2.2.4.1	Incoming Side of the BSS

Refer to Section 7.11.2.2.2.1.
7.11.2.2.4.2	Outgoing Side of the BSS
(a)	Route and Virtual Channel Selection
(R) 7-264	After sending the IAA, an intermediate BSS shall analyze the called party 		number to determine the routing of the call. 

(R) 7-265	The procedures shall continue as in Section 7.11.2.1.4.2 (a)-(c) if the 		connection for the additional party needs to be routed to another BSS 		not currently the far end for any of the existing outgoing connection links 		for the call.  (This is Case 1.)

(R) 7-266	If the additional party connection needs to be routed to an BSS that is 		already the far end of an existing Outgoing Connection Link for this point-		to-multipoint call, the following procedures shall apply.  (This is Case 2.)

			(a)	The BSS shall assign a SID, establish a logical association 				between the incoming and outgoing SIDs used for this connection 			establishment, and send an IAM.  The BSS shall not perform 			the assignment procedure for VPCI/VCI and bandwidth.  The 			Connection Element identifier (VPCI/VCI) used for the new party 			shall correspond to the stored values for the Outgoing Connection 			Link.  In case the Destination Connection Link Identifier is not yet 			known at the BSS, the BSS shall wait for the IAA in response to the 			first IAM sent for this Outgoing Connection Link.

		(b)	Parameters in the IAM Sent by the Assigning BSS:
			Refer to Section 7.8.5.1.4.2 (b) for the parameters included in the 			IAM and related requirements except that the CEI shall not be 			included.  In addition, the IAM shall include the destination 				connection link identifier parameter.
			After sending the IAM, a response is awaited, i.e., an IAA or an 			IAR.

		(c)	Parameters in the IAM Sent by the Non-Assigning BSS:
			Refer to (b) above.  

(b)	Completion of Transmission Path

(R) 7-267	The completion of the transmission path is only applicable for Case 1 (a 		new user plane connection is established) and the procedures defined in 		section 7.8.5.1.2.2 (e) shall apply.  Furthermore a cell replication function 		shall be invoked.

(a) Incoming Side
Refer to Section 7.11.2.2.2.1.

(b) Call Processing
Refer to Section 7.11.2.1.5 c.

Refer to Section 7.8.5.2.

Refer to Section 7.8.5.3.

Refer to Section 7.8.5.4.

Refer to Section 7.8.5.5.  In addition the following requirement applies.

(R) 7-268	The originating BSS of the connection shall store the ATM Cell Rate, 		Broadband Bearer Capability, Quality of Service and Additional ATM Cell 		Rate (if present) parameters contained in the first  IAM sent. This call 		information shall be stored so that identical copies of these parameters can 		be sent in the subsequent IAMs for setting up connections to additional leaf 		parties.

Refer to Section 7.11.2.2 for the definitions of Case 1 and Case 2.

(R) 7-269	If at any time the call/connection establishment to the first leaf party or the 		establishment of a new connection link (leg) for the addition of a new leaf 		party (Case 1) cannot be completed due to a lack of resources at the 		incoming side (e.g., SIDs, CLIDs, VPCI/VCI or bandwidth), the BSS 		receiving the IAM shall immediately send an IAR towards the preceding 		BSS. The IAR shall contain the DSID and cause indicators parameter. 		Cause value 47 (resource unavailable - unspecified) shall be included if no 		SIDs or CLIDs were available; cause value 45 (no VPCI/VCI available) 		shall be included in the case of a lack of VPCI/VCI; and cause value 37 		(ATM Cell Rate not available) shall be included in the case of a lack of 		bandwidth. The incoming signaling association shall be deleted.

(R) 7-270	If at any time the addition of one new leaf party to an already existing 		connection link (Case 2) cannot be completed due to a lack of resources at 		the incoming side (e.g., SIDs), the BSS receiving the IAM shall 			immediately send an IAR towards the preceding BSS. The IAR shall 		contain the DSID and cause indicators parameter. Cause value 47 (resource 		unavailable - unspecified) shall be included if no SIDs were available.

(R) 7-271	If at any time the call/connection establishment to the first leaf party or the 		establishment of a new connection link (leg) for the addition of a new leaf 		party (Case 1) cannot be completed due to a lack of resources at the 		outgoing side (e.g., SIDs, CLIDs, VPCI/VCI or bandwidth), the BSS 		shall immediately start to drop the leaf party and shall send an REL towards 		the preceding BSS. The REL shall contain the DSID and cause 			indicators parameter.  Cause value 47 (resource unavailable - unspecified) 		shall be included if no SIDs or CLIDs were available, cause value 45 (no 		VPCI/VCI available) shall be included in the case of a lack of VPCI/VCI; 		and cause value 37 (ATM Cell Rate not available) shall be included in the 		case of a lack of bandwidth. Further procedures shall be as in Section 		7.11.3.4.

(R) 7-272	If at any time the addition of a new leaf party to an already existing 			connection link (Case 2) cannot be completed due to a lack of resources at 		the outgoing side (e.g., SIDs), the BSS shall immediately start to drop 		the leaf party and shall send an REL towards the preceding BSS. The 		REL shall contain the DSID and cause indicators parameter.  Cause value 47 		(resource unavailable - unspecified) shall be included if no SIDs were 		available.  Further procedures shall be as in Sec. 7.11.3.4.

(R) 7-273	If an BSS receives an IAR during either the call/connection 				establishment to the first leaf party or the establishment of a new connection 		link (leg) for the addition of a new leaf party (Case 1), it shall release the 		VPCI/VCI (if applicable) and the bandwidth, and shall terminate the 		outgoing signaling association, i.e. the associated outgoing Connection 		Link ID and the SID.  The BSS may attempt to re-route the 				call/connection. 

(R) 7-274	If an BSS receives an IAR during the addition of a new leaf party to an 		already existing connection link (Case 2), it shall terminate the signaling 		association, i.e. the associated SID is deleted.  The BSS may provide 		the capability to re-route the call/connection.

(R) 7-275	If all attempts to re-route the connection have failed the BSS shall:

		(a)	If this is an intermediate BSS, it shall send an REL with the 			received cause value towards the preceding BSS.  Further 				procedures shall be as in Section 7.11.3.4.
		(b)	If this is an originating BSS, it  shall send an indication to the 			calling user.

(R) 7-276	If during the establishment of a point-to-multipoint network connection for 		the first leaf party an BSS receives a Release message from the succeeding 		BSS after the IAA and before the ACM, the BSS shall release the 			VPCI/VCI (if applicable) and the bandwidth, and shall send an RLC. The 		outgoing signaling association is terminated, i.e. the associated outgoing 		Connection Link ID and the corresponding SID are deleted. The BSS may 		attempt to re-route the connection.  If all attempts to re-route the connection 		have failed, the BSS shall:

		(a)	If this is an intermediate BSS, it shall send an REL with the 			received cause value towards the preceding BSS.  Further 				procedures shall be as in Sec. 7.11.4.1.
		(b)	If this is an originating BSS, it  shall send an indication to the 			calling user.

(R) 7-277	If during the addition of another leaf party and attachment to the point-to-		multipoint network connection an BSS receives a Release message from the 		succeeding BSS after the IAA and before the ACM, the BSS shall take the 		following actions:

		(a)	The signaling association is terminated, i.e. the associated SID is 			deleted.
		(b)	If there are no other SIDs associated with the concerned Outgoing 			Connection Link ID, the Outgoing Connection Link ID shall be 			deleted and the associated VPCI/VCI (if applicable) and the 				corresponding bandwidth shall be made available for new traffic.
		(c)	Send an RLC.
		(d)	The BSS may attempt to re-route the connection. If all attempts to 			re-route the connection have failed, the BSS shall:
		(i)	If this is an intermediate BSS, it shall send an REL in 			order to drop the leaf party with the received cause value 			towards the preceding BSS.  Further procedures shall be 			as in Sec. 7.11.4.1.
		(ii)	If this is an originating BSS, it  shall send an indication to 			the calling user.

(R) 7-278	If a BSS determines that the proper number of digits for routing the 		connection has not been received, an REL shall be sent towards the 		preceding BSS with cause "address incomplete".  Refer to Section 7.11.4.1 		for further procedures.

The following release procedures are addressed:

	-	En-bloc release of call/connection requested by the root party: this operation will 		cause all parties to be dropped and release of the point-to-multipoint call
	-	Drop of a leaf party from an existing call when requested by the root party
	-	Drop of a leaf party from an existing call when requested by the leaf party itself
The release procedure is a confirmed operation: the Release message initiates release of the call/connection and/or drop of a party and the RLC signifies completion of the release of the call/connection and/or drop of the party. A set of common procedures are used in the network irrespective of whether they are initiated by the root party, the  leaf party or the network.

(R) 7-279	The following actions shall be performed by any BSS receiving a 			Release message:

		(a)	The signaling association is terminated, i.e. the associated SID is 			deleted.
		(b)	If there are no other SIDs associated with the concerned Incoming or 			Outgoing Connection Link ID, the Incoming or Outgoing 				Connection Link ID shall be deleted and the associated VPCI/VCI (if 			applicable) and the corresponding bandwidth shall be made available 			for new traffic.
		(c)	Send an RLC.

(R) 7-280	An BSS that has initiated the release procedure by sending a Release 		message shall perform the following actions on receipt of the RLC:

		(a)	The signaling association is terminated, i.e. the associated SID is 			deleted.
		(b)	If there are no other SIDs associated with the concerned Incoming or 			Outgoing Connection Link ID, the Incoming or Outgoing 				Connection Link ID shall be deleted and the associated VPCI/VCI (if 			applicable) and the corresponding bandwidth shall be made available 			for new traffic.

The following sections describe additional required actions.

(a)	Actions Required at the Originating BSS

(R) 7-281	On receipt of a request from the root party to drop a leaf party, the 			originating  BSS immediately starts the release.  An REL is sent towards the 		succeeding BSS with the DSID corresponding to the remote leaf party to be 		dropped. The REL shall not contain the Destination Connection Link 		Identifier parameter.

(R) 7-282	In case of a premature drop of a leaf party by the root party, the BSS 		shall immediately release the resources towards the root party, but shall 		delay the release of the connection towards the succeeding BSS until 		after the IAA is received.

(b)	Actions at an Intermediate BSS

On receipt of the Release message, an intermediate BSS will send an REL towards the succeeding BSS with the DSID corresponding to the remote leaf party to be dropped. The release  towards the succeeding BSS shall not occur until after the receipt of the IAA.

(c)	Actions Required at the Destination BSS

(R) 7-283	If there is no remaining party at the interface, the BSS shall immediately 		release the resources towards the leaf party.

(d)	Collision of Release Messages

(R) 7-284	In the case when two points in the connection initiate the drop of the same 		leaf party, a Release message may be received at an BSS from a 			succeeding or preceding BSS after the drop is initiated.  In this case, 		the BSS shall return an RLC towards the BSS from which the concerned 		REL was received. The RLC shall be sent when the BSS resources have 		been released.

(a)	Actions Required at the Leaf Party Serving (Destination) BSS

(R) 7-285	On receipt of a request from the access protocol to drop a leaf party, the leaf 		party serving BSS immediately starts the release.  A Release message 		shall be sent towards the preceding BSS with the DSID corresponding 		to the leaf party to be dropped.

(b)	Actions at an Intermediate BSS

(R) 7-286	On receipt of the Release message, an intermediate BSS shall send a 		Release message towards the preceding BSS with the DSID 			corresponding to the leaf party to be dropped.

(c)	Actions Required at the Originating BSS

(R) 7-287	The BSS shall notify the root party that the leaf party has dropped.

(d)	Collision of Release Messages

Refer to Section 7.11.4.2 (d).

The procedures in Section 7.11.4.2 and Section 7.11.4.3 apply, except that they can be initiated at any BSS.

(a)	Actions Required at the Originating  BSS

(R) 7-288	On receipt of a request from the root party to release the call, the BSS 		shall immediately start the release.  For each associated Outgoing 			Connection Link, a Release message is sent towards the succeeding 		BSS containing the relevant Destination Connection Link Identifier 			parameter and one of the associated DSID parameters.  The transmission 		path shall be disconnected.

(R) 7-289	When the RLC related to an Outgoing Connection Link is received:
		•	All the associated SIDs shall be deleted.
		•	The associated VPCI/VCI (if applicable) and the corresponding 		bandwidth shall be made available for new traffic, when the last 		remaining SID associated with the Outgoing Connection Link has 		been deleted.
		•	The Outgoing Connection Link ID shall be deleted.

(R) 7-290	In case of a premature release by the root party, the BSS shall:

		•	Immediately release the resources towards the root party,
		•	Immediately release each connection link towards the succeeding 		BSS for which an IAA has been received,
		•	Delay release of each connection link towards the succeeding BSS 		for which an IAA has not been received until an IAA is received.

(b)	Actions at an Intermediate BSS

(i)	Incoming Side of the BSS
(R) 7-291	On receipt of a Release message containing a Destination Connection Link 		Identifier parameter and DSID, an intermediate BSS:

		•	Shall make the associated VPCI/VCI (if applicable) and 			corresponding bandwidth available for new traffic
		•	Shall delete all the other SIDs associated with the incoming 			Connection Link
		•	Shall return an RLC to the preceding BSS, when all the other 		SIDs associated with the Incoming Connection Link have been 		deleted
		•	When the RLC has been returned, the last remaining SID 			(corresponding to the DSID parameter) and the Incoming 			Connection Link ID shall be deleted.

(ii)	Other Action at the BSS

See section 7.11.4.5 (a).

(c)	Actions Required at the Destination BSS

(i)	Incoming Side of the BSS

See section 7.11.4.5 (b) (i).

(ii)	Other Actions at the BSS

The Destination BSS will immediately release the resources towards the leaf parties.

(d)	Collision of Release Messages

(i)	Outgoing Side of an BSS

(R) 7-292	After sending a Release message with the destination Connection Link 		Identifier parameter, a Release message may be received.  In this case, the 		BSS shall return the corresponding RLC.  The RLC shall be sent when 		the transmission path is disconnected.

(ii)	Incoming Side of an BSS

(R) 7-293	After sending a Release message, a Release message with a Destination 		Connection Link identifier parameter may be received.  In this case, the 		BSS shall continue as described in section 7.11.4.5.(b) (i).

The point-to-multipoint BISUP procedures specified in this section will support connection set up to a broadband leaf party that does not support the point-to-multipoint access procedures defined in UNI 3.1. 

The network will not support the connection establishment to a user that is not a broadband user.
 
(R) 7-294	When an BSS has received the complete call information for the 			establishment of a point-to-multipoint network connection to a remote party 		or the addition of a remote party to an existing network connection and has 		determined that the connection has to be routed to a non-Broadband ISDN 		user, this connection shall be released in accordance with the normal release 		procedures specified in Section 7.11.4. Such a determination could be made 		at a broadband/narrowband interworking BSS or at the destination BSS.

The procedures defined in Section 7.9 apply also to point-to-multipoint, except for the reset procedures, which are specified in this section.

As explained in Section 7.9.1, the reset procedure is used to return signaling identifiers and connection elements (virtual channel links/path connections) to the idle condition. Refer to Section 7.9.1 for the definitions of "remote" and "local" SIDs to be reset. The procedure is invoked under abnormal conditions when the current status of the Signaling Identifiers (SIDs) or the Connection Element Identifiers (CEIs) are unknown or ambiguous.  

(R) 7-295	The reset procedure shall be initiated for the following signaling anomalies 		detected by the B-ISDN signaling system.  These anomalies are detected by 		the protocol procedures, reported to the BSS management functions, and 		thus initiate the reset procedure.

			An unexpected message is one which contains a message type code that is 		within the set supported by the BSS but is not expected to be received in 		the current state of the call. 

			(1)	If an unexpected message (any message other than an IAA or IAR) 			is received while awaiting the IAA, the BSS shall send a reset 			message to reset the remote SID.
			(2)	If an unexpected message (any message other than an ACM, ANM, 			or REL) is received while awaiting the Address Complete message, 			the BSS shall send a reset message to reset the local SID.
			(3)	If the Timer T1b, "Await Release Complete" expires during a drop 			party operation and there are no other SIDs associated with the 			corresponding Connection Link, the BSS shall send a reset 				message to reset the VPCI/VCI.
			(4)	If the Timer T1b, "Await Release Complete" expires during en bloc 			release operation, the BSS shall send a reset message to reset the 			VPCI/VCI.
			(5)	If the Timer T1b, "Await Release Complete" expires during a drop 			party operation and there are other SIDs associated with the 				corresponding Connection Link, the BSS shall send a reset 				message to reset the local SID
			(6)	If the Timer T40b, "Await IAM Acknowledgment", expires during 			connection set up to the first leaf party, an assigning BSS shall 			send a reset message to reset the VPCI/VCI and remove the 				VPCI/VCI and bandwidth from service; a non-assigning BSS 			shall send a reset message to reset the remote SID.  
			(7)	If the Timer T40b, "Await IAM Acknowledgment", expires during 			an add party operation and there are no other SIDs associated with 			the corresponding Connection Link, an assigning BSS shall send 			a reset message to reset the VPCI/VCI and remove the VPCI/VCI 			and bandwidth from service; a non-assigning BSS shall send a 			reset message to reset the remote SID. 
			(8)	If the Timer T40b, "Await IAM Acknowledgment", expires during 			an add party operation and there are other SIDs associated with the 			corresponding Connection Link, the BSS shall send a reset 				message to reset the remote SID. 
			(9)	If an unexpected message is received relating to an unallocated SID, 			the BSS shall send a reset message to reset the remote SID. 
			(10)	If the BSS detects a missing mandatory parameter, then the BSS 			shall send a reset message to reset the local SID.
			(11)	If a maintenance action is invoked due to memory mutilation, e.g., 			losing the association information between a signaling ID and a 			Connection Element identifier, the BSS shall send a reset message 			to reset each affected VPCI.
			(12)	If a maintenance action is invoked involving start-up and restart of a 			BSS and/or a signaling system, the BSS shall send a reset 				message to reset each affected VPCI.

To initiate the reset procedure, the BSS sends a RSM containing the resource identifier parameter. The requirements in Section 7.9.1.1 are applicable. In addition, the following requirements apply for point-to-multipoint. 

(R) 7-296	On receiving the RAM, the affected BSS (the reset initiating BSS) 			shall perform the following actions depending on the type of reset and the 		number of SIDs associated with the Connection Link.

		(a)	If the resource to be reset is a SID and other SIDs are associated 			with the Connection Link, the BSS shall reset the referenced SID 			and put it in the "idle" state.
		(b)	If the resource to be reset is a SID and no other SID is associated 			with the Connection Link, the referenced SID and the associated 			Connection Link identifier shall be put in the "idle" state.  				Additionally, the related VCI is placed in the "idle" state and all 			associated bandwidth is put in the "available" state.
		(c)	If the resource to be reset is VPCI/VCI, the Connection Link 			identifier and all Signaling identifiers associated with the 				Connection Link for the referenced VPCI/VCI are put in the "idle" 			state.  Additionally, the related VCI is placed in the "idle" state and 			all associated bandwidth is put in the "available" state.
		(d)	If the resource to be reset is VPCI, all Connection Link identifiers 			and all Signaling identifiers associated with the Connection Links 			related to the referenced VPCI are put in the "idle" state.  				Additionally, all related VCIs are placed in the "idle" state and all 			associated bandwidth on the virtual path is put in the "available" 			state.

(R) 7-297	On receiving a RSM, the receiving (unaffected) BSS shall take the 			following actions:

		(a)	If it is the incoming or outgoing BSS on a connection in any 			call/connection state, the BSS shall accept the message as a 				request to idle resources it controls. It responds by sending an RAM 			after the indicated resources have been made available for new 			traffic.  The specific actions depend on the type of reset and on the 			number of SIDs associated with the incoming or outgoing 				Connection Link  (see Section 7.11.6.1.1 item (a) to (d)).
		(b)	Interconnected virtual path/channel links and/or associated resources 			at the other side of the BSS shall be released according to 				Section 7.11.4.4 except in the case of call/connections and add party 			operations that are currently awaiting the IAA; in this case, an 			automatic repeat attempt is applicable.
		(c)	Additional actions are described in (b), (d), (e) and (f) of Section 			7.9.1.2.

Refer to Section 7.9.1.3.

Connection for a new leaf party will not be routed over a connection link used for previous leaf parties if the connection link is on a blocked virtual path.  Alternative routing may be done using another virtual path.  Refer to Section 7.11.2.2.

	(R) 7-298	Each BSS shall have the capability to set the following administrative 			data:
			
			Each BSS shall be capable of assigning multiple VPCs to a physical 			path between itself and the BSS at the far-end and shall be capable of 			assigning bandwidth to each such VPC so that the total bandwidth assigned 			to all the VPCs does not exceed the bandwidth of the physical path at any 			point along the physical path. The number of VPCs and the bandwidth 			assigned to each VPC will be based on specific service needs.

			Assignment of a VPCI value to each VPC so that every VPC between this 			BSS and a given connected BSS has a different value. In other words, the 			VPCI values between two BSSs shall be unique. Identical VPCI value shall 			be assigned to each VPC by BSSs at two ends of the VPC. 

			For each VPCI, the BSS shall be able to designate whether it controls 			this VPCI, i.e., it can assign VCI associated with this VPCI for an 				incoming or an outgoing call/connection.  If the BSS does not control a 			VPCI, the BSS at the far-end will be the assigning (controlling) BSS.  The 			default mechanism described in Section 7.8.2.1 for determining assigning/ 			non-assigning BSS designation shall be supported by every BSS.  How 			many VPCIs an BSS controls will be based on specific service needs. 

Certain parameters in the IAM sent by the originating BSS or sent by an intermediate BSS can be set to be included or not included when a call is to be routed to another network.  This has been specified in detail in earlier parts of Section 7, but for completeness, a summary of such parameters is given below.  The basis for including each parameter is also indicated.

	•  AAL Parameters			Per succeeding network and user subscription
	•  Broadband High Layer Information	Per succeeding network and user subscription
	•  Broadband Low Layer Information	Per succeeding network and user subscription
	•  Called Party Subaddress		Per succeeding network and user subscription
	•  Calling Party Number 			Per succeeding network
	•  Calling Party Subaddress		Per succeeding network and user subscription
	•  Carrier Identification Code (*)		Per CIC
	•  Carrier Selection Information (*)	Per succeeding network
	•  Charge Number (*)			Connecting carrier and user subscription
	•  Originating Line Information (*)	Connecting carrier and user subscription

Those parameters indicated with (*) apply only to networks that support ANSI BISUP procedures.
Note that the Charge Number can be different from the Calling Party Number.

	(R) 7-299	An intermediate BSS that receives an IAM from a preceding network 			shall be capable of including or not including the received optional IAM 			parameters (Calling Party Number, AESA for Calling Party Number, AAL-			parameters, Broadband High Layer Information, Broadband Low Layer 			Information, Calling Party Subaddress and Called Party Subaddress 			parameters) in the outgoing IAM on a per preceding network and on a per 			parameter basis.
	
	(R) 7-300	An intermediate BSS that receives an IAM from a preceding network 			shall be capable of including or not including the received unrecognized 			IAM parameters in the outgoing IAM on a per preceding network basis.

	(R) 7-301	The preceding two requirements shall take precedence over the compatibility 			instructions included in such parameters and the instructions 				notwithstanding, the intermediate BSS may discard an optional parameter, 			an unrecognized parameter, or a parameter with unrecognized value.  In 			other words, the screening (policing) functions specified in the preceding 			requirements shall take precedence over compatibility instructions.

The following requirements monitor timer expirations and make counts needed for traffic engineering (i.e., sizing).  

	(R) 7-302	For each OPC/DPC signaling relationship, the BSS shall count the number 			of BISUP messages for which the timer expired.

The following counts are needed for traffic engineering. These are analogous to "Peg Count" and "Overflow" counts made in narrowband networks. 

Note that in the following requirements, the term "call/connection attempts" applies not only to attempts to establish a point-to-point call/connection, but also attempts to establish point-to-multipoint call/connections and add leaves to them.

	(R) 7-303	For each OPC/DPC signaling relationship, the BSS shall count, for each 			ATM layer service category (e.g., CBR, VBR) and for each supported cell 			rate category (e.g., 173 cells/sec, or 0-500 cells/sec), the following:

•	Total (i.e., successful plus unsuccessful) call/connection attempts made by  the BSS. (Note that an attempt may result in the BSS sending a connection request message (e.g., IAM), or it might not.)

•	Call/connection attempts made by the BSS that are rejected due to resource unavailability.  This is the sum of:

				1.	Call/connection requests rejected by the BSS in cases where 					the BSS rejects the call without sending an IAM to the next 					BSS, plus 

	2.	The number of call/connection requests where the "remote" 	BSS rejects calls/connections due to resource unavailability.  	This case is indicated by receiving one of the following 	cause codes from the remote BSS:
					- Cause Code 47: resource unavailable, unspecified;
					- Cause Code 51: cell rate not available;
					- Cause Code 34: no VPCI/VCI available.

	(R) 7-304	For each OPC/DPC signaling relationship, the BSS shall count, for each 			ATM layer service category and for each supported cell rate category, the 			number of call/connection requests rejected by the BSS where the BSS 			sends an IAR indicating resources/ identifiers unavailability (i.e., having a 			cause code of 47, 51, or 34).

The precise definitions of "service category" and "cell rate category" are not specified at this time. Different administrations may decide to define these categories differently.

It is desirable to have a measure of traffic usage of a VPCI. 

 	(O) 7-3	For each VPCI, the BSS should periodically record the total Peak Cell Rate 			allocated for active calls/connections, and form an estimate of the average 			usage on the VPCI. For some service categories, other parameters (e.g., 			Sustained Cell Rate) may need to be recorded as well.

The following changes are made in Sections 10.4.1 (Operations for Common Part of the AAL Type 5) of the ATM Forum B-ICI Specification, Version 1.1, September 1994, previously published.

(1)	After (R) 10-13, the following paragraph is added:

		At the receiving endpoint where the AAL Type 5 is processed, the discard of cells due to 	buffer overflow impairs the ability to reconstruct AAL Type 5 PDUs.

(2)	A new Requirement is added:

		(R) 10-13a	Network equipment at a B-ICI terminating the AAL Type 5 Common Part 			shall count occurrences of cell buffer overflow.

		One example of an occurrence of cell buffer overflow is overflow of a single cell. 	However, if this is too complex, a count of "congestion events" as defined for a specific 	equipment implementation may be adequate as an indication that a performance problem 	exists.

The following changes are made in Sections 11.1.4 (Support of SMDS in the European Environment) of the ATM Forum B-ICI Specification, Version 1.1, September 1994, previously published.

(1)	The following text is added at the end of Section 11.1.4:

	The support of SMDS at the B-ICI in European environment, as specified by the 	applicable requirements in Section 11.2, is compliant to ITU-T Recommendations I.363 	and I.364, and ETSI Standards prETS-300478[66] and prETS-300479[67].

(2)	The following references are added to the list of REFERENCES:

	66.	ETSI prETS-300478, CBDS Over ATM, Framework and Protocol Specification at 		the UNI, Version 10/94.

	67.	ETSI prETS-300479, CBDS Over ATM, NNI Protocol Specification, Version 		10/94.

(3)	At the end of first line of the last paragraph of Section 11.1.4, the reference number [64] is 	added.

The following changes are made in Sections 11.2.3 (ICIP_CLS Layer Specification) of the ATM Forum B-ICI Specification, Version 1.1, September 1994, previously published.

The following changes are made to the "Bridging Field" related Requirements:

(1)	Replace (R) 11-43 [B-ICI Specification, Version 1.1, September, 1994] OR (R)-195 [B-	ICI Specification, Version 1.0,  August, 1993] with:

	(R) 11-43	When an ICIP_CLS layer entity encapsulates a SIP L3_PDU or a SIP 			CLS_PDU, it shall fill the 2-octet "Bridging" field with 0.

	The following is added:

	(R) 11-43a	Equipment supporting the distributed database approach defined in ITU 			Recommendation I.364 shall set the "Bridging" field to 0 when sending an 			ICIP_CLS packet across a B-ICI for an ATM Forum B-ICI Specification 			Version 1.1 compliant equipment.

(2)	Delete (R) 11-56 [B-ICI Specification, Version 1.1, September, 1994] OR (R)-208 [B-ICI 	Specification, Version 1.0,  August, 1993] 

See the ATM Forum B-ICI Specification, Version 1.1, September 1994.

See the ATM Forum B-ICI Specification, Version 1.1, September 1994. The following modifications and additions apply.

1.	The second paragraph of (R) 12-17 is modified as follows:

	"The interval elapsed time shall be settable in 1-hour increments. The minimum interval 	elapsed time shall be 1-hour and the maximum shall be 24 hours. The default interval 	elapsed time shall be 1 hour. The recording interval elapsed time is set independently for 	different intervals."

2.	The following is added to Section 12.2.2 - "Recording Interval", after (R) 12-17:

Although the above hourly recording intervals are sufficient for many needs, more granular counts are necessary for specific applications.

	(R) 12-17a	The generation functionality shall be settable so that the carrier can specify 			15-minute recording intervals for a limited number of simultaneous ATM 			PVCs.

3.	The following is added to Section 12.2.2.1 - "Scheduled Closings":

	(R) 12-17b	The generation functionality shall assemble a usage record and forward it to 			the formatting functionality only if one or more of the cell counts in it has a 			non-zero value. 

The above requirement specifically applies to assembled usage records. It does not apply to cell counts that are transferred between functions or systems prior to the assembly of a usage record. Whether such transfers include zero cell counts is beyond the scope of this specification.”

4.	The following is added to Section 12.2.4 - "Usage Information Integrity":

	(R) 12-23a	A single failure or error for any component that supports the generation 			functionality shall not cause a loss of usage measurement data (including 			cell counts) that are 15 minutes old or more.

The above requirement is based on the guiding principle that the loss of usage measurement data be minimized. Additional carrier-specific requirements related to the loss of partial or complete usage records may also apply.

5.	The definition specified by (R) 12-3 (for the Recording Interface), is  changed to “15 	decimal digits” from “16 decimal digits.” 

The definition specified by (R) 12-24 (for the Remote Interface) and (R) 12-26 (for the Frame Relay Interface Identifier) is changed to "15 decimal digits" from "16 decimal digits".

In Section 7, Figure 7.6 illustrates an example of the reference configuration for B-ICIs supporting SVC service. As illustrated below in Figure 12.8, this example configuration contains one Originating Carrier, one or more Transit Carriers, and one Terminating Carrier. [Note - Figure 12.1 to 12.7 can be found in the ATM Forum B-ICI Specification, Version 1.1, September 1994].

In order to support Inter Carrier SVC services, each carrier will need to provide usage measurement capabilities.

This section proposes usage measurement capabilities that apply to the Originating Carrier Network. The following requirements apply to an Originating Carrier Network for Point-to-Point Inter Carrier Switched Virtual Connections (SVCs). [Note - (R) 12-1 to (R) 12-32 can be found in the ATM Forum B-ICI Specification, Version 1.1, September 1994].

(R) 12-33	For Inter Carrier SVCs, the Originating Carrier Network shall be capable of 	recording the Calling Party associated with the SVC. The Calling Party is 	the Address Digits from the Calling Party Number parameter from the IAM 	associated with the SVC, plus the AESA for Calling Party parameter, if 	present.

(R) 12-33a	In North American Networks, for Inter Carrier SVCs, the Originating 	Carrier Network shall be capable of recording the Charge Number 	associated with the SVC. The Charge Number is the Address Digits from 	the Charge Number parameter (when present) from the IAM associated with 	the SVC.

(R) 12-33b	For Inter Carrier SVCs, the Originating Carrier Network shall be capable of 	recording the Default Address associated with the SVC. This requirement 	applies when usage information is generated by the Originating ATM 	Switch in the Originating Carrier Network.

	(R) 12-34	For Inter Carrier SVCs, the Originating Carrier Network shall be capable of 			recording the Terminating Address for the SVC. The Terminating Address 			is the Address Digits from the Called Party Number Parameter from the 			IAM associated with the SVC, plus the AESA for Called Party parameter, if 			present.

	(R) 12-35	For Inter Carrier SVCs, the Originating Carrier Network shall be capable of 			recording the following subfields in the Broadband Bearer Capability 			Parameter from the IAM associated with the SVC:

		•	Bearer Class,
		•	Traffic Type,
		•	Timing Requirements,
		•	Susceptibility to Clipping, and
		•	User Plane Connection Configuration.

	(R) 12-36	For Inter Carrier SVCs, the Originating Carrier Network shall be capable of 			recording the QOS Class Forward and QOS Class Backward subfields 			(when present) in the Quality of Service Parameter from the IAM associated 			with the SVC.

	(R) 12-37	For Inter Carrier SVCs, the Originating Carrier Network shall be capable of 			recording the following indicators from the corresponding subfields (when 			present) in the ATM Cell Rate Parameter from the IAM associated with the 			SVC:

		•	Best Effort Indication,
		•	Tagging Forward, and
		•	Tagging Backward.

	(R) 12-38	For Inter Carrier SVCs, the Originating Carrier Network shall be capable of 			recording the following traffic parameters from the corresponding subfields 			(when present) in the ATM Cell Rate Parameter from the IAM associated 			with the SVC:

		•	Forward Peak Cell Rate (CLP = 0+1)
		•	Forward Peak Cell Rate (CLP = 0)
		•	Forward Sustainable Cell Rate (CLP = 0+1)
		•	Forward Sustainable Cell Rate (CLP = 0)
		•	Forward Maximum Burst Size (CLP = 0+1)
		•	Forward Maximum Burst Size (CLP = 0)

	(R) 12-39	For Inter Carrier SVCs, the Originating Carrier Network shall be capable of 			recording the following traffic parameters from the corresponding subfields 			(when present) in the ATM Cell Rate Parameter from the IAM associated 			with the SVC:

		•	Backward Peak Cell Rate (CLP = 0+1)
		•	Backward Peak Cell Rate (CLP = 0)
		•	Backward Sustainable Cell Rate (CLP = 0+1)
		•	Backward Sustainable Cell Rate (CLP = 0)
		•	Backward Maximum Burst Size (CLP = 0+1)
		•	Backward Maximum Burst Size (CLP = 0)

	(R) 12-40	In North American networks, for Inter Carrier SVCs, the Originating 			Carrier Network shall be capable of recording Originating Line Information 			Parameter (OLIP) from the IAM associated with the SVC (when present).

	(R) 12-41	In North American networks, for Inter Carrier SVCs, the Originating 			Carrier Network shall be capable of recording the Carrier Identification 			Code corresponding to the Transit Carrier Network from the Transit 			Network Selection Parameter from the IAM associated with the SVC.

Note that if multiple Transit Carrier Networks transport the inter carrier SVC, more than one Transit Carrier Identifiers may be needed.  This issue is for further study.

	(R) 12-42	In North American networks, for Inter Carrier SVCs, the Originating 			Carrier Network shall be capable of recording the Outgoing Facility 			Identifier for the SVC.  

The Outgoing Facility Identifier for the SVC includes the Signaling Point Code of the Intermediate ATM Switch in the Transit Carrier Network and the VPCI which transports the ATM SVC between the Originating and Transit Carrier Networks.

At the Originating ATM Switch in the Originating Carrier Network, the Outgoing Facility Identifier is recorded from the EXM associated with the SVC. At the Intermediate ATM Switch in the Originating Carrier Network, the Outgoing Facility Identifier is determined by the ATM Switch from internal processes.

	(R) 12-43	For Inter Carrier SVCs, the Originating Carrier Network shall be capable of 			recording the duration of the ATM SVC.

The duration may be described by a start date, start time, and elapsed time. The elapsed time represents the amount of time between a defined start time and the disconnect of the SVC. Two start times are relevant for Inter Carrier SVCs: Carrier Connect Time and Connect Time. The Carrier Connect Time is the time that the SVC is recognized by the originating network as connected to the transit network. The Connect Time is the time that the SVC is recognized by the originating network as connected end-to-end between the calling and called party. 

	(R) 12-44	For Inter Carrier SVCs, the Originating Carrier Network shall be capable of 			recording cell counts as needed.

See Section 12 of the B-ICI Specification, Version 1.1 for a description of cell counting functionality for ATM Permanent Virtual Connections (PVCs). This functionality may be used to generate cell counts for ATM SVCs.

	(R) 12-45	For Inter Carrier SVCs, the Originating Carrier Network shall be capable of 			recording the Cause Value subfield from the Cause Indicators Parameter 			from the RELEASE or RELEASE COMPLETE messages associated with 			the SVC.

The potential usage measurement recording locations in the Originating Carrier Network are illustrated in Figure 12.9.

In this figure, note that the Charge Number Parameter and OLIP might not be included in the usage information. The Charge Number Parameter is included in the usage information only if the Charge Number Parameter is present in the IAM associated with the SVC. The OLIP is included in the usage information only if OLIP is present in the IAM associated with the SVC. 

The Charge Number, OLIP, and Carrier Identification Code are indicated by (*) because the Charge Number parameter, OLIP, and TNS parameters apply to North American networks only.

The Quality of Service (QOS) Parameter is indicated by (**) because the current Version of BISUP does not support this Parameter.

The objective is that all usage information generated by the Originating Carrier Network for an Inter Carrier SVC be assembled as a single usage record and made available to the formatting functionality.  Procedures to assemble usage information from the Originating and Intermediate ATM Switches require further study. 

Procedures to control the generation of usage information for Inter Carrier SVCs require further study.

Additional carrier-specific data elements may also be included in the usage information.

This section proposes usage measurement capabilities that apply to the Terminating Carrier Network. The following requirements apply to a Terminating Carrier Network for Point-to-Point Inter Carrier Switched Virtual Connections (SVCs).

(R) 12-46	For Inter Carrier SVCs, the Terminating Carrier Network shall be capable 	of recording the Calling Party associated with the SVC.  The Calling Party 	is the Address Digits from the Calling Party Number parameter (when 	present) from the IAM associated with the SVC, plus the AESA for Calling 	Party, if present.

(R) 12-46a	In North American Networks, for Inter Carrier SVCs, the Terminating 	Carrier Network shall be capable of recording the Charge Number 	associated with the SVC.  The Charge Number is the Address Digits from 	the Charge Number parameter (when present) from the IAM associated with 	the SVC.

Note that Charge Number Parameter and/or Calling Party Number might not be provided to the Terminating Carrier Network.  The above requirements apply only if these Parameters are included in the IAM provided to the Terminating Carrier Network.

	(R) 12-47	For Inter Carrier SVCs, the Terminating Carrier Network shall be capable 			of recording the Terminating Address for the SVC.  The Terminating 			Address is the Address Digits from the Called Party Number parameter			from the IAM associated with the SVC, plus the AESA for Called Party 			parameter, if present.

	(R) 12-48	For Inter Carrier SVCs, the Terminating Carrier Network shall be capable 			of recording the following subfields in the Broadband Bearer Capability 			Parameter from the IAM associated with the SVC:

		•	Bearer Class,
		•	Traffic Type,
		•	Timing Requirements,
		•	Susceptibility to Clipping, and
		•	User Plane Connection Configuration.

	(R) 12-49	For Inter Carrier SVCs, the Terminating Carrier Network shall be capable 			of recording the QoS Class Forward and QoS Class Backward subfields 			(when present) in the Quality of Service Parameter from the IAM associated 			with the SVC.

	(R) 12-50	For Inter Carrier SVCs, the Terminating Carrier Network shall be capable 			of recording the following indicators from the corresponding subfields 			(when present) in the ATM Cell Rate Parameter from the IAM associated 			with the SVC:

		•	Best Effort Indication,
		•	Tagging Forward, and
		•	Tagging Backward.

	(R) 12-51	For Inter Carrier SVCs, the Terminating Carrier Network shall be capable 			of recording the following traffic parameters from the corresponding 			subfields (when present) in the ATM Cell Rate Parameter from the IAM 			associated with the SVC:

		•	Forward Peak Cell Rate (CLP = 0+1)
		•	Forward Peak Cell Rate (CLP = 0)
		•	Forward Sustainable Cell Rate (CLP = 0+1)
		•	Forward Sustainable Cell Rate (CLP = 0)
		•	Forward Maximum Burst Size (CLP = 0+1)
		•	Forward Maximum Burst Size (CLP = 0)

	(R) 12-52	For Inter Carrier SVCs, the Terminating Carrier Network shall be capable 			of recording the following traffic parameters from the corresponding 			subfields (when present) in the ATM Cell Rate Parameter from the IAM 			associated with the SVC:

		•	Backward Peak Cell Rate (CLP = 0+1)
		•	Backward Peak Cell Rate (CLP = 0)
		•	Backward Sustainable Cell Rate (CLP = 0+1)
		•	Backward Sustainable Cell Rate (CLP = 0)
		•	Backward Maximum Burst Size (CLP = 0+1)
		•	Backward Maximum Burst Size (CLP = 0)

	(R) 12-53	In North American networks, for Inter Carrier SVCs, the Terminating 			Carrier Network shall be capable of recording Originating Line Information 			Parameter (OLIP) from the IAM associated with the SVC (when present).

Note that the Originating Line Information Parameter (OLIP) might not be provided to the Terminating Carrier Network.  The above requirement applies only if this Parameter is included in the IAM provided to the Terminating Carrier Network.

	(R) 12-54	In North American networks, for Inter Carrier SVCs, the Terminating 			Carrier Network shall be capable of recording the Carrier Identification 			Code corresponding to the Transit Carrier Network.

Note that if multiple Transit Carrier Networks transport the inter carrier SVC, more than one Transit Carrier Identifiers may be needed. This issue is for further study. 

At the Intermediate ATM Switch in the Terminating Carrier Network, the Carrier Identification Code is associated with the B-ICI.  Determining the Carrier Identification Code at the Terminating ATM Switch in the Terminating Carrier Network requires further study.

	(R) 12-55	In North American networks, for Inter Carrier SVCs, the Terminating 			Carrier Network shall be capable of recording the Incoming Facility 			Identifier for the SVC. 

The Incoming Facility Identifier for the SVC includes the Signaling Point Code of the Intermediate ATM Switch in the Transit Carrier Network and the VPCI which transports the ATM SVC between the Transit and Terminating Carrier Networks.

At the Intermediate ATM Switch in the Terminating Carrier Network, the Incoming Facility Identifier is determined by the ATM Switch from internal processes.  Determining the Incoming Facility Identifier at the Terminating ATM Switch in the Terminating Carrier Network requires further study.

	(R) 12-56	For Inter Carrier SVCs, the Terminating Carrier Network shall be capable 			of recording the duration of the ATM SVC.

The duration may be described by a start date, start time, and elapsed time. The elapsed time represents the amount of time between a defined start time and the disconnect of the SVC. Two start times are relevant for Inter Carrier SVCs:  Carrier Connect Time and Connect Time. The Carrier Connect Time is the time that the SVC is recognized by the terminating network as connected to the transit network. The Connect Time is the time that the SVC is recognized by the terminating network as connected end-to-end between the calling and called party.

	(R) 12-57	For Inter Carrier SVCs, the Terminating Carrier Network shall be capable 			of recording cell counts as needed.

See Section 12 of the B-ICI Specification, Version 1.1 for a description of cell counting functionality for ATM Permanent Virtual Connections (PVCs). This functionality may be used to generate cell counts for ATM SVCs.  

	(R) 12-58	For Inter Carrier SVCs, the Terminating Carrier Network shall be capable 			of recording the Cause Value subfield from the Cause Indicators Parameter 			from the RELEASE or RELEASE COMPLETE messages associated with 			the SVC.

The potential usage measurement recording locations in the Terminating Carrier Network are illustrated in Figure 12.10.

In this figure, note that three data elements might not be available in the Terminating Carrier Network. These data elements are the Charge Number, Calling Party, and OLIP. 

The Charge Number and OLIP are indicated by (*) because the Charge Number Parameter and OLIP apply to North American networks only.

The Quality of Service Parameter is indicated by (**) because the current version of BISUP does not support this parameter.

The objective is that all usage information generated by the Terminating Carrier Network for an Inter Carrier SVC be assembled as a single usage record and made available to the formatting functionality.  Procedures to assemble usage information from the Terminating and Intermediate ATM Switches require further study.  

Procedures to control the generation of usage information for Inter Carrier SVCs require further study.

Additional carrier-specific data elements may also be included in the usage information.

The usage measurement capabilities for inter network SVCs are specified for the Originating Carrier Network in Section 12.4.1 and for the Terminating Carrier Network in Section 12.4.2.  These capabilities also apply to Point-to-Multipoint SVCs. An example Point-to-Multipoint SVC is illustrated in Figure 12.11.

This Point-to-Multipoint SVC includes one root and three leaves. For usage measurement purposes, this Point-to-Multipoint SVC provides three communication paths. A communication path is defined between the root and a leaf.  The three communication paths provided by the above Point-to-Multipoint SVC are as follows:
•	a communication path from the Root to Leaf 1
•	a communication path from the Root to Leaf 2
•	a communication path from the Root to Leaf 3

Note that these communication paths share connection links at different points within the networks.  For instance, all three communication paths use the same user plane connection link (i.e., the same VPCI/VCI) at the UNI between the Root and the Originating Carrier Network.

Usage information is collected for each communication path. The ATM switches are capable of recording the specified usage measurement data elements for the communication paths they support. These data elements should indicate that the communications path is part of a Point-to-Multipoint SVC. For instance, the User Plane Connection Configuration in the Broadband Bearer Capability Parameter from the IAM should indicate "Point-to-Multipoint". The usage information generated for the above Point-to-Multipoint SVC is illustrated in Figures 12.12 and 12.13. 

Figure 12.12 illustrates the Originating Carrier Network. 

Figure 12.13 illustrates the Terminating Carrier Network. 

As illustrated in these figures, each network is capable of generating usage information for the listed communication paths.

Originating ATM Switch in the Originating Carrier Network:
•	the communication path from the Root to Leaf 1
•	the communication path from the Root to Leaf 2
•	the communication path from the Root to Leaf 3

Intermediate ATM Switch in the Originating Carrier Network:
•	the communication path from the Root to Leaf 2
•	the communication path from the Root to Leaf 3

Intermediate ATM Switch in the Terminating Carrier Network:
•	the communication path from the Root to Leaf 2
•	the communication path from the Root to Leaf 3

Terminating ATM Switch in the Terminating Carrier Network:
•	the communication path from the Root to Leaf 3

The usage information generated for the communication paths will have many common data elements. For instance, the following usage measurement data elements are the same for all communication paths provided by the Point-to-Multipoint SVC:
•	Broadband Bearer Capability
•	Quality of Service Class (when present)
•	ATM Cell Rate Parameters

The following usage measurement data elements may vary (i.e., may be different for each communication path provided by the Point-to-Multipoint SVC):
•	Calling Party (when present)
•	Terminating Address
•	Cause Value
•	Carrier Identification Code
•	Facility Identifiers (Incoming and Outgoing)
•	OLIP (when present)
•	Charge Number (when present)
•	Connect Time
•	Carrier Connect Time
•	Cell Counts

The usage measurement data elements collected for the Point-to-Multipoint SVC may be formatted as one or more usage records by each ATM switch that generates usage measurement data. Data formatting is beyond the scope of this specification.  

AAL			ATM Adaptation Layer
ACM			Address Complete Message 
AESA			ATM End System Address
Ai			Signaling ID Assigned by Switch A
ANI			Automatic Number Identification
ANM			Answer Message 
ATM			Asynchronous Transfer Mode
BBC			Broadband Bearer Capability 
BCOB		Broadband Connection Oriented Bearer 
BHLI			Broadband High Layer Information
Bi			Signaling ID assigned by Switch B
BLA			Blocking Acknowledgment Message
BLLI			Broadband Low Layer Information
BLO			Blocking Message 
BSS			Broadband Switching System
CBDS			Connectionless Broadband Data Service
CCE			Consistency Check End Message 
CCEA			Consistency Check End Acknowledge Message 
CCR			Consistency Check Request Message 
CCRA		Consistency Check Request Acknowledge Message
CdPN			Called Party Number 
CFN			Confusion Message
CgPN			Calling Party Number 
CIP			Carrier Identification Parameter 
CPG			Call Progress Message 
CSI			Carrier Selection Information
CS-2			Capability Set 2
CS-2.1		Capability Set 2, Step 1
DCC			Data Country Code
DCLI			Destination Connection Link Identifier
DSID			Destination Signaling Identifier 
EXM			Exit Message 
IAA			IAM Acknowledgment Message 
IAM			Initial Address Message 
IAR			IAM Reject Message 
ICD			International Code Designator
IE			Information Element 
ILEC			Independent Local Exchange Carrier
INC			International Carrier
IEC			Inter Exchange Carrier
LEC			Local Exchange Carrier
OCLI			Origination Connection Link Identifier
OFI			Outgoing Facility Identifier
OLI			Originating Line Information 
OSID			Origination Signaling Identifier 
QoS			Quality of Service 
RAM			Reset Acknowledgment Message
REL			Release Message
RLC			Release Complete Message 
RSM			Reset Message
SAAL			Signaling ATM Adaptation Layer
SID			Signaling Identifier
SSCF			Service Specific Coordination Function
SSCOP		Service Specific Connection Oriented Protocol
TNS			Transit Network Selection
UBA			Unblocking Acknowledgment Message 
UBL			Unblocking Message
UPA			User Part Available Message
UPT			User Part Test Message
VCI			Virtual Channel Identifier 
VPCI			Virtual Path Connection Identifier

1-24, 26 and 29-65.	See B-ICI Specification, Version 1.1, September 1994.

25.	ITU-T Recommendation, I.610, B-ISDN Operation and Maintenance Principles and 	Functions, July 1995.

27.	GR-1248-CORE, Generic requirements for Operations of ATM Network Elements, 	Bellcore, Issue 2, September 1995. 

28.	(B-ICI Specification, V 1.1's Reference 28 is replaced by the current Reference 25 above).

66.	ETSI prETS-300478, CBDS Over ATM, Framework and Protocol Specification at 	the UNI, Version 10/94.

67.	ETSI prETS-300479, CBDS Over ATM, NNI Protocol Specification, Version 		10/94.

68.	ITU-T Recommendations, Q.701-Q.710, Message Transfer Part  (MTP), 1992.

69.	ITU-T Recommendation, Q.2761, BISDN, BISDN User Part - Functional 	Description, October 1994. 

70.	ITU-T Recommendation, Q.2762, BISDN, BISDN User Part - General Functions 	of Messages and Signals, October 1994.

71.	ITU-T Recommendation, Q.2763, BISDN, BISDN User Part  - Formats and Codes, 	October 1994.

72.	ITU-T Recommendation, Q.2764, BISDN, BISDN User Part - Basic Call 	Procedures, October 1994.

73.	ITU-T Recommendation, Q.2610, BISDN - Usage of Cause and Location in BISDN 	User Part and DSS2, October 1994.

74.	ITU-T Recommendation, Q.2650, Interworking Between the BISDN DSS2  Layer 3 	Protocol and the SS7 BISUP, December 1993.

75.	ITU-T Recommendation, Q.2723, BISDN, BISDN User Part - Support of Additional 	Traffic Parameters, July 1995.

76.	ITU-T Draft Recommendation Q.2210,  Message Transfer Part Level 3 Functions and 	Messages Using the Services of ITU-T Recommendation Q.2140, May 1995 (TD PL/11-	97).

77.	ITU-T Recommendation Q.2110, B-ISDN ATM Adaptation Layer Service Specific 	Connection Oriented Protocol (SSCOP),

78.	ITU-T Recommendation Q.2140, B-ISDN ATM Adaptation Layer - Service Specific 	Coordination Function for Signaling at the Network Node Interface (SSCF at NNI).

79.	ITU-T Recommendation Q.2144, B-ISDN  ATM Adaptation Layer - Layer Management 	for the SAAL at the NNI.

80.	ITU-T Draft Recommendation, Q.2722.1, BISDN, BISDN User part - Network Node 	Interface Specification for Point-to-Multipoint call/Connection Control, July 1995.

81.	ITU-T Draft Recommendation, Q.2726.1, BISDN, BISDN User Part - ATM End System 	Address for Calling and Called Party, July 1995.

82.	ANSI T1.111-1996, American National Standard for Telecommunications  — Signaling 	System  No. 7 — Message Transfer Part,  American National Standards Institute, New 	York, 1996.

83.	ANSI T1.113-1995, American National Standard for Telecommunications  — Signaling 	System  No. 7 — ISDN User Part,  American National Standards Institute, New York.

84.	ANSI T1.635-1994, American National Standard for Telecommunications  — Broadband 	ISDN — ATM adaptation layer  type 5 common part functions and specification.

85.	ANSI T1.637-1994, American National Standard for Telecommunications  — B-ISDN 	ATM Adaptation Layer — Service Specific Connection Oriented Protocol (SSCOP).

86.	ANSI T1.645-1995, American National Standard for Telecommunications  — B-ISDN 	ATM Adaptation Layer — Service Specific Coordination Function for Support of 	Signaling at the Network Node Interface (SSCF at NNI).

87.	ANSI T1.648-1995, American National Standard for Telecommunications  — Signaling 	System  No. 7 — Broadband ISDN User Part,  American National Standards Institute, 	New York.

88.	ANSI T1.652-1996, American National Standard for Telecommunications  — B-ISDN 	ATM Adaptation Layer — Layer Management for the SAAL at the NNI.

Note:	The current text in the B-ICI Specification, Version 1.1, September 1994 is expected to be 	revised if and when any updated version of the Traffic Management specification is 	available.

In the following table, each parameter is identified as being Mandatory (M), Optional (O), or Not Applicable (no entry) for each message.  Message acronyms (e.g., IAM) are spelled out in full in the Acronyms list.

Table B-1	Parameters of Each Message (Part 1)

Parameter	Mandatory/Optional								
	ACM	ANM	BLA	BLO	CCE	CCEA	CCR	CCRA	
AAL parameters		O							
Additional ATM cell rate									
AESA for called party									
AESA for calling party									
ATM cell rate									
Automatic congestion level									
Broadband bearer capability									
Broadband high layer information									
Broadband low layer information		O							
Called party's indicators	M								
Called party number									
Called party subaddress									
Calling party number									
Calling party subaddress									
Calling party's category									
Carrier identification code									
Cause indicators									
Carrier selection information									
Charge number									
Connection element identifier									
Consistency check result information						M			
Destination connection link identifier									
Destination signaling identifier	M	M	M		M	M		M	
Leaf party type									
Originating line information									
Origination connection link identifier									
Origination signaling identifier				M			M	M	
Outgoing facility identifier									
Quality of service									
Resource identifier				M			M		
Transit network selection 									

Table B-1	Parameters of Each Message (Part 2)

Parameter	Mandatory/Optional								
	CFN	CPG	EXM	IAA	IAM	IAR	RAM	REL	
AAL parameters					O				
Additional ATM cell rate					O				
AESA for called party					O				
AESA for calling party					O				
ATM cell rate					M				
Automatic congestion level						O		O	
Broadband bearer capability					M				
Broadband high layer information					O				
Broadband low layer information					O				
Called party's indicators		O							
Called party number					M				
Called party subaddress					O				
Calling party number					O				
Calling party subaddress					O				
Calling party's category					M				
Carrier identification code					O				
Cause indicators	M					M		M	
Carrier selection information					O				
Charge number					O				
Connection element identifier				O	O				
Consistency check result information									
Destination connection link identifier					Note1			Note3	
Destination signaling identifier	M	M	M	M		M	M	M	
Leaf party type					Note4				
Originating line information					O				
Origination connection link identifier				Note2	Note2				
Origination signaling identifier				M	M				
Outgoing facility identifier			O					O	
Quality of service					M				
Resource identifier									
Transit network selection					O				
Originating ISC point code					O				

Note 1 -	(IAM) This parameter is mandatory for the addition of a new leaf to an existing 		connection. It is not applicable for point-to-point calls. 

Note 2 -	(IAM & IAA) This parameter is mandatory for the establishment of a new 			connection link in a point-to-multipoint call.  It is not applicable for point-to-point 		calls. 

Note 3 -	(REL) This parameter is mandatory for the en-bloc release of call/connection 		requested by the root party in a point-to-multipoint call.  It is not applicable for 		point-to-point calls. 

Note 4 -	(IAM) This parameter is mandatory for point-to-multipoint calls.  It is not applicable 		for point-to-point calls. 

Table B-1	Parameters of Each Message (Part 3)

Parameter	Mandatory/Optional								
	RLC	RSM	UBA	UBL	
AAL parameters					
Additional ATM cell rate					
AESA for called party					
AESA for calling party					
ATM cell rate					
Automatic congestion level					
Broadband bearer capability					
Broadband high layer information					
Broadband low layer information					
Called party's indicators					
Called party number					
Called party subaddress					
Calling party number					
Calling party subaddress					
Calling party's category					
Carrier identification code					
Cause indicators	O				
Carrier selection information					
Charge number					
Connection element identifier					
Consistency check result information					
Destination connection link identifier					
Destination signaling identifier	M		M		
Leaf party type					
Originating line information					
Origination connection link identifier					
Origination signaling identifier		M		M	
Outgoing facility identifier					
Quality of service					
Resource identifier		M		M	
Transit network selection 					

C.1	Introduction

This Appendix identifies issues surrounding the use of the VPCI in signaling for SVC call setup within Permanent Virtual Path Connections.  A sample problem which raised the issues is captured in Figure C1:

Figure C1	Merging Physical Facilities onto a Single Facility

Note:  PF # refers to Physical Facility #.

If BSS1 has a Virtual Path Connection (VPC) over PF 1 and PF 3 to BSS3, and BSS2 has a VPC over PF 2 and PF 3 to BSS3, are the VPs merged over PF 3 into a single VP?  Also, how is signaling for setting up SVCs handled?  If the signaling channel is VPI 0, VCI 5 for both PF 1 and PF 2, are they merged in some way onto VPI 0, VCI 5 on PF 3? The answers can be found in the ATM Forum UNI 3.1, B-ICI Version 2.0 specifications (Section 7.8), and  Bellcore’s GR-1417-CORE, "Broadband Switching System SS7 Requirements Using BISUP SS7 and ATM Protocols for Broadband".

C.2	B-ISUP Signaling Links

There is some misconception in the industry that the signaling channel for a virtual path is always carried over VPCI 0, VCI 5.  In fact, B-ICI signaling uses "signaling links" which can be carried in any VPCI. VCI 5 is reserved for signaling links, and each signaling link shall use this VCI value.  While each VPC shall be able to support a signaling link, the BSS is not required to have a signaling link for each VPC since a signaling link can be used to transport signaling messages associated with multiple VPCs.  

The set of signaling links that directly interconnect two signaling points constitute a "signaling link set". All signaling links in a signaling link set must operate at the same speed.

For the question posed above, signaling from BSS1 and BSS2 is not merged, but is kept in distinct signaling link sets.

Routing of SS7 messages is performed by the MTP layer.  Routing of signaling messages involves selecting an outgoing signaling link from the signaling link set that will efficiently deliver a signaling message to its proper destination node. 

Additional requirements regarding transport of MTP level 3 user messages, support of Message Sequencing procedures, and support of Load Sharing procedures are found in GR-1417-CORE.

Finally, merging VPs into a single VP is not allowed. VPs must be set up on a per switch pair basis (see Figure C2).

C.3	Definition and Use of VPCI/VCI

When a BSS sets up a call to another BSS through a Virtual Path, it is necessary that the Virtual Path be identified by the same value at both BSSs.  Since an ATM VP can pass through an ATM VP Crossconnect and the VP Crossconnect can perform a translation of the VPIs, it is necessary to define another value, called a Virtual Path Connection Identifier (VPCI), which is unambiguous and identical at both ends of a Virtual Path Connection, i.e., is unique for each pair of BSSs (see B-ICI Version 2.0, Section 7.12). If no VP Crossconnect exists between the BSSs, then the VPI and the VPCI can be the same.  

Between the two BSSs each BSS is responsible for assigning bandwidth and the VPI/VCIs for about half of the VPCIs.  For every VPCI it shall be defined which BSS controls the VPCI (i.e., is the assigning switch).  The default mechanism calls for the BSS with the higher signaling point code to be the assigning switch for all even numbered VPCI values, and the other BSS be the assigning switch for all odd numbered VPCI values. 

For an outgoing call/connection, a BSS shall first attempt to use a VPCI which it controls.  If it has a VPCI that satisfies the CAC requirements, the BSS sends an Initial Address Message (IAM) over a signaling channel in the signaling link set.  The IAM will contain the Connection Element Identifier (CEI) parameter which, in turn, contains the VPCI/VCI values to be used.  If the BSS does not have a VPCI which it controls that satisfies the CAC requirements for the call or has run out of VPCI/VCIs, then the BSS sends the IAM without the CEI parameter.  In this case, the far end BSS will be expected to assign a VPCI/VCI from the set of VPCIs it controls.

The VPCI subfield (octets 1 and 2) of the CEI shall contain the VPCI code expressed in pure binary.  Bit 8 of octet 1 is most significant and Bit 1 of octet 2 is least significant.  The VCI sub-field (octets 3 and 4) shall contain the VCI code expressed in pure binary.  Bit 8 of octet 3 is most significant and bit 1 of octet 4 is least significant.  

VCI values 0 to 31 are reserved by the ITU-T and shall not be assigned.  (Refer to Section 2.5.2 of GR-1113-CORE for the usage of VCI values in this reserved range.)

These concepts are illustrated in Figure C2.

Figure C2	Illustration of VPCIs

In this figure, BSS1 has a physical facility to the VP Crossconnect; this facility contains a virtual path with VPI = 1.  In the VP Crossconnect, the cells in this virtual path will have their VPI translated to VPI = 3 before being sent to BSS3.  Also, BSS2 has a physical facility to the VP Crossconnect; this facility contains a virtual path with VPI = 2.  In the VP Crossconnect, cells with this VPI are translated to VPI = 4 before being sent to BSS3 in the same physical facility that carries cells with VPI = 3.  

In order to set up calls, VPCI 8 is assigned for the VPC using VPI 1 and VPI 3 between BSS1 and BSS3, and VPCI 33 is assigned for the VPC using VPI 2 and VPI 4 between BSS2 and BSS3.  Note that in order to have unambiguous VPCIs, the facility that carries VPCI 8 between the cross-connect and BSS3 cannot also have a VPCI 8 as part of a VPC between BSS2 and BSS3.  Similarly for VPCI 33.

Using the default procedure, the assigning switch for VPCI 8 is BSS3 (since the Signaling Point Code for BSS3 is higher than that for BSS1 and the VPCI is even).  The assigning switch for VPCI 33 is also BSS3 (since the Signaling Point Code for BSS3 is smaller than that for BSS2 and the VPCI is odd).  In both cases, the non-assigning switch does not assign but requests the assigning switch to assign both VPCI/VCI and bandwidth.  For example, in the above figure if BSS2 wants to make a VCC to BSS3 but has no VPCI/VCIs available which it controls, it would send an IAM to BSS3 over a signaling link in the signaling link set; this IAM would not contain a CEI parameter.  BSS3 would