Technical Committee

Voice and Telephony Over ATM to the Desktop Specification

AF-VTOA-0083.001

February, 1999

© 1999 by The ATM Forum.  This specification/document may be reproduced and distributed in whole, but (except as provided in the next sentence) not in part, for internal and informational use only and not for commercial distribution.  Notwithstanding the foregoing sentence, any protocol implementation conformance statements (PICS) or implementation conformance statements (ICS) contained in this specification/document may be separately reproduced and distributed provided that it is reproduced and distributed in whole, but not in part, for uses other than commercial distribution.  All other rights reserved.  Except as expressly stated in this notice, no part of this specification/document may be reproduced or transmitted in any form or by any means, or stored in any information storage and retrieval system, without the prior written permission of The ATM Forum.

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.

NOTE:  The user's attention is called to the possibility that implementation of the ATM interoperability specification contained herein may require use of an invention covered by patent rights held by ATM Forum Member companies or others.  By publication of this ATM interoperability specification, no position is taken by The ATM Forum with respect to validity of any patent claims or of any patent rights related thereto or the ability to obtain the license to use such rights.  ATM Forum Member companies agree to grant licenses under the relevant patents they own on reasonable and nondiscriminatory terms and conditions to applicants desiring to obtain such a license.  For additional information contact:

The ATM Forum
Worldwide Headquarters
2570 West El Camino Real, Suite 304
Mountain View, CA 94040-1313
Tel:	+1-650-949-6700
Fax:	+1-650-949-6705

A C K N O W L E D G M E N T S
Preparation of a Specification of this kind requires a concerted effort on the part of many individuals. The following individuals (names listed alphabetically), among others, provided written contributions and devoted valuable time towards the development of this Specification. 
Dave Alley	Tim Andvaag
Jozef Babiarz	Behram Bharucha
Gordon Boot	Jack Cotton
Maurice Duault	John Elwell
Faris Faris	Duncan Greatwood
Jim Harford	Tom Henderson
Brian Holden	Martin Jackson
Takao Kasahara	Takayuki Kobayashi
Costa Kourtis	Gösta Leijonhufvud
Luisa Liffredo	Jeffrey Lynch
Terry Lyons	Karlo Németh
Mike Nilsson	Matt Noah
Bernhard Petri	Larry Roberts
Birgitte Rodger	David Singer
Terry Sterkel	Lee S. Rogers
Dietrich Schlichthaerle	Katie Taaffe
Mike Tisiker	Daniel Upp
Surya Varanas	Georgina Waide
Christian Wipliez	Steven Wright
Ferit Yegenoglu	Joseph Zebarth
François Audet & Sanjay Kumar, Editors of af-vtoa-0083.000
François Audet, Editor of af-vtoa-0083.001
Peter M. Chase, Ex-Chair of ATM Forum SAA/RMOA Working Group
Ameneh Zahir, Chair of ATM Forum SAA/RMOA Working Group
Bahman Mobassser, Chair of ATM Forum SAA Working Group

Contents

1	Introduction	1
1.1	Purpose		1
1.2	Scope		1
1.3	Reference configuration	1
1.4	Service requirements	1
1.5	References	2
1.6	Abbreviations and acronyms	4
2	Definition of native ATM terminal equipment	6
2.1	Functional requirements	6
2.2	Interfaces	6
2.3	Protocol Reference Model	6
2.4	User plane	6
2.5	Control plane	7
2.6	Management plane	9
3	Interworking Function	9
3.1	Functional requirements	9
3.2	Interfaces and protocols	9
3.3	User plane	9
3.4	Control plane	9
3.5	Management plane	9
3.7	PNNI Routing Protocol	9
4	Timing and synchronisation	9
4.1 Timing distribution mechanisms	9
4.2	IWF requirements	9
4.3	B-TE requirements	9
5	Delay and echo	9
6	Addressing	9
Appendix A - Echo Cancellation in N-ISDN	9
Appendix B - Interworking between AAL1 and AAL5	9
Appendix C - Interworking with H.320/H.321 terminals	9
Appendix D - Required incremental subset of UNI Signalling 4.0 from UNI 3.1	9
D.1	Notification procedures	9
D.2	Notification of interworking procedures (Progress)	9
D.3	AAL negotiation	9
D.4	Call/connection alerting	9
D.5	Narrowband bearer capability information element	9
D.6	Narrowband high layer compatibility information element	9
D.7	Narrowband low layer compatibility information element	9
D.8	UNI Signalling 4.0 supplementary services	9
Appendix E - Protocol Implementation Conformance Statement (PICS) Proforma	9
E.1	Introduction	9
E.2	Identification of the Implementation	9
E.3	PICS Proforma for af-vtoa-0083.001	9
Appendix F - Summary of changes between af-vtoa-0083.000 and af-vtoa-0083.001	9

1	Introduction
1.1	Purpose
This document specifies the ATM Forum’s interoperability agreement for supporting voice and telephony over ATM to the desktop. It complies with the Forum’s other interoperability agreements.
1.2	Scope
This document specifies the particular features required to provide voice and telephony service in B-ISDN. It describes the functions to be performed by a native ATM terminal and an Interworking Function (IWF) to provide service between B-ISDN attached terminals and/or N-ISDN attached terminals, be they public or private. This document specifies the particular features required to support signalling interworking between B-ISDN and N-ISDN. The requirements for support of UNI SIG 4.0 supplementary services are also described.
This document applies to the transport of a single 64 kbit/s A-law or µ-law (ITU-T Recommendation G.711) voiceband signal. Alternative coding for voice transport (e.g., high quality voice, compressed voice) and silence removal are outside the scope of this specification.
Only the signalling interworking with a N-ISDN and at a Q.SIG (PSS1) interfaces are covered. This document is based on PNNI 1.0, UNI SIG 4.0, ITU-T Recommendation I.580 on N-ISDN interworking and ITU-T Recommendations Q.2931, Q.2951 and Q.2957 on DSS2 signalling. This document covers the interworking scenario where a user on a B-ISDN is accessing N-ISDN services offered by a N-ISDN, through an Interworking Function (IWF).
Three types of attachment are considered in this specification:
	- B-TE to Private or Public B-ISDN,
	- Private B-ISDN to Public N-ISDN,
	- Private B-ISDN to Private N-ISDN.
1.3	Reference configuration

Figure 1-1 Reference configuration
The interworking between a Public B-ISDN and a Public N-ISDN, including the B-ISUP and the N-ISUP protocols, is outside the scope of this specification.
The signalling between a public B-ISDN and a private B-ISDN is specified in UNI SIG 4.0.
1.4	Service requirements
The service requirements for N-ISDN service are described in ITU-T Recommendation I.231 for the circuit mode bearer service and in I.251 and I.257 for the supplementary services supported in this specification.
1.5	References
1.5.1	Normative
ATM Forum Technical Committee, af-pnni-0055.000, Private Network-Network Interface Specification Version 1.0 (PNNI 1.0), March 1996
ATM Forum Technical Committee, af-sig-0061.000, ATM User-Network Interface (UNI) Signalling Specification Version 4.0, June 1996
ATM Forum Technical Committee, af-ilmi-0065.000, Integrated Local Management Interface (ILMI) Specification Version 4.0, July 1996
ATM Forum/af-ra-0106.000, ATM Forum Addressing: Reference Guide, January 1999
ISO/IEC 9646-1: 1990, Information technology - Open systems interconnection - Conformance testing methodology and framework - Part 1: General concepts (See also ITU-T Recommendation X.290 (1991))
ISO/IEC 9646-2: 1990, Information technology - Open systems interconnection - Conformance testing methodology and framework - Part 2: Abstract test suite specification (See also ITU-T Recommendation X.291 (1991))
ISO/IEC 11572:1994, Information technology - Telecommunications and information exchange between systems - Private Integrated Services Network - Circuit mode bearer services - Inter-exchange signalling procedures and protocol
ITU-T G.711-1988, Pulse code modulation (PCM) of voice frequencies
ITU-T I.150-1993, Asynchronous Transfer Mode Functional Characteristics
ITU-T I.356-1993, Integrated Services Digital Network (ISDN); Overall network aspects and functions; B-ISDN ATM layer cell transfer performance
ITU-T I.363.1-1996, B-ISDN ATM Adaptation Layer (AAL) Specification, Types 1 and 2
ITU-T I.363.5-1996, B-ISDN ATM Adaptation Layer (AAL) Specification, Type 5 
ITU-T I.430-1993, Integrated Services Digital Network (ISDN); ISDN user-network interfaces; Basic rate user-network interface; Layer 1 specifications
ITU-T I.431-1993, Integrated Services Digital Network (ISDN); ISDN user-network interfaces; Primary rate user-network interface; Layer 1 specifications
ITU-T Q.921-1993, ISDN User-Network Interface; Data link layer specification
ITU-T Q.931-1993, Digital Subscriber Signalling System No. 1 (DSS1); ISDN User-Network Interface Layer 3 Specification for Basic Call Control
ITU-T Q.951-1992, Stage 3 Description for Number Identification Supplementary Services using DSS1, clauses 1, 2, 8
ITU-T Q.951-1993, Stage 3 Description for Number Identification Supplementary Services using DSS1, clauses 3, 4, 5, 6
ITU-T Q.957-1993, Stage 3 Description for Additional Information Transfer Supplementary Services using DSS1), clause 1
ITU-T Q.2931-1995, Broadband Integrated Services Digital Network (B-ISDN); Digital Subscriber Signalling System No. 2 (DSS2); User-Network Interface (UNI) Layer 3 Specification for Basic Call/Connection Control
ITU-T Q.2951-1995, Stage 3 Description for Number Identification Supplementary Services using B-ISDN Digital Subscriber Signalling System No. 2 (DSS2) - Basic Call
ITU-T Q.2957-1995, Stage 3 Description for Additional Information Transfer Supplementary Services using B-ISDN Digital Subscriber Signalling System No. 2 (DSS2) - Basic Call
1.5.2	Informative
ANSI T1.101-1994, Synchronization Interface Standard
ANSI T1.508-1992, Network Performance-Loss Plan for Evolving Digital Networks
ANSI Technical Report No. 27, A Technical report on Echo Cancellers, T1A1.6 Working Group, November 1993
Bellcore TR-NWT-001244, Clocks for the synchronized Network: Common Generic Clock Criteria
ISO/IEC 11571:1994, Information technology - Telecommunications and information exchange between systems - Numbering and subaddressing in Private Integrated Services Networks
ISO/IEC 11579-1:1994, Information technology - Telecommunications and information exchange between systems - Reference configuration for Private Integrated Services Networking (PISN) exchanges
ITU-T G.131-1996, Control of talker echo
ITU-T G.164-1988, Echo suppressors
ITU-T G.165-1993, Echo cancellers
ITU-T G.176-1997, Planning guidelines for the integration of ATM technology into the PSTN
ITU-T G.811-1988, Timing requirements at the outputs of primary reference clocks suitable for plesiochronous operation of international digital links
ITU-T I.231-1988, Circuit-mode bearer service categories
ITU-T I.251.1 (rev. 1)-1992, Integrated Services Digital Network (ISDN) - General structure and service capabilities - Direct-Dialling-In
ITU-T I.251.2 (rev. 1)-1992, Integrated Services Digital Network (ISDN) - General structure and service capabilities - Multiple Subscriber Number
ITU-T I.251.3 (rev. 1)-1992, Integrated Services Digital Network (ISDN) - General structure and service capabilities - Calling Line Identification Presentation
ITU-T I.251.4 (rev. 1)-1992, Integrated Services Digital Network (ISDN) - General structure and service capabilities - Calling Line Identification Restriction
ITU-T I.251.5-1995, Integrated Services Digital Network (ISDN) - Service capabilities - Connected Line Identification Presentation
ITU-T I.251.6-1995, Integrated Services Digital Network (ISDN) - Service capabilities - Connected Line Identification Restriction
ITU-T I.251.8 (rev. 1)-1992, Integrated Services Digital Network (ISDN) - General structure and service capabilities - Sub-addressing supplementary service
ITU-T I.257.1-1995, Integrated Services Digital Network (ISDN) - Service capabilities - User-User Signalling (UUS)
ITU-T I.411-1993, Integrated Services Digital Network (ISDN); ISDN user-network interfaces; ISDN user-network interface - Reference configuration
ITU-T I.413-1993, Integrated Services Digital Network (ISDN); ISDN user-network interfaces; B-ISDN user-network interface
ITU-T I.580-1995, General Arrangements for Interworking Between B-ISDN and 64 kbit/s Based ISDN
ITU-T P.310-1996, Transmission characteristics for telephone band (300-3400 Hz) digital telephones
ITU-T Q.2932-1996, Broadband Integrated Services Digital Network (B-ISDN); Digital Subscriber Signalling System No. 2 (DSS2); Generic Functional Protocol - Core functions
ITU-T X.213-1995 | ISO/IEC 8348:1996, Information technology - Open systems interconnection - Network service definition
1.6	Abbreviations and acronyms
AAL	ATM Adaptation Layer
B-ISDN	Broadband ISDN
B-ISUP	Broadband ISDN User Part
B-TE	Broadband Terminal Equipment
CDV	Cell Delay Variation
CRC	Cyclic Redundancy Check
CS	Convergence Sublayer
CSI	Convergence Sublayer Information
DCC	Data Country Code
DSS1	Digital Subscriber Signalling System #1
DSS2	Digital Subscriber Signalling System #2
GF	Generic Functional Protocol
ICD	International Code Designator
ILMI	Integrated Local Management Interface
ISDN	Integrated Services Digital Network
ISO	International Organization for Standardization
ITU-T	International Telecommunication Union - Telecommunication Standardization Sector
IWF	Interworking Function
LLC	Low Layer Capability
MIB	Management Information Base
NSAP	Network Service Access Point
N–BC	Narrowband Bearer Capability
N-ISDN	Narrowband ISDN
N-ISUP	ISDN User Part
N–LLC	Narrowband Low Layer Capability
OAM	Operation, Administration and Maintenance
PBX 	Private Branch Exchange
PCM	Pulse Code Modulation
PDU	Protocol Data Unit
POTS	Plain Old Telephone Service
PNNI	Private Network-Network Interface
PRI	Primary Rate Interface
PRS	Primary Reference Source
PSS1	Private Integrated services Signalling System No. 1
Q.SIG	PSS1
SAR	Segmentation and Reassembly
SDU	Service Data Unit
SN	Sequence Number
SNP	Sequence Number Protection
TE	Terminal Equipment
TDM	Time Division Multiplexing
UNI	User-Network Interface
VPN	Virtual Private Network
VTOA	Voice and Telephony Over ATM
2	Definition of native ATM terminal equipment
2.1	Functional requirements
The native ATM terminal equipment (B-TE) is able to establish a voice communication through a B-ISDN on a per call basis. The traffic is 64 kbit/s PCM-encoded voice. Each voice call uses one VCC. The B-TE may invoke supplementary services (as described in section 2.5.2) on a per call basis. 
2.2	Interfaces
A B-TE has either a public UNI to a public B-ISDN or a private UNI to a private B-ISDN.
2.3	Protocol Reference Model
Figure 2-2 illustrates the protocol reference model at the interface between the B-TE and the B-ISDN network at the SB reference point.

Figure 2-2 Protocol reference model
2.4	User plane
2.4.1	Physical layer
The physical layer shall be any of the physical layers defined by the ATM Forum. 
2.4.2	ATM Layer
The specification of the ATM layer is as defined in section ITU-T Recommendations I.150 and I.361, including OAM cells for F4 and F5 management information flows.
2.4.3	AAL
A B-TE attached to a private B-ISDN has the option of using either the AAL1 specification for voiceband signal transport as described in ITU-T Recommendation I.363.1, or the AAL5 as specified in ITU-T Recommendation I.363.5. However, a B-TE attached directly to a public B-ISDN may have to support the AAL1 specification for voiceband signal transport to conform to the public B-ISDN offerings.
It is considered extremely important that two B-TEs should be able to connect directly to one another and should not require that an interworking function be inserted into the VCC to transcode between different user plane formats (AAL1 for voice and AAL5).
Therefore, it is required that all B-TEs implement a common user plane format – in the sense that they shall accept incoming calls whose signaling indicates the use of that format.
It is not required that all B-TEs establish their outgoing calls using only the common format. A B-TE may choose to use the alternate format instead. If a call is rejected for that reason, a B-TE may choose to retry it using the common format.
Since all B-TEs must implement AAL 5 to support control plane signaling, the common user plane format is mandated to be AAL 5.
Appendix B describes the consequences of interworking between B-TEs using different AALs for voice.
2.4.3.1	Additional requirements for AAL5
Voiceband information shall use the Message Mode service.
The SSCS is null, thus the AAL-SDU is mapped to one CPCS-SDU (no SSCF and no SSCOP).
The CPCS-PDU payload may be up to 40 octets, in increments of 8 octets, with 40 octets as the preferred value. Therefore, the SAR sub-layer is trivial: the AAU bit in the Payload Type of the ATM header is always set to "1" to indicate the end of a SAR-SDU.
The CPCS User-to-User indication (CPCS-UU) (in the CPCS trailer) should be set to 00000000. The use of this octet for other purposes is reserved for further study.
The Length field in the CPCS trailer may be coded as 8 to 40.
The cell rate for AAL5 shall be 8000 ÷ payload_length cell/s (64 kbit/s x 1 octet/8 bits x 1 cell ÷ payload_length octets). For a full-fill cell, the cell rate is 200 cell/s. This implies a cell construction delay of 125 µs x payload_length. For a full-fill cell, the cell construction delay will be 5 ms.
When a B-TE or IWF receives a corrupted AAL5 CPCS-PDU, it shall pass the corrupted data, together with an indication that it is corrupted, from the ATM Adaptation layer to the higher layers according to the procedures of I.363.5. It is the responsibility of the higher layers to process this information. This method will improve the performance of the system as well provide the hooks for alternative encoding algorithms that already have error correction capabilities. 
2.4.4	Voice bit stream
The voice stream is encoded as 64 kbit/s PCM µ-Law or A-Law, as described in ITU-T Recommendation G.711. The B-TE may transmit either -Law or A-Law signals, according to the guidelines of G.711, and it must be capable of receiving both -Law or A-Law signals. Human and acoustical aspects of a speech transmission path are outside the scope of this specification. Nevertheless, the ITU-T P series Recommendations (e.g., P.310) can be taken as guidelines for developing B-TEs.
Section 4.3 contains requirements on a B-TE to provide clocking for the operation of the PCM codec in a specified order of preference. Section 5 contains a recommendation for acoustic echo control.
2.5	Control plane
The physical layer shall be as specified in section 2.4.1.
The ATM layer shall be as specified in section 2.4.2.
The SAAL layer shall be as specified in section 4.1 of UNI SIG 4.0 (af-sig-0061.000).
2.5.1	Basic Call/Connection Control Signalling
The procedures of section 6/Q.2931 "Procedures for the support of 64kbit/s based circuit-mode ISDN services in B-ISDN and access signalling interworking between N-ISDN and B-ISDN" and Appendix II.2.2/Q.2931 shall apply, as modified per UNI SIG 4.0 "Basic Point-to-Point Call".
For clarity, this section refers to Q.2931 sections numbers because UNI SIG 4.0 is a pointer to Q.2931, with a list of differences. It should be understood that the modifications described in UNI SIG 4.0 apply.
6.2.2/Q.2931 Bearer-service related information: A B-TE shall code the following information elements as described below. 
The N-BC information element shall be coded as follows:
Octet	Information element field	Field value	
3	Information transfer capability	- Speech (not to be used for fax or modem), or
- 3.1 kHz audio	
4	transfer mode	Circuit mode	
	Information transfer rate	64 kbit/s	
4.1	absent		
5	User information layer 1 protocol	- Recommendation G.711 -Law, or
- Recommendation G.711 A-Law	
5a-7	absent		
The Broadband bearer capability information element shall be coded as follows:
Octet	Information element field	Field value	
5	Bearer class	BCOB-A	
5a	absent		
6	Susceptibility to clipping	Susceptible to clipping	
	User plane connection configuration	Point-to-point	
The ATM traffic descriptor information element shall be coded as follows for AAL1 for voice.

Octet	Information
element field	Field value if no
OAM cells are used
(Note 1)	Field value if 1 OAM
cells/s is used
(Note 2)	Field value with
maximal OAM support
(Note 3)	
5	absent				
6	absent				
7.1
7.2
7.3	Forward peak
cell rate 
(CLP = 0  1)	0000 0000
0000 0000
1010 1011
(171 cells/s)	0000 0000
0000 0000
1010 1100
(172 cells/s)	0000 0000
0000 0000
1010 1111
(175 cells/s)	
8.1
8.2
8.3	Backward peak
cell rate 
(CLP = 0  1)	0000 0000
0000 0000
1010 1011
(171 cells/s)	0000 0000
0000 0000
1010 1100
(172 cells/s)	0000 0000
0000 0000
1010 1111
(175 cells/s)	
NOTES
1	These values are based on an AAL for voice (i.e., AAL type 1 with a payload of 47 octets per cell) for user information and no cell rate allocation for OAM cells.
2	These values are based on an AAL for voice (i.e., AAL type 1 with a payload of 47 octets per cell) for user information and on 1 cell/s allocation for OAM cells.
3	These values are based on an AAL for voice (i.e., AAL type 1 with a payload of 47 octets per cell) for user information and the following cell rate allocation for OAM: two percent of the user cell rate and an additional 1 cell/s.					
The ATM traffic descriptor information element shall be coded as follows for AAL5.

Octet	Information
element field	Field value if no
OAM cells are used
(Note 1)	Field value if 1 OAM
cells/s is used
(Note 2)	Field value with
maximal OAM support
(Note 3)	
5	absent				
6	absent				
7.1
7.2
7.3	Forward peak
cell rate 
(CLP = 0  1)	0000 0000
0000 0000
1100 1000
(200 cells/s)	0000 0000
0000 0000
1100 1001
(201 cells/s)	0000 0000
0000 0000
1100 1101
(205 cells/s)	
8.1
8.2
8.3	Backward peak
cell rate 
(CLP = 0  1)	0000 0000
0000 0000
1100 1000
(200 cells/s)	0000 0000
0000 0000
1100 1001
(201 cells/s)	0000 0000
0000 0000
1100 1101
(205 cells/s)	
NOTES
1	These values are based on an AAL type 5 payload of 40 octets per cell for user information and no cell rate allocation for OAM cells. For a payload of less than 40 octets, the filed value shall be 8000 ÷ payload_length, encoded in binary format.
2	These values are based on an AAL type 5 payload of 40 octets per cell for user information and on 1 cell/s allocation for OAM cells. For a payload of less than 40 octets, the filed value shall be 8000 ÷ payload_length + 1, encoded in binary format.
3	These values are based on an AAL type 5 payload of 40 octets per cell for user information and the following cell rate allocation for OAM: two percent of the user cell rate and an additional 1 cell/s. For a payload of less than 40 octets, the filed value shall be 8000 ÷ payload_length x 1.02 + 1, encoded in binary format.					
The Quality of service parameters information element shall be coded as follow:
Octet	Information element field	Field value	
5	QOS-class forward	Unspecified QOS class	
6	QOS-class backward	Unspecified QOS class	
The AAL parameters information element shall be coded as follows for AAL1 for voice.
Octet	Information element field	Field value	
5	AAL-Type	0000 0000	AAL for voice	
The AAL parameters information element shall be coded as follows for AAL5.
Octet	Information element field	Field value	
5	AAL-Type	0000 0101	AAL Type 5	
6.1
6.2	Forward maximum CPCS-SDU size	Any multiple of 8 between 8 and 40, encoded in binary format	
7.1
7.2	Backward maximum CPCS-SDU size	Any multiple of 8 between 8 and 40, encoded in binary format	
8
8.1	SSCS-type	absent (preferred), or 
0000 0000	null	
6.3/Q.2931 Interworking N-ISDN -> B-ISDN: Not applicable to B-TE.
6.4/Q.2931 Interworking B-ISDN -> N-ISDN: Not applicable to B-TE.
6.5/Q.2931 Overlap sending and receiving: Not applicable to B-TE.
6.6/Q.2931 Notification of interworking: Only those procedures relating to a user shall apply.
6.7/Q.2931 Additional features with regards to the provision of N-ISDN services: Only those procedures relating to a user shall apply.
2.5.2	Support of Supplementary Services
The support of the supplementary services defined in this section is optional, as explained in UNI SIG 4.0. However, if they are supported, they shall conform to the requirements of this section. Non-Generic Functional protocol based supplementary services consists of Supplementary Services that do not use the GF protocol as defined by ITU-T Recommendation Q.2932. GF-based supplementary services use the Generic Functional protocol as defined by the ITU-T Recommendation Q.2932. 
2.5.2.1	UNI SIG 4.0 supplementary services
The seven supplementary services supported by UNI SIG 4.0 that are applicable to a B-TE are defined in ITU-T Recommendations Q.2951 and Q.2957. These services do not require the use of the generic functional protocol.
	- Multiple Subscriber Number (MSN)
	- Calling Line Identification Presentation (CLIP)
	- Calling Line Identification Restriction (CLIR)
	- Connected Line Identification Presentation (COLP)
	- Connected Line Identification Restriction (COLR)
	- Subaddressing (SUB)
	- User-to-User Signalling (UUS) Service 1
The requirements of Annex 4/UNI SIG 4.0 apply.
2.5.2.2	Generic Functional protocol based supplementary services
For further study.
2.5.3	Notification of adaptive timing recovery
Refer to section 4.3 for a discussion of timing recovery requirements on a B-TE, including a description of the adaptive recovery mechanism used in this specification.
The procedures of this section use the following notification descriptor value in the Notification indicator information element:
Bit
7654321
0011100	Adaptive timing recovery used for transmit (TX) clock
2.5.3.1	Requirements on the B-TE originating a call
If a B-TE originating a call does not have access to a network clock, and has the capability to support adaptive timing recovery, it shall signal its intention to do so to by using notification description "Adaptive timing recovery used for transmit (TX) clock" in a Notification indicator information element in the SETUP message.
If a B-TE originating a call is performing adaptive timing recovery and receives a notification description "Adaptive timing recovery used for transmit (TX) clock" in a Notification indicator information element in any message, it shall stop performing adaptive timing recovery. This case should never happen in a network were all the B-TEs conform to this specification: it is included to allow for future services such as call transfer and conference call.
2.5.3.2	Requirements on the B-TE receiving a call
If a B-TE receiving a call receives a notification description "Adaptive timing recovery used for transmit (TX) clock" in a Notification indicator information element in any message, it shall not perform adaptive timing recovery.
If a B-TE receiving a call satisfy the following requirements, it shall perform adaptive timing recovery and signal its intention to do so to by using notification description "Adaptive timing recovery used for transmit (TX) clock" in a Notification indicator information element in the first message sent in response to the SETUP message:
- it does not have access to a network clock, and
- it has the capability to support adaptive timing recovery, and 
- it does not receive a notification description "Adaptive timing recovery used for transmit (TX) clock" in a Notification indicator information element in any message.
2.5.4	AAL negotiation
If a B-TE supporting AAL5 only and not AAL1 for voice receives a SETUP message indicating AAL1 for voice, it shall reject the call with cause value # 93, "AAL parameters cannot be supported".
The B-TE that initiated the call, upon receipt of cause value # 93, AAL parameters cannot be supported" may re-attempt the call using AAL5.
2.6	Management plane
ILMI is defined in the ILMI 4.0 specification for the UNI.
3	Interworking Function
3.1	Functional requirements
Refer to section 6.1.1/I.580 for a high-level view of the functional requirements
The interworking function (IWF) converts the voice traffic on the B-ISDN (ATM network) to voice traffic on the N-ISDN (narrowband telephony network). On both sides, the traffic is 64 kbit/s PCM-encoded voice. One ATM VCC is mapped to one N-ISDN channel dynamically on a per call basis. For that purpose, the IWF also maps the B-ISDN signalling information (on VC=5) to N-ISDN signalling information (on the D-channel). To preserve service integrity, the IWF attempts to keep intact as much as possible the information of the signalling channel.
In the opposite direction from the N-ISDN to the B-ISDN, an inverse set of operations to the above is performed.
3.2	Interfaces and protocols
This section specifies mapping requirements to interwork between N-ISDN and B-ISDN at the interworking function (IWF). It also proposes interworking configurations and a protocol reference model. The interworking configurations shown in Figure 3-1 are derived from scenario B case 1 of Annex A/I.580, but contains additional clarification. See section 1.2 for more details. Also, it allows for the use of AAL5 for the transport of voiceband information, as described in section 2.4.3.1. When the N-ISDN is a public network, the signalling protocol between the B-ISDN and the IWF is DSS2, and the signalling between the IWF and the N-ISDN is DSS1. When the N-ISDN is a private network, the signalling protocol between the B-ISDN and the IWF is PNNI signalling or DSS2, and the signalling protocol between the IWF and the private N-ISDN is PSS1 (Q.SIG).
Two B-ISDN private networks can be connected through an N-ISDN network (public or private), or a B-ISDN network can be connected to narrowband devices (N-ISDN or analogue) through a N-ISDN.

Figure 3-1 Interworking configurations
The S and T reference points are described in ITU-T Recommendation I.411. The SB and TB reference points are described in ITU-T Recommendation I.413. The Q reference point is described in ISO/IEC 11579-1.
In Figure 3-1, at the T reference point, the user side of the interface is at the left and the network side of the interface is at the right. At the TB reference point, the user side of the interface is at the left and the network of the interface is at the right if the IWF maps messages one-to-one; if the IWF fully terminates the call control protocol, the user side and the network side can be reversed. See section 3.4.2 for more details.
A private B-ISDN may consist of a multitude of devices, including a private ATM switch or a network of private ATM switches.
A private N-ISDN may consist of a multitude of devices, including a PBX or a network of PBXs.
- Public N-ISDN
In this interworking scenario, the N-ISDN sees the IWF as a B-TE or as a PBX. Depending on which side is the user side, the private B-ISDN sees the IWF either as a B-TE or as a public B-ISDN.
- Private N-ISDN
In this interworking scenario, the private N-ISDN sees the IWF as another N-ISDN node in the private N-ISDN network. Similarly, the private B-ISDN sees the IWF as another B-ISDN node in the private B-ISDN network.
In some scenarios, the IWF may be integrated, as shown in Figure 3-2:
- either with the private B-ISDN, in which case there would be no physical PNNI or UNI between the private B-ISDN and the IWF;
- or with the private N-ISDN, in which case there would be no real Q reference point between the IWF and the private N-ISDN.

Figure 3-2 Additional interworking configurations for integrated IWF
When the IWF is integrated, some of the requirements in the following sections may not apply. For example, if the IWF is integrated with the private B-ISDN, there will be no PNNI at the IWF.
3.3	User plane
3.3.1	Protocol Reference Model
Figure 3-3 illustrates the user information (user plane) interworking applicable to the same reference configuration.

Figure 3-3 User information (U-plane)
In the User plane, the role of the IWF is to convert between TDM encoded voice-band information and ATM cell-based voice-band information.
3.3.2	Physical layer
The physical layer on the B-ISDN side of the IWF shall be any of the physical layers defined by the ATM Forum. On the public N-ISDN side of the IWF, the physical layer as defined in ITU-T Recommendations I.430 or I.431 shall apply. There is no standard physical layer for the private N-ISDN side of the IWF (Q.SIG).
3.3.3	ATM Layer
The specification of the ATM layer is as defined in ITU-T Recommendations I.150 and I.361, including OAM cells for F4 and F5 management information flows. In the case of public N-ISDN interworking, the IWF shall act as the network side of the public UNI.
For private N-ISDN interworking, see section 6.1.2.3/PNNI 1.0 for additional clarification.
3.3.4	AAL
The IWF has the option of using either the AAL1 specification for voiceband signal transport as described in ITU-T Recommendation I.363.1, or the AAL5 as specified in ITU-T Recommendation I.363.5.
The IWF shall support both AAL1 for voice and AAL5, or shall behave like a B-TE in which case the requirements of 2.4.3 apply.
See Appendix B for information on interworking between B-TEs using different AALs for voice.
3.3.4.1	Additional requirements for AAL5
The requirements of 2.4.3.1 apply.
3.3.5	Voice stream
The voiceband information is encoded as 64 kbit/s PCM µ-Law or A-Law, as described in ITU-T Recommendation G.711.
3.4	Control plane
3.4.1	Protocol reference model
Figure 3-4 illustrates the signalling interworking (control plane) applicable to the reference configuration of section 3.2. 

Figure 3-4 Signalling (C-plane)
The physical layer shall be as specified in section 3.3.2.
The ATM layer shall be as specified in section 3.3.3.
- Public N-ISDN
In the Control plane, the role of the IWF is to act as a protocol converter between DSS2 and DSS1. The SAAL layer shall be as specified in section 4.1 of UNI SIG 4.0 (af-sig-0061.000).
- Private N-ISDN
In the Control plane, the role of the IWF is to be a protocol converter between PSS1 and DSS2 or PNNI signalling. The SAAL layer shall be as specified in section 4.1/UNI SIG 4.0 (af-sig-0061.000) for DSS2 signalling or in section 6.1.2.2/PNNI.0 (af-pnni-0055.000) for PNNI signalling.
3.4.2	Basic Call/Connection Control Signalling
Interworking between the N-ISDN basic call signalling protocol and the B-ISDN basic call/connection control signalling protocol shall be achieved either by fully terminating each protocol within the IWF or by a one-to-one mapping of messages.
Where each protocol is fully terminated, a message of global significance from one network shall result in the corresponding message being sent to the other network, subject to the other network's protocol being in a suitable state for sending that message. Messages of global significance are SETUP, ALERTING, CONNECT, PROGRESS and the first call clearing message (DISCONNECT, RELEASE or RELEASE COMPLETE). When mapping the first call clearing message from one network onto the first call clearing message to be sent to the other network, the choice of message to be sent will depend on the requirements of the other network's protocol (e.g., a RELEASE COMPLETE message as a first call clearing message from the B-ISDN can result in a DISCONNECT message being sent to the N-ISDN, unless it is the first response to a SETUP message from the N-ISDN). Messages of local significance (all other messages) shall be terminated in the IWF if received and shall be generated in the IWF in accordance with the requirements of the protocol. Protocol timers shall be run in accordance with the requirements of the two protocols.
Where messages are mapped one-to-one, each message from one network shall be mapped onto the corresponding message of the other network, apart from the exceptions detailed in the remaining subsections of 3.4.2. Protocol timers need not be run except where specified in the remaining subsections of 3.4.2.
In both cases, when mapping a message from one protocol to the other, the IWF shall pass on each received information element that is allowed in the corresponding message of the other protocol and carry out any necessary length adjustment. Other contents shall not be changed, except where specified in the remaining subsections of 3.4.2. Received information elements that cannot be mapped shall be discarded. When sending a message, additional information elements shall be generated in accordance with the requirements of the protocol concerned and the requirements of Annex E/Q.2931 (see 3.4.2.8 for more details).
If the IWF converts between DSS2 and PSS1, a simple one-to-one mapping is impossible and the protocol shall be fully terminated on both sides of the IWF.
3.4.2.1	Public N-ISDN
The procedures of section 6/Q.2931 “Procedures for the support of 64 kbit/s based circuit-mode ISDN services in B-ISDN and access signalling interworking between N-ISDN and B-ISDN” and Annex E/Q.2931 “Mapping functions to support 64 kbit/s based circuit-mode ISDN services in B-ISDN and interworking between N-ISDN and B-ISDN (DSS1/DSS2)” shall apply, as modified per section 2/UNI  4.0 “Basic Point-to-Point Call”.
For clarity, this section refers to Q.2931 sections numbers because UNI SIG 4.0 is a pointer to Q.2931, with a list of clarification. It should be understood that the modifications described in UNI SIG 4.0 apply. 
The following DSS1 procedures are not supported by UNI SIG 4.0 and should be handled locally by the IWF, if required:
•	Annex E/Q.931 - Network specific facility selection
•	Annex F/Q.931 - D-channel backup procedures
•	Annex H/Q.931 - Message segmentation procedures
The B-TE shall cut-through the voice path when initiating the call.
3.4.2.2	Private N-ISDN
PNNI 1.0 does not explicitly support the procedures for the support of 64 kbit/s based circuit-mode ISDN services in B-ISDN and the mapping functions for B-ISDN/N-ISDN interworking. However, PNNI 1.0 supports the transparent transport of the information elements and messages required to interwork with N-ISDN. The material in this section is thus also applicable to Private N-ISDN interworking.
3.4.2.3	Overlap sending and receiving
If the N-ISDN network uses overlap sending and receiving, the IWF will have to collect the digits and determine when the number is completed, before it can format the addressing information in one the format supported by UNI or PNNI.
3.4.2.4	Instruction indicators
DSS2 and PNNI supports instruction indicators, but not DSS1 and PSS1.
In the N-ISDN to B-ISDN direction, the IWF shall generate the instruction indicator as per the guidelines of Appendix I/Q.2931.
In the B-ISDN to N-ISDN direction, the IWF shall conform to the requirements of sections 5.7, 5.8/Q.2931 for public N-ISDN interworking and the requirements of sections 6.5.7, 6.5.8/PNNI 1.0 for private N-ISDN interworking. In some cases, it means the IWF may need to clear the call on both the B-ISDN and the N-ISDN sides of the IWF.
3.4.2.5	Call clearing
This subsection does not apply if both protocols are fully terminated within the IWF.
Since the call clearing procedures are the same for both public and private N-ISDN interworking, this section covers both cases. 
The call clearing sequences of N-ISDN and B-ISDN differ since in B-ISDN does not support the DISCONNECT message. The normal N-ISDN call clearing sequence is DISCONNECT/RELEASE/RELEASE COMPLETE while the normal B-ISDN call clearing sequence is RELEASE/RELEASE COMPLETE.
UNI SIG 4.0 and PNNI 1.0 does not explain how to map the call clearing sequence between N-ISDN and B-ISDN.
In the following requirements, when referring to a message being “mapped”, it should be understood that the content of the message should be preserved as much as possible, even when mapping from one message to another (e.g., when mapping a N-ISDN DISCONNECT message to a B-ISDN RELEASE message. By opposition, when referring to a “locally-generated” message, it should be understood that the message is generated by the IWF and does not have significance across the IWF.
Figure 3-5 illustrates the mapping of call clearing messages from N-ISDN to B-ISDN and from B-ISDN to N-ISDN.

Figure 3-5 Mapping of call clearing messages
- N-ISDN  ->  B- ISDN 
A N-ISDN DISCONNECT message shall be mapped to a B-ISDN RELEASE message; the procedures of 5.4.4/ITU-T Q.2931 for public N-ISDN interworking or 6.5.3.3/PNNI 1.0 for private N-ISDN interworking shall apply. The IWF shall respond to the N-ISDN side by sending a locally-generated N-ISDN RELEASE message; the procedures of 5.3.3/ITU-T Q.931 for public N-ISDN interworking or 10.2.3/ISO/IEC 11572 for private N-ISDN interworking shall apply. Normally, the N-ISDN side should respond with a N-ISDN RELEASE COMPLETE message that shall cause the IWF to stop timer T308. In response to the B-ISDN RELEASE message, the B-ISDN side should respond with a B-ISDN RELEASE COMPLETE message that shall cause the IWF to stop timer T308. 
A N-ISDN RELEASE message shall be mapped to a B-ISDN RELEASE message; the procedures of 5.4.4/ITU-T Q.2931 for public N-ISDN interworking or 6.5.3.3/PNNI 1.0 for private N-ISDN interworking shall apply. The IWF shall respond to the N-ISDN side by sending a locally-generated N-ISDN RELEASE COMPLETE message. In response to the B-ISDN RELEASE message, the B-ISDN side should respond with a B-ISDN RELEASE COMPLETE message that shall be ignored by the IWF.
If a N-ISDN RELEASE COMPLETE is received as the first call clearing message (e.g., as a response to a SETUP message), it shall be mapped to a B-ISDN RELEASE COMPLETE message.
- B-ISDN  - > N- ISDN
A B-ISDN RELEASE message shall be mapped to a N-ISDN DISCONNECT message, and timer T305 shall be started. The IWF shall respond to the B-ISDN side by sending a locally-generated B-ISDN RELEASE COMPLETE message. In response to the N-ISDN DISCONNECT message, the N-ISDN side should respond with a N-ISDN RELEASE message to which the IWF should respond with a locally-generated N-ISDN RELEASE COMPLETE message. On receipt of the N-ISDN RELEASE message, timer T305 shall be canceled. If timer T305 expires, the IWF shall send a N-ISDN RELEASE message to the network with the cause number originally contained in the N-ISDN DISCONNECT message. In addition, the IWF may indicate a second Cause information element with cause No. 102, “recovery on timer expiration”.
Note - The default value for timer T305 is defined as 30 s in ITU-T Recommendation Q.931 and in ISO/IEC 11572.
If a B-ISDN RELEASE COMPLETE is received as the first call clearing message (e.g., as a response to a SETUP message), it shall be mapped to a N-ISDN RELEASE COMPLETE message.
3.4.2.5.1	Clearing collision
Clearing collision occurs when the IWF receives a call clearing indication (either a DISCONNECT or a RELEASE message) simultaneously from the B-ISDN and the N-ISDN side specifying the same call (this is done by correlating the call reference values on both sides).
If the IWF receives a N-ISDN DISCONNECT message after sending a N-ISDN DISCONNECT message, it shall stop N-ISDN timer T305, release the call reference, disconnect the information channel (if not already disconnected), send a N-ISDN RELEASE message and start timer T308. The procedures on the B-ISDN side are not affected.
If the IWF receives a N-ISDN RELEASE message after sending a N-ISDN RELEASE message, it shall stop timer T308, release the call reference and disconnect the information channel without sending a N-ISDN RELEASE COMPLETE message. The procedures on the B-ISDN side are not affected.
If the IWF receives a B-ISDN RELEASE message after sending a B-ISDN RELEASE message, it shall stop timer T308, release the call reference and virtual channel without sending a B-ISDN RELEASE COMPLETE message. The procedures on the N-ISDN side are not affected.
Figure 3-6 illustrates the mapping of call clearing messages from N-ISDN to B-ISDN and from B-ISDN to N-ISDN when there is call collision.

Figure 3-6 Mapping of call clearing messages with collision
3.4.2.6	Connection acknowledgment
This subsection does not apply if both protocols are fully terminated within the IWF.
3.4.2.6.1	Public N-ISDN
There is no special requirements for public N-ISDN interworking.
3.4.2.6.2	Private N-ISDN
The PNNI signalling protocol does not support the CONNECT ACKNOWLEDGE message and the associated T313 timer. If possible, the CONNECT ACKNOWLEDGE message shall not be supported on the N-ISDN side by bilateral agreement, as mentioned in the note at the end of section 10.1.6/ISO/IEC 11572.
However, if this is not possible, the IWF shall respond to a N-ISDN CONNECT message by sending a locally-generated N-ISDN CONNECT ACKNOWLEDGE message. The IWF shall ignore a N-ISDN CONNECT ACKNOWLEDGE message. 
The IWF shall not support timer T313. 
Figure 3-7 illustrates the mapping of call/connection establishment messages from private N-ISDN to private B-ISDN and from private B-ISDN to private N-ISDN when the private N-ISDN makes use of the CONNECT ACKNOWLEDGE message.

Figure 3-7 Mapping of connection establishment messages in private N-ISDN/private B-ISDN
3.4.2.7	Restart procedure
Restart procedures shall operate independently across each interface. On the B‑ISDN side, restart procedures shall operate in accordance with section 5.5/Q.2931 or section 6.5.5/PNNI 1.0. On the N-ISDN side, restart procedures shall operate in accordance with section 5.5 of Q.931 or subclause 11.1/ISO/IEC 11572.
As a result of performing a restart of "all interfaces" on the N‑ISDN side, the IWF shall initiate a restart of "all virtual channels" on the B‑ISDN side.
As a result of performing a restart of "single interface" on the N‑ISDN side, the IWF shall initiate a restart of any VCIs on the B‑ISDN side that are currently mapped to channels on the N‑ISDN interface concerned.
As a result of performing a restart of "indicated channels" on the N‑ISDN side, the IWF shall initiate a restart of any VCIs on the B‑ISDN side that are currently mapped to the N‑ISDN channels concerned.
As a result of performing a restart of "all virtual channels" on the B‑ISDN side, the IWF shall initiate a restart of "all interfaces" on the N‑ISDN side.
As a result of performing a restart of "all virtual channels in the indicated VPC" on the B‑ISDN side, the IWF shall initiate restart of any N‑ISDN channels that are currently mapped to VCIs in the indicated VPC.
As a result of performing a restart of "indicated virtual" on the B‑ISDN side, the IWF shall initiate restart of any N‑ISDN channel that is currently mapped to the indicated VCI.
3.4.2.8	Additional requirements for basic call/connection control
This section provides additional guidance for section 6/Q.2931 and Annex E/Q.2931. To maintain consistency with UNI SIG 4.0, the text of Q.2931 shall apply unless otherwise stated: only the subsections with exceptions are given below. In this implementation agreement, subsections of section 6/Q.2931 and Annex E/Q.2931 are identified by the actual subsection number from that Recommendation with the Recommendation number appended.
The IWF shall map N-ISDN codeset 4, 5, 6 and 7 information elements to B-ISDN. However, it is possible that they will be discarded within the B-ISDN.
Throughout section 6/Q.2931, whenever "AAL for voice" is encountered, it is understood that it may be "AAL1 for voice" or "AAL5 for voice", e.g., in sections 6.2.3/Q.2931, 6.3.3/Q.2931 and 6.7.1/Q.2931.
Figure 6-1/Q.2931 Illustration of the use of N-LLC and B-LLI information elements in Q.2931: The following configuration should be added and is the configuration applicable to this specification.

Annex E/Q.2931 Mapping functions to support 64 kbit/s based circuit-mode ISDN services in B-ISDN and interworking between N-ISDN and B-ISDN (DSS1/DSS2): Since this specification is applicable at both the UNI and at the PNNI, "DSS1" shall be replace by "N-ISDN", and "DSS2" shall be replaced by "B-ISDN" throughout Annex E. The modifications of UNI SIG 4.0 apply.
E.2.1/Q.2931 A B-ISDN user requests the 3.1 kHz audio N-ISDN bearer service: The AAL parameters can be coded as either "AAL for voice" or "AAL5".
E.2.2/Q.2931	A B-ISDN user requests the N-ISDN unrestricted digital information bearer service: Not applicable.
E.2.3/Q.2931 A B-ISDN user requests the N-ISDN telephony teleservice: The AAL parameters can be coded as either "AAL for voice" or "AAL5".
E.2.4/Q.2931 A B-ISDN user requests the N-ISDN videotelephony teleservice based on the unrestricted digital information with tones/announcements bearer capability: Not applicable.
E.3.2/Q.2931	A N-ISDN user requests the unrestricted digital information bearer service: Not applicable.
E.3.4/Q.2931 A N-ISDN user requests the videotelephony teleservice based on the unrestricted digital information bearer capability: Not applicable.
E.4.2.2.1/Q.2931 ATM traffic descriptor for N-BC information transfer capabilities of unrestricted digital information and restricted digital information: Not applicable.
E.4.2.2.2/Q.2931 ATM traffic descriptor for N-BC information transfer capabilities of speech and 3.1 kHz audio:
The following table applies to AAL1 for voice.

Octet	Information
element field	Field value if no
OAM cells are used
(Note 1)	Field value if 1 OAM
cells/s is used
(Note 2)	Field value with
maximal OAM support
(Note 3)	
7.1
7.2
7.3	Forward peak
cell rate 
(CLP = 0  1)	0000 0000
0000 0000
1010 1011
(171 cells/s)	0000 0000
0000 0000
1010 1100
(172 cells/s)	0000 0000
0000 0000
1010 1111
(175 cells/s)	
8.1
8.2
8.3	Backward peak
cell rate 
(CLP = 0  1)	0000 0000
0000 0000
1010 1011
(171 cells/s)	0000 0000
0000 0000
1010 1100
(172 cells/s)	0000 0000
0000 0000
1010 1111
(175 cells/s)	
NOTES
1	These values are based on an AAL for voice (i.e., AAL type 1 with a payload of 47 octets per cell) for user information and no cell rate allocation for OAM cells.
2	These values are based on an AAL for voice (i.e., AAL type 1 with a payload of 47 octets per cell) for user information and on 1 cell/s allocation for OAM cells.
3	These values are based on an AAL for voice (i.e., AAL type 1 with a payload of 47 octets per cell) for user information and the following cell rate allocation for OAM: two percent of the user cell rate and an additional 1 cell/s.					
The following table applies to AAL5.

Octet	Information
element field	Field value if no
OAM cells are used
(Note 1)	Field value if 1 OAM
cells/s is used
(Note 2)	Field value with
maximal OAM support
(Note 3)	
7.1
7.2
7.3	Forward peak
cell rate 
(CLP = 0  1)	0000 0000
0000 0000
1100 1000
(200 cells/s)	0000 0000
0000 0000
1100 1001
(201 cells/s)	0000 0000
0000 0000
1100 1101
(205 cells/s)	
8.1
8.2
8.3	Backward peak
cell rate 
(CLP = 0  1)	0000 0000
0000 0000
1100 1000
(200 cells/s)	0000 0000
0000 0000
1100 1001
(201 cells/s)	0000 0000
0000 0000
1100 1101
(205 cells/s)	
NOTES
1	These values are based on an AAL type 5 payload of 40 octets per cell for user information and no cell rate allocation for OAM cells. For a payload of less than 40 octets, the filed value shall be 8000 ÷ payload_length, encoded in binary format.
2	These values are based on an AAL type 5 payload of 40 octets per cell for user information and on 1 cell/s allocation for OAM cells. For a payload of less than 40 octets, the filed value shall be 8000 ÷ payload_length + 1, encoded in binary format.
3	These values are based on an AAL type 5 payload of 40 octets per cell for user information and the following cell rate allocation for OAM: two percent of the user cell rate and an additional 1 cell/s. For a payload of less than 40 octets, the filed value shall be 8000 ÷ payload_length x 1.02 + 1, encoded in binary format.					
E.4.2.4.1/Q.2931 AAL parameters for N-BC information transfer capabilities of unrestricted digital information and restricted digital information: Not applicable.
E.4.2.4.2	AAL parameters for N-BC information transfer capabilities of speech and 3.1 kHz audio 
The table in E.4.2.4.2/Q.2931 applies to AAL1 for voice.
The following table applies to AAL5.
Octet	Information element field	Field value	
5	AAL-Type	0000 0101	AAL Type 5	
6.1
6.2	Forward maximum CPCS-SDU size	Any multiple of 8 between 8 and 40, encoded in binary format	
7.1
7.2	Backward maximum CPCS-SDU size	Any multiple of 8 between 8 and 40, encoded in binary format	
8
8.1	SSCS-type	absent (preferred), or 
0000 0000	null	
E.4.2.4.3/Q.2931 AAL parameters for N-BC information transfer capabilities of unrestricted digital information with tones/announcement: Not applicable.
3.4.2.8.1	Called party number, Calling party number and Connected number information elements: 
The requirements of section 6 apply.
3.4.2.8.2	Connection identifier information element 
This subsection does not apply if both protocols are fully terminated within the IWF. The IWF shall replace the Connection identifier information element by a Channel identifier information element, and vice-versa. At call establishment, the IWF needs to allocate a mapping between a Connection identifier and a Channel identifier. It is outside the scope of this specification to describe how it is done. After a call is established, the IWF needs to maintain a mapping of the Connection identifiers to the Channel identifiers so that the VPI/VCI and channel can be released correctly on call/connection clearing.
3.4.3	Mapping of Supplementary Services Signalling
This section divides supplementary services in two classes:
Non GF-based:	Supplementary services which do not require the use of the Generic Functional protocol.
GF-based:	Supplementary services that use the Generic Functional protocol.
3.4.3.1	UNI SIG 4.0 Supplementary Services
The IWF shall support the mapping of the supplementary services defined in UNI SIG 4.0 between DSS2 and DSS1. The PNNI 1.0 signalling specification does not explicitly support the procedures for N-ISDN Number identification supplementary services in B-ISDN as described in Annex 4/UNI SIG 4.0. However, these services are implicitly supported by the PSS1 protocol as part of basic call control and by PNNI 1.0 since these services use basic call/connection control procedures. Therefore, the requirements this section are applicable both for public and private N-ISDN interworking.
3.4.3.1.1	Direct Dialing In (DDI)
The requirements of section 6 apply.
3.4.3.1.2	Multiple Subscriber Number (MSN)
The requirements of section 6 apply.
3.4.3.1.3	Calling Line Identification Presentation (CLIP)
The requirements of section 6 apply.
3.4.3.1.4	Calling Line Identification Restriction (CLIR)
The requirements of section 4.11.1/Q.2951 apply.
3.4.3.1.5	Connected Line Identification Presentation (COLP)
The requirements of sections 6 and 5.11.1/Q.2951 apply. 
3.4.3.1.6	Connected Line Identification Restriction (COLR)
The requirements of section 6.11.1/Q.2951 apply.
3.4.3.1.7	Subaddressing (SUB)
- N-ISDN -> B-ISDN
The DSS1 Called party subaddress information element is mapped to the DSS2 Called party subaddress information element by the IWF by inserting the second octet and adjusting the length indication without causing other changes to the contents, and by respecting the order of this information element in the DSS2 message.
3.4.3.1.8	User-to-User Signalling (UUS) Service 1
The requirements of section 6.11.1/Q.2957.1 shall apply for public N-ISDN interworking. This supplementary service is not supported by PNNI 1.0 or PSS1 and is thus not applicable to private N-ISDN interworking. The manufacturer specific information transfer capability of the PSS1 Generic Functional protocol offers equivalent functionality.
3.4.3.2	Generic Functional protocol based supplementary services
For further study.
3.4.4	AAL negotiation
If the IWF supports both AAL1 for voice and AAL5, no AAL negotiation procedures are required. Otherwise, it shall behave as a B-TE and the requirements of 2.5.4 are applicable.
3.5	Management plane
ILMI is defined in the ILMI 4.0 and PNNI 1.0 specifications for respectively the UNI and the PNNI. In the case of public N-ISDN interworking, the IWF shall act as the network side of the public UNI. Special MIB elements to manage the IWF are for further study.
MIBs between N-ISDN and the IWF are outside the scope of this specification. In the case of public N-ISDN interworking, the IWF shall act as the user side of the interface (BRI or PRI).
3.7	PNNI Routing Protocol
The PNNI 1.0 specification includes a signalling and routing protocol. Full signalling functionality requires PNNI routing and so PNNI signalling cannot be used without the routing functions.
To support PNNI, the IWF must support the minimum function subset as described in Annex G/PNNI 1.0. This enables the IWF to act as node within a lowest level PNNI peer group.
In a PNNI topology, if an IWF with the minimum function subset has a single connection to the ATM network, it is a stub node from a routing perspective. This means that it terminates and originates calls, but does not have tandem VCs. For reliability, an IWF could be connected by multiple PNNI links to the ATM network. If the network operator does not want the IWF to tandem calls in this topology, the restricted transit bit can be set in the nodal flags advertised in the Nodal IG. This will allow only originating and terminating call traffic.
The IWF could optionally implement the:
- border node subset
- border node with logical group node peer support
- PNNI options subset
Note - In the above configurations, the IWF could be part of an ATM switch that supports the full PNNI protocol.
4	Timing and synchronisation
The voice and telephony services of the N-ISDN are synchronous services. To minimize service defects, public networks are synchronised to primary reference standards. Refer to ANSI T1.101 and ITU-T Recommendation G.811 for accuracy requirements for synchronisation in public networks. A timing relationship is therefore required when a B-TE is connected to the N-ISDN via an IWF. The PCM codec in the B-TE may have to be synchronised to the network clock of the N-ISDN. 
4.1 Timing distribution mechanisms
There are three distribution mechanism available:
- Network based (physical layer),
- Adaptive (ATM and/or AAL layer),
- Independent (free running clock),
Timing derived from a network based clock (i.e., the physical layer), when available, is the preferred timing distribution mechanism. However, there are many cases where no network clock distribution mechanism is available: e.g., legacy ATM LANs. Additionally, the 100 Mbit/s Fiber (TAXI) ATM physical interfaces does not have any network based (physical layer) timing distribution mechanism.
The timing distribution mechanism is technically independent of the choice of AAL (i.e., AAL5 or AAL1 for voice). However, ITU-T Recommendation I.363.1 states that network based timing distribution (at the physical layer) shall be used for AAL1 for voice. Within private networks, adaptive or independent timing distribution mechanisms could be used. At a public UNI, the timing distribution mechanism shall be network based (physical layer).
4.1.1 Network based timing distribution (physical layer)
Network based timing distribution mechanisms are shown in Figure 4-1. Network based timing distribution is typically achieved by receiver recovery of the line rate of the physical interface ( e.g. DS1, SONET).
In some cases a separate clock distribution network may be used.
Information on the distribution of network timing may be found in Bellcore document TR-NWT-001244. Public networks typically utilize timing traceable to primary references. Some private networks may not be traceable to such references in which case alternative synchronisation mechanisms should be employed. 

Figure 4-1 Network Based Timing Distribution Mechanisms
4.1.2 Adaptive timing (ATM and/or AAL layer)
The adaptive clock method is a general method for source clock frequency recovery. No explicit timing information of the source clock is transported by the network: the method is based on the fact that the amount of transmitted data is an indication of the source frequency, and this information can be used to recover the source clock frequency. By averaging the amount of received data over a period of time, CDV (Cell Delay Variation) effects are counteracted. The period of time used for averaging depends on the CDV characteristics.
The implementation of the method is not standardized. One possible method to measure the amount of data is to use the fill level of the AAL user data buffer. The following is the general description of this method and does not preclude other adaptive clock methods.
The B-TE writes the received data into a buffer, and then reads it out using a locally generated clock. Therefore the fill level of the buffer depends on the source frequency and it is used to control the frequency of the local clock. Operations are the following: the fill level of the buffer is continuously measured and the measure is used to drive the phase-locked loop generating the local clock. The method maintains the fill level of the buffer around its medium position. To avoid buffer underflow or overflow, the fill level is maintained between two limits. When the level in the buffer goes to the lower limit, this means the frequency of the local clock is too high compared to the one of the source and so it has to be decreased ; when the level in the buffer goes to upper limit, the frequency of the local clock is too low compared to the one of the source, and so it has to be increased.
4.1.3 Independent timing (free running clock)
Independent timing requires access to a reference clock of sufficient accuracy to minimize the slips at the synchronisation boundary. 
If free-running clocking is implemented, then bit slip and cell loss or cell gain will occur. Under these circumstances, the IWF or the B-TE will have to repeat information, insert silence or noise, or discard information (incipient buffer overflow) to recover. This information could be on a cell basis or preferably on an octet basis for better performance. This option will be satisfactory for simple point to point links which only want to transport 64 kbit/s PCM encoded voice. However it is inadequate for quality voice service delivery to the desktop and may cause errors for some fax/modem data rates. For information, for a 64Kbit voice call between 2 PCs, one +50ppm and the other -50ppm the data will slip one octet per 12 seconds. Should the free running option be chosen, the end stations (B-TE or IWF) would normally repeat the last octet on underrun or delete on overrun.
When a free-running clock is used, slips have to be accepted. ISDN quality of service can not reasonably be met. A reasonable slip rate for speech communication might be in the order of one slip every 10 seconds. This corresponds to a frequency accuracy of 10-5 for single octet slips or 10-4 when slipping more than 8 octets at the time. For facsimile or modem quality of service, the slip requirement has to be decrease by a factor of 10 to 100. Bit error rate requirements can be relaxed to minimize slip rate.
4.2	IWF requirements
Figure 4.2 illustrates the basic structure of the interworking function.

Figure 4-2 Basic structure of the IWF
The IWF shall be synchronised to the N-ISDN public or private network clock. This clock is referenced to the Primary Reference Source (PRS). For private N-ISDN that are not referenced to the PRS, a Stratum 4 clock source is required at a minimum.
The IWF shall use its synchronous clock to write PCM data into the packetiser of the AAL transmitter. This leads to a cell rate of 200 cell/s (full cell fill AAL5) or 171 cell/s (AAL1 for voice).
The IWF shall have the ability to receive cell streams from unsynchronised sources, i.e., free running clocks at the B-TEs. This requires provisions to cope with overflows and underflows in the CDV and reassembly buffer. The buffer is read out using the N-ISDN network clock but may be filled by the AAL receiver at a higher or lower rate.
The N-ISDN network clock may be distributed in the ATM network to the B-TEs by transferring synchronisation information through the physical layers.
4.3	B-TE requirements
There are in principle three possible ways to provide clocks for the operation of the PCM codec in the B-TE:
(n) Network based (physical layer),
(a) Adaptive (ATM and/or AAL layer) which is realised, for example, by using a voltage controlled oscillator (VCXO) controlled by the fill level of the CDV buffer,
(i) Independent (free running clock), using a free running oscillator. 
The B-TE is required to have a free running oscillator, option (i), if it may be used in a situation where a network clock signal is not accessible or is not active.
Figure 4.3 illustrates the timing relationship in the B-TE. Table 4.1 summarises which clocks have to be applied to the PCM coder and decoder for the various options. 
The algorithm to determine the timing recovery mechanism at the terminal, as summarised by Table 4-1, is as described in the following paragraphs. In addition, the B-TE shall conform to the signalling requirements of section 2.5.3.
If a B-TE has access to a network clock (at the physical layer), it shall synchronise both its RX and TX clocks to this network clock.
If no network clock is available, and if the B-TE does not receive an indication from the other end that it will use adaptive timing recovery, the B-TE shall perform adaptive timing recovery on both it's TX and RX clocks if it has the capability to do so.
If no network clock is available, and if the B-TE receives an indication from the other end that it will perform adaptive timing recovery, the B-TE shall use an independent clock on its TX clock to avoid a timing loop. If the B-TE has two distinct clocks for TX and RX, it shall perform adaptive timing recovery on the RX clock if it has the capability to do so. If the B-TE only has one clock (i.e., if RX and TX clocks are the same), it the RX/TX clock shall be run independently (free-running).
If no network clock is available, and if the B-TE does not have the ability to perform adaptive timing recovery, it shall use a free-running clock on both TX and RX. This is the minimum requirement.
Table 4-1 Timing distribution mechanism
Order of preference	RX clock	TX clock	
1	n	n	
2 - not allowed if other end signals its intention to do adaptive on both RX and TX clocks	a	a	
3 - some B-TEs may not support this option if the RX and TX clocks are the same	a	i	
4	i	i	

Figure 4-3 Timing relationships in the B-TE
A B-TE using a free running clock requires provisions to cope with overflow or underflow in the CDV and reassembly buffer. The buffer is read out using the local free running clock but may be filled by the AAL receiver at a higher or lower rate which is determined by the IWF or the other B-TE.
Note - A B-TE which has the ability to synchronise to the network clock (physical layer) must know if the ATM network it is connected to provides network clock synchronisation over the physical layer. For a 25.6 Mbit/s interface, for example, this may not be a problem since the chips often have a special output providing 8 kHz synchronisation information. This pin has only to be monitored for activity. In case of a 155 Mbit/s Sonet/SDH interface, the transmission clock will be locked to the N-ISDN clock. At the B-TE, the 8 kHz frame clock may be derived by division from the line clock. In this case, a B-TE can not directly detect if the physical layer is locked to a reference clock or not. One method for the B-TE to determine if network clock synchronisation is achievable would by a "trial and error method" where the B-TE would try to use the clock derived from the physical layer and conclude that the physical layer is not synchronised if slips occur.
5	Delay and echo
Appropriate echo control measures are recommended on all speech connections where the end-to-end delay exceeds that specified in section 3.1/G.131. Additional guidance is provided in G.176.
It is recommended that echo control be provided as close to the source as possible. For connections to the N-ISDN, hybrid echo control should be provided at the IWF on the N-ISDN side, and acoustic echo control should be provided at the voice terminal on the B-ISDN side.
Appendix A provides a brief overview of some of the issues related to echo in N-ISDN. 
6	Addressing
The material from section 6/af-vtoa-0083.000 has been superseded by the material in ATM Forum Addressing: Reference Guide (af-ra-0106.000), more specifically by Annex C.
The following summarizes the changes:
•	To interwork an ATM address with a public or private N-ISDN, there needs to be a way to map between one address to the other. Many means are available, e.g.: a database look-up mechanism such as the ATM Name System Specification (af-saa-0069.000) can be used, the same address formats can be used in both cases, or an algorithmic mapping between the two addressing plans can be defined. Section 6/af-vtoa-0083.000 only assumed a fixed mapping solution that is now only an example.
•	Except for the Calling party number in the outgoing direction, setting the DSP field to zero for NSAP-formatted E.164 addresses can not be assumed since the DSP can be used for other purposes.
•	A “fixed” mapping of PNP into a Local AFI can not be assumed because the AFI can be used within the same network for other addressing plans. The mapping that was mandatory in af-vtoa-0083.000 is therefore only a suggested format, for the case where the Local AFI is not used by other addressing plans.
•	For routing purposes, a PNP address encoded in an Local AFI format should be left-justified instead of right-justified.
•	The maximum length of a PNP address is 15 digits, not 16.

Appendix A - Echo Cancellation in N-ISDN
(Informative)
A general description of the applications of echo cancellation in N-ISDN/PSTN is provided in ANSI Technical Report No. 27. The material below provides a brief overview of some of the issues related to echo canceller deployments in existing N-ISDN/PSTN networks.
Echo suppressors and echo cancellers are deployed in the existing PSTN and NISDN networks. Deployments are engineered by the network planners to ensure that the characteristics of each link meets network performance standards. Note that this may result in tandem connections each with their own echo cancellation/suppression devices. Echo suppressors are an older technology developed for analogue networks and specified in ITU-T Recommendation G.164. While echo cancellers can have analogue or digital interfaces and perform the echo subtraction using analogue or digital mechanisms, the term is commonly used to refer to those with digital interfaces and digital subtraction algorithms. More formally, these are Type C echo cancellers and they are described in ITU-T Recommendation G.165. Echo cancellation is the currently preferred approach for new deployments. 
Echo cancellation techniques are designed to remove echo from voice signals. Non voice services such as voice band data and facsimile can experience difficulties when operating in conjunction with echo cancellers (and even more so with echo suppressors). Inband tone signaling (2100Hz) is defined in G.164 and G.165 to permit modem manufacturers and end users to disable echo suppression and cancellation that may be present on a given connection. Separate tone conventions permit suppressors and cancellers to be turned off independently. Modems that include echo cancellers and facsimile protocols use these tone in various ways to achieve their best performance.
Network based echo arises from impedance mismatches in the network typically associated with the hybrid transformers associated with conversion between 2 wire and 4 wire analogue transmission systems. Echo signals become objectionable with increased levels and increased delays. For links with distance (delay) below a certain threshold (refer to ITU-T Recommendation G.131 and ANSI T1.508 for guidance), additional loss can be inserted to reduce the effects of echoes. Beyond this threshold echo suppression or echo cancellation techniques are recommended. 
The echo canceller performance is sensitive to the distance (delay) between the echo canceller device and the source(s) of the echo. Echo cancellation devices typically need to be correctly provisioned for this delay or else have some training or learning mechanisms to determine the best setting.
Acoustic echoes may also occur (e.g. in “speaker phone” or “hands free” telephony equipment) where there is acoustic coupling between the microphone and speaker's transducers. While the acoustic echo phenomenon is similar to network echo, there are a number of differences (e.g., levels, path loss, protection from howling etc.). Control of acoustic echoes is the responsibility of the digital telephone set manufacturer and public networks have not attempted to control for such echoes in the path. The increasing use of PCs equipped with sound cards as digital telephone sets will place additional requirements on the vendors of those equipment to support the necessary acoustic echo suppression. 
Appendix B - Interworking between AAL1 and AAL5 
(Informative)
Communication between a B-TE using AAL1 for voice and a B-TE using AAL5 for voice requires an interworking function. This specification does not define the details of such an interworking function. One consequence of interworking is the introduction of additional delay.
When mapping from AAL5 to AAL1 for voice there will be an additional cell construction delay of 5.875 ms plus the maximum CDV of the AAL5 connection in the IWF. Assuming a 40 octet fill CPCS-PDU for AAL5, the end-to-end delay would be 5 ms cell construction delay for AAL5 at the source plus CDV buffering delay and 5.875 ms cell reconstruction delay in the IWF plus the CDV delay of the AAL1 connection. Therefore, the total delay would be 10.875 ms plus CDV of AAL5 and AAL1 connections. 
When mapping from AAL1 to AAL5 for voice there will be an additional cell construction delay of 5 ms plus the maximum CDV of AAL1 connection in the IWF. Assuming a 40 octet fill CPCS-PDU for AAL5, the end-to-end delay would be 5.875 ms cell construction delay for AAL1 at the source plus CDV buffering delay and 5 ms cell reconstruction delay for AAL5 in the IWF plus the CDV delay of the AAL5 connection. Therefore, the total delay would be 10.875 ms plus CDV of AAL1 and AAL5 connections. 
Another consequence of interworking is that signalling information will need to be converted.
Appendix C - Interworking with H.320/H.321 terminals 
(Informative)
H.320 describes N-ISDN multimedia conferencing on N-ISDN using n  64 kbit/s service. H.321 describes N-ISDN multimedia conferencing (i.e., H.320 emulation) over ATM.
When performing a voice only call, an H.321 terminal behaves as a af-vtoa-0083 TE. The signalling parameters are described in A.3.2/H.321 for AAL1 for voice, and in B.5.2/H.321 for AAL5. They are the same as in section 2 of this specification.
On a call going from a af-vtoa-0083 TE to an H.321 terminal, the H.321 terminal will recognize from the signalling information in the SETUP message (e.g., the “transfer mode” in the Narrowband Bearer Capability information element) that the call is a af-vtoa-0083 call (i.e., a single channel voice only call) and will accept it as so. On an H.321 call going from an H.321 terminal to a af-vtoa-0083 TE, the af-vtoa-0083 TE will reject the call based on the unrecognized signalling information present in the SETUP message. The H.321 terminal can thus re-attempt the call as a af-vtoa-0083 call.
Appendix D - Required incremental subset of UNI Signalling 4.0 from UNI 3.1
(Informative)
“Voice and Telephony Over ATM to the Desktop” requires a  UNI signalling 4.0. However, the subset of the UNI Signalling 4.0 (af-sig-0061.000) capabilities necessary for VTOA to the Desktop (not already supported by UNI 3.1) is a relatively small subset of the overall UNI Signalling 4.0 capabilities. 
“Voice and Telephony Over ATM to the Desktop” is part of N-ISDN emulation and interworking. It requires the use of that subset of UNI signalling 4.0 capabilities. A voice call is encoded the same way it would be in N-ISDN, i.e., 64 kbit/s PCM encoded data (A-Law or µ-Law). The signalling capabilities were essentially ported over from Q.931 (which is the N-ISDN signalling access protocol).
This subset is part of ITU-T Recommendation Q.2931. UNI 3.1 is based on Q.2931, but it specifically excluded the N-ISDN emulation and interworking procedures of section 6/Q.2931 and Annex E/Q.2931. However, PNNI 1.0 (like UNI Signalling 4.0) supports the transport of the messages and information elements necessary for these procedures.
This appendix describes the signalling capabilities required over and above those of  UNI 3.1, and compares them to UNI Signalling 4.0 and PNNI 1.0 signalling capabilities.
Table D-1 summarizes which messages, information elements and codepoints are supported for various capabilities of VTOA to the Desktop by UNI Signalling 4.0, UNI 3.1 and PNNI 1.0. It also illustrates if the associated capabilities are mandatory or optional for VTOA to the Desktop. The subsequent sections describes Table D-1 in more details, and includes references to the associated procedures.
Table D-1 Messages and information elements support
Signalling message, information element or codepoint	Capability	UNI SIG 4.0	UNI 3.1	PNNI 1.0	VTOA desktop	
NOTIFY/Notification indicator	Notification procedures		-		Note 1	
PROGRESS/Progress indicator	Notification of interworking		-		M	
AAL for voice in AAL parameters	AAL negotiation		-		O	
Cause value #93	AAL negotiation		Note 2		M	
ALERTING	Call/connection alerting		-		M	
Narrowband bearer capability	N-ISDN service		-		M	
Narrowband low layer compatibility	N-ISDN service		-		O	
Narrowband high layer compatibility	N-ISDN service		-		O	
Called party number	DDI, MSN				O	
Called party subaddress	SUB				O	
Calling party number	CLIP, CLIR, MSN				O	
Calling party subaddress	CLIP				O	
Connected number	COLP, COLR		-		O	
Connected subaddress	COLP		-		O	
User-user information	UUS		-	Note 4	O	
AFI=x049 “Local ATM Format”	PNP Addressing	Note 3	O	
Messages, information elements or codepoint are supported ()	Mandatory capability (M)
Messages, information elements or codepoint are not supported (-)	Optional capability (O)
Note 1 - The Notification procedures are only necessary if adaptive timing recovery is used.
Note 2 - Cause values #78 and #93 have the same meaning in UNI 3.1
Note 3 - Not explicitly  mentioned, but in accordance with the principles of the specifications.
Note 4 - See section 8.8 on how UUS can be supported in PNNI.
D.1	Notification procedures
The NOTIFY message and Notification indicator information element are not supported in UNI 3.1, but are supported in PNNI 1.0, UNI Signalling 4.0 and Q.2931. UNI 3.1 is based on Q.2931, but it specifically excludes the notification procedures. The NOTIFY message is described in 3.1.10/Q.2931 and 6.3.1.9/PNNI 1.0. The Notification indicator information element is described in 4.5.23/Q.2931 (which refers back to 8.2.8/Q.932) and 6.4.5.27/PNNI 1.0 (which refers back to Q.2931). The notification procedures are described in 5.9/Q.2931 and 6.5.10/PNNI 1.0 (which refers back to Q.2931).
The notification procedures are used in VTOA to the Desktop to signal adaptive timing recovery for the transmit clock (see section 2.5.3). A new codepoint specific to VTOA Desktop “adaptive timing recovery used for the transmit (TX) clock” is used. The procedures are of end-to-end significance and the B-ISDN simply transports the Notification indicator information element in a NOTIFY or other message. This message may also be useful when interworking with N-ISDN (e.g., in conjunction with narrowband supplementary services).
D.2	Notification of interworking procedures (Progress)
The PROGRESS message and Progress indicator information element are not supported in UNI 3.1, but are supported in PNNI 1.0, UNI Signalling 4.0 and Q.2931. UNI 3.1 is based on Q.2931, but it specifically excludes the notification of interworking procedures. The PROGRESS message is described in 3.2.5/Q.2931 and 6.3.2.3/PNNI 1.0. The Progress indicator information element is described in 4.6.5/Q.2931 (which refers back to 4.5.23/Q.931) and in 6.4.7.4 (which refers back to Q.2931). The notification of interworking procedures are described in 6.6/Q.2931 and 6.5.11/PNNI 1.0.
The notification of interworking procedures are used to indicate interworking with other networks (analogue, private, etc.) and normally only require transport of the Progress indicator information element in a PROGRESS or other message through the B-ISDN. In some cases, it requires stopping some timers.
D.3	AAL negotiation
Two AALs are supported for 64 kbit/s: "AAL for voice" which is a very simplified version of AAL1, and AAL5.
 AAL negotiation procedures (2.5.4) are required. AAL negotiation procedures require the use of UNI Signalling 4.0 cause value #93, “AAL parameters cannot be supported”. UNI 3.1 has conflicting cause values assigned to “AAL parameters cannot be supported”: cause value #78 and cause value #93. To ensure compatibility, a terminal should treat reception of cause value #78 as cause value #93, and should generate cause value #93 instead of cause value #78.
D.4	Call/connection alerting
The ALERTING message is not supported in UNI 3.1, but is supported in PNNI 1.0, UNI Signalling 4.0 and Q.2931. UNI 3.1 is based on Q.2931, but it specifically excludes the ALERTING message. The ALERTING message is described in 3.2.1/Q.2931 and 6.3.2.1/PNNI 1.0. 
The ALERTING message is sent by a called terminal to the calling terminal to indicate that the called user is being alerted (i.e., that the phone is ringing). A PARTY ALERTING is also defined in 8.1.2.3/Q.2971 and 6.3.4.3/PNNI 1.0 for point-to-multipoint calls, but it is outside the scope of this specification. The ALERTING message is of end-to-end significance and the B-ISDN simply transport the message. Section 6.7.1.2/Q.2931 and section 6.5.2.5/PNNI 1.0 describes call/connection alerting procedures. 
Call/connection alerting also implies two call states for each side of the UNI for the state machine:
- Call delivered (U4): This state exists for an outgoing call when the calling user has received an indication that that remote user alerting has been initiated.
- Call received (U7): This state exists for an incoming call when the user has received a call establishment request but has not yet  responded. 
- Call delivered (N4): This state exists for an outgoing call when the network has indicated that the remote user alerting has been initiated.
- Call received (N7): This state exists for an incoming call when the network has received an indication that the user is alerting but has not yet received an answer. 
On the PNNI, the two call states are:
- Alerting delivered (NN4): This state exists when a succeeding side has sent an ALERTING message to the preceding side.
- Alerting received (NN7): This state exists when a preceding side has received an ALERTING message from the succeeding side of the PNNI. 
The support of ALERTING message and the call/connection alerting procedures are mandatory.
D.5	Narrowband bearer capability information element
The Narrowband bearer capability (N-BC) information element is not supported in UNI 3.1, but is supported in PNNI 1.0, UNI Signalling 4.0 and Q.2931. UNI 3.1 is based on Q.2931, but it specifically excludes the N-BC information element. The N-BC is described in 4.6.2/Q.2931 (which refers back to 4.5.5/Q.931) and 6.4.7.1/PNNI 1.0 (which refers back to Q.2931). 
The N-BC information element is essential for the support of any N-ISDN service, including VTOA to the Desktop. It is the information element used to signal that a N-ISDN service (e.g., 64 kbit/s PCM-encoded A-Law or µ-Law speech) is requested.
D.6	Narrowband high layer compatibility information element
The Narrowband high layer compatibility (N-HLC) information element is not supported in UNI 3.1, but is supported in PNNI 1.0, UNI Signalling 4.0 and Q.2931. UNI 3.1 is based on Q.2931, but it specifically excludes the N-HLC information element. The N-LLC is described in 4.6.3/Q.2931 (which refers back to 4.5.17/Q.931) and 6.4.7.2/PNNI 1.0 (which refers back to Q.2931). 
The N-HLC information element is not essential for the support of any N-ISDN service, including VTOA to the Desktop. It is of end-to-end significance and transported transparently by the B-ISDN. “Voice and Telephony Over ATM to the Desktop” does not make use of the N-HLC information element, but it could be used in the N-ISDN.
D.7	Narrowband low layer compatibility information element
The Narrowband low layer compatibility (N-LLC) information element is not supported in UNI 3.1, but is supported in PNNI 1.0, UNI Signalling 4.0 and Q.2931. UNI 3.1 is based on Q.2931, but it specifically excludes the N-LLC information element. The N-LLC is described in 4.6.4/Q.2931 (which refers back to 4.5.19/Q.931) and 6.4.7.3/PNNI 1.0 (which refers back to Q.2931). 
The N-LLC information element is not essential for the support of N-ISDN services. It is of end-to-end significance and transported transparently by the B-ISDN. “Voice and Telephony Over ATM to the Desktop” does not make use of the N-LLC information element, but it could be used in the N-ISDN.
D.8	UNI Signalling 4.0 supplementary services
Although only UNI Signalling 4.0 explicitly supports these supplementary services, most of them do not have any extra signalling requirements over what is in UNI 3.1 or PNNI 1.0 because they support the required messages and information elements. All these services are optional.
D.8.1	Direct Dialling In (DDI)
DDI uses the called address in the Called party number information element to route the call. Since delivery of the Called party number information element in the SETUP message is mandatory in both directions in UNI 3.1, UNI Signalling 4.0 and PNNI 1.0, there is no additional signalling requirements in to support DDI.
D.8.2	Multiple Subscriber Number (MSN)
MSN allows the use of more then one address for one endpoint using the called address in the Called party number information element to distinguish them. Since delivery of the called party number in the SETUP message is mandatory in both directions in UNI Signalling 4.0 and PNNI 1.0, there is no additional signalling requirements in to support MSN.
D.8.3	Calling Line Identification Presentation (CLIP)
Since the Calling party number and Calling party subaddress information elements are supported in UNI 3.1, there is no additional signalling requirements to support CLIP beyond including the Calling party number and possibly the Calling party subaddress information elements in the SETUP message.
D.8.4	Calling Line Identification Restriction (CLIR)
To restrict presentation of the calling party number at the called party, the calling party shall set the “presentation indicator” in the Calling party number information element to “presentation restricted”. To allow presentation of the calling party number at the called party, the calling party shall set the “presentation indicator” in the Calling party number information element to “presentation allowed”.
D.8.5	Connected Line Identification Presentation (COLP)
COLP requires the use of the Connected number and possibly the Connected subaddress information elements as defined in 5.8/Q.2951. UNI Signalling 4.0 and PNNI 1.0 support the Connected number and Connected subaddress information elements, but not UNI 3.1.
D.8.6	Connected Line Identification Restriction (COLR)
COLR requires the use of the Connected number information element as defined in 5.8/Q.2951. UNI Signalling 4.0 and PNNI 1.0 support the Connected number information element, but not UNI 3.1.
To restrict presentation of the connected number at the calling party, the connected party shall set the “presentation indicator” in the Connected party number information element to “presentation restricted”. To allow presentation of the connected number at the calling party, the connected party shall set the “presentation indicator” in the Connected number information element to “presentation allowed”.
D.8.7	Subaddressing (SUB)
SUB uses the called subaddress in the Called party subaddress information element to expand the addressing capabilities beyond the normal capabilities provided by the B-ISDN numbering plan. Since the Called party subaddress information element is supported in UNI 3.1, there is no additional signalling requirements to support SUB beyond including the Called party subaddress information element in the SETUP message.
D.8.8	User-to-user signalling (UUS) Service 1
UUS requires the use of the User-user information information element as described in Q.2957.1. UUS is not supported in either UNI 3.1 or PNNI 1.0, but is supported in UNI Signalling 4.0. However, UUS could be supported at the PNNI with the use of the pass along indicator.
Appendix E - Protocol Implementation Conformance Statement (PICS) Proforma
(Normative)
E.1	Introduction
To evaluate conformance of a particular implementation, it is necessary to have a statement of which capabilities and options have been implemented for a given protocol. Such a statement is called a Protocol Implementation Conformance Statement (PICS).
E.1.1	Scope
This document provides the PICS proforma for the Voice and Telephony Over ATM to the Desktop Specification as described in af-vtoa-0083.001, in compliance with the relevant requirements, and in accordance with the relevant guidelines, given in ISO/IEC 9646-2[4].
E.1.2	Definitions
This document uses the following terms defined in ISO/IEC 9646-1 [3]:
A Protocol Implementation Conformance Statement (PICS) is a statement made by the supplier of an implementation or a system, stating which capabilities have been implemented for given protocol.
A PICS Proforma is a document in the form of a questionnaire, designed by the protocol specifier or the conformance test suite specifier, which when completed for an implementation or a system, becomes the PICS.
A static conformance review is a review of the extent to which the static conformance requirements are met by the IUT, accomplished by comparing the PICS with the static conformance requirements expressed in the relevant protocol specification.
E.1.3	Symbols and Conventions
IE	Information Element
IUT	Implementation Under Test
M	Mandatory
O	Option (may be selected to suit the implementation, provided that any requirements applicable to the options are observed)
O.n	Options, but support is required for either at least one or only one of the options in the group labeled with the same numeral  n .
SUT	System Under Test 
E.1.4	Conformance
The supplier of a protocol implementation which is claimed to conform to af-vtoa-0083.001 is required to complete a copy of the PICS proforma provided in the following sections of this document and is required to provide the information necessary to identify both the supplier and the implementation.
E.2	Identification of the Implementation

IUT Identification
IUT Name:	
	
IUT Version: 

System Under Test
SUT Name:	
	
Hardware Configuration: 	
	
Operating  System: 	

Product Supplier
Name: 	
Address: 	
	
Telephone Number: 	
Facsimile Number: 	

Additional Information:	

Client
Name:	
Address:	
	
Telephone Number: 	
Facsimile Number: 	
Additional Information: 	

PICS Contact Person
Name:	
Address: 	
	
Telephone Number:	
Facsimile Number: 	
Additional Information: 	
E.3	PICS Proforma for af-vtoa-0083.001
E.3.1	Global Statement of Conformance
The implementation described in this PICS meets all of the mandatory requirements of the protocol specification.
	__Yes
	__No
Note: Answering  No  indicates non-conformance to the protocol specification. Non-supported mandatory capabilities are to be identified in the following tables, with an explanation in the comments section of each table as to why the implementation is non-conforming.
E.3.2	Instructions for Completing the PICS Proforma
Each question in this section refers to a major function of the protocol. Answering  Yes  to a particular question states that the implementation supports all of the mandatory procedures for that function, as defined in the referenced section of af-vtoa-0083.001. Answering  No  to a particular question in this section states that the implementation does not support that function of the protocol.
A supplier may also provide additional information, categorized as exceptional (X) or supplementary information. This additional information should be provided in the Support column as items labeled X<I> for exceptional or S<I> for supplementary information, respectively for cross-reference purposes, where <I> is any unambiguous number.
E.3.3	Native ATM terminal equipment
Index	Protocol feature	Condition for Status	Status Pred.	Ref.	Support	
BTE. 1	Does the IUT support AAL1 for voice for the user plane information?		O	2.4.3	Yes__	No__
X__	S__	
BTE. 2	Does the IUT support AAL5 for the user plane information?		M	2.4.3	Yes__	No__
X__	S__	
BTE. 3	Does the IUT support a null SSCS in the message mode service for AAL5 transport of the user plane information?	BTE. 2=y	M	2.4.3.1	Yes__	No__
X__	S__	
BTE. 4	Does the IUT support a CPCS-PDU payload of 8, 16, 24, 32 or 40 octets for user plane information?	BTE. 2=y	M	2.4.3.1	Yes__	No__
X__	S__	
BTE. 5	Does the IUT support a preferred maximum CPCS-PDU size of 40 octets?	BTE. 2=y	O	2.4.3.1	Yes__	No__
X__	S__	
BTE. 6	Does the IUT set the CPCS-UU to 00000000 for user plane information?	BTE. 2=y	M	2.4.3.1	Yes__	No__
X__	S__	
BTE. 7	When the IUT receives a corrupted AAL5 CPCS-PDU, does it pass the corrupted data to the higher layers?	BTE. 2=y	M	2.4.3.1	Yes__	No__
X__	S__	
BTE. 8	Is the IUT capable of receiving both G.711 -Law and A-Law signals?		M	2.4.4	Yes__	No__
X__	S__	
BTE. 9	Is the IUT capable of sending G.711 -Law signals?		O.1 	2.4.4	Yes__	No__
X__	S__	
BTE. 10	Is the IUT capable of sending G.711 A-Law signals?		O.1	2.4.4	Yes__	No__
X__	S__	
BTE. 11	Does the IUT conform to the mandatory requirements of UNI SIG 4.0 (af-sig-0061.000)?		M	4.11/UNI SIG 4.0	Yes__	No__
X__	S__	
BTE. 12	Does the IUT support the Notification indicator IE, NOTIFY message and notification procedures?		O	5.9/
Q.2931	Yes__	No__
X__	S__	
BTE. 13	Does the IUT support the signalling procedures of section 6/Q.2931 as modified by UNI SIG 4.0?		M	2.5.1	Yes__	No__
X__	S__	
BTE. 14	Does the IUT support the ALERTING message and the associated alerting procedures?		M	3.2.1/
Q.2931	Yes__	No__
X__	S__	
BTE. 15	Does the IUT support the Narrowband Bearer capability IE as described in 6.2.2/Q.2931?		M	2.5.1	Yes__	No__
X__	S__	
BTE. 16	Does the IUT support the Narrowband high layer compatibility IE?		O	4.6.3/
Q.2931	Yes__	No__
X__	S__	
BTE. 17	Does the IUT support the Narrowband low layer compatibility IE?		O	4.6.4/
Q.2931	Yes__	No__
X__	S__	
BTE. 18	Does the IUT support the Broadband bearer capability IE as described?		M	2.5.1	Yes__	No__
X__	S__	
BTE. 19	Does the IUT support the ATM traffic descriptor IE as described?		M	2.5.1	Yes__	No__
X__	S__	
BTE. 20	Does the IUT support the Quality of service parameters IE as described?		M	2.5.1	Yes__	No__
X__	S__	
BTE. 21	Does the IUT support the AAL parameters IE as described?		M	2.5.1	Yes__	No__
X__	S__	
BTE. 22	Does the IUT support the Progress indicator IE and PROGRESS message?		M	2.5.1 	Yes__	No__
X__	S__	
BTE. 23	Does the IUT support the user-related procedures of 6.7/Q.2931?		M	2.5.1	Yes__	No__
X__	S__	
BTE. 24	Does the IUT support the DDI supplementary service?		O	2.5.2.1	Yes__	No__
X__	S__	
BTE. 25	Does the IUT support the MSN supplementary service?		O	2.5.2.1	Yes__	No__
X__	S__	
BTE. 26	Does the IUT support the CLIP supplementary service?		O	2.5.2.1	Yes__	No__
X__	S__	
BTE. 27	Does the IUT support the CLIR supplementary service?		O	2.5.2.1	Yes__	No__
X__	S__	
BTE. 28	Does the IUT support the COLP supplementary service?		O	2.5.2.1	Yes__	No__
X__	S__	
BTE. 29	Does the IUT support the COLR supplementary service?		O	2.5.2.1	Yes__	No__
X__	S__	
BTE. 30	Does the IUT support the SUB supplementary service?		O	2.5.2.1	Yes__	No__
X__	S__	
BTE. 31	Does the IUT support the UUS Service 1 supplementary service?		O	2.5.2.1	Yes__	No__
X__	S__	
BTE. 32	Does the IUT support physical layer synchronization to a network clock?		O.2	4.3	Yes__	No__
X__	S__	
BTE. 33	Does the IUT support the adaptive timing recovery procedures?	BTE. 32=n	O.2	4.3	Yes__	No__
X__	S__	
BTE. 34	Does the IUT support the Notification of adaptive timing recovery procedures?	BTE. 33=y
BTE. 12=y	M	2.5.3	Yes__	No__
X__	S__	
BTE. 35	Does the IUT support a free-running clock?	BTE. 32=n
BTE. 33=n	O.2	4.3	Yes__	No__
X__	S__	
BTE. 36	If the IUT receives a setup request indicating AAL1 for voice, will it reject the call with cause #93? 	BTE. 1=n	M	2.5.4	Yes__	No__
X__	S__	
BTE. 37	If the IUT receives cause #93 in a rejected call, will it re-attempt the call using AAL5?		O	2.5.4	Yes__	No__
X__	S__	
BTE. 38	Will the IUT treat cause #78 the same as it treats cause #93?		M	2.5.4	Yes__	No__
X__	S__	
Comment(s)
O.1 = At least one of these options must be supported.
O.2 = At least one of these options must be supported.						
E.3.4	Interworking function
Index	Protocol feature	Condition for Status	Status Pred.	Ref.	Support	
IWF. 1	Does the ATM interface conform to the mandatory requirements of UNI SIG 4.0?	IWF. 2=n	O.1	3.2	Yes__	No__
X__	S__	
IWF. 2	Does the ATM interface conform to the mandatory requirements of PNNI 1.0?	IWF. 1=n	O.1	3.2	Yes__	No__
X__	S__	
IWF. 3	Is the N-ISDN interface a T or coincident S and T reference point?	IWF. 1=y
IWF. 4=n	O.2	3.2	Yes__	No__
X__	S__	
IWF. 4	Is the N-ISDN interface a Q reference point?	IWF. 3=n	O.2	3.2	Yes__	No__
X__	S__	
IWF. 5	Are the signalling protocols fully terminated at the IUT?	IWF. 6=n	O.3	3.4.2	Yes__	No__
X__	S__	
IWF. 6	Are the signalling protocols mapped at the IUT?	IWF. 5=n	O.3	3.4.2	Yes__	No__
X__	S__	
IWF. 7	Does the IUT support AAL1 for voice for the user plane information?		O
Note 1	3.3.4	Yes__	No__
X__	S__	
IWF. 8	Does the IUT support AAL5 for the user plane information?		M	3.3.4	Yes__	No__
X__	S__	
IWF. 9	Does the IUT support a null SSCS in the message mode service for AAL5 transport of the user plane information?	IWF. 8=y	M	3.3.4.1	Yes__	No__
X__	S__	
IWF. 10	Does the IUT support a CPCS-PDU payload of 8, 16, 24, 32 or 40 octets for user plane information?	IWF. 8=y	M	3.3.4.1	Yes__	No__
X__	S__	
IWF. 11	Does the IUT support a preferred maximum CPCS-PDU size of 40 octets for user plane information?	IWF. 8=y	O	3.3.4.1	Yes__	No__
X__	S__	
IWF. 12	Does the IUT set the CPCS-UU to 00000000 for user plane information?	IWF. 8=y	M	3.3.4.1	Yes__	No__
X__	S__	
IWF. 13	When the IUT receives a corrupted AAL5 CPCS-PDU, does it pass the corrupted data to the higher layers?	IWF. 8=y	M	3.3.4.1	Yes__	No__
X__	S__	
IWF. 14	Is the IUT capable of receiving both G.711 -Law and A-Law signals?		M	3.3.5	Yes__	No__
X__	S__	
IWF. 15	Is the IUT capable of sending G.711 -Law signals?		O.4	3.3.5	Yes__	No__
X__	S__	
IWF. 16	Is the IUT capable of sending G.711 A-Law signals?		O.4	3.3.5	Yes__	No__
X__	S__	
IWF. 17	Are the content of IEs common to both the B-ISDN and N-ISDN passed unchanged  (except as per this specification)?		M	3.4.2	Yes__	No__
X__	S__	
IWF. 18	Does the N-ISDN use only overlap sending/receiving?		O	3.4.2.3	Yes__	No__
X__	S__	
IWF. 19	Does the IUT perform the necessary digit collection?	IWF. 18=y	M	3.4.2.3	Yes__	No__
X__	S__	
IWF. 20	In the N-ISDN to B-ISDN direction, does the IUT generate instruction indicators as per the guidelines of Appendix I/Q.2931?		M	3.4.2.4	Yes__	No__
X__	S__	
IWF. 21	In the B-ISDN to N-ISDN direction, does the IUT conform to 5.7 and 5.8/Q.2931 (for UNI) or 6.5.7 and 6.5.8/PNNI 1.0 (for PNNI) ?		M	3.4.2.4	Yes__	No__
X__	S__	
IWF. 22	Does the IUT conform to the call clearing procedures of 3.4.2.5 (excluding 3.4.2.5.1)?	IWF. 5=n	M	3.4.2.5	Yes__	No__
X__	S__	
IWF. 23	Does the IUT conform to the call clearing collisions procedures of 3.4.2.5.1?	IWF. 5=n	M	3.4.2.5.1	Yes__	No__
X__	S__	
IWF. 24	Is the CONNECT ACKNOWLEDGE not supported at the Q reference point?	IWF. 2=y
IWF. 5=n	O	3.4.2.6.2	Yes__	No__
X__	S__	
IWF. 25	Does the IUT ignore a N-ISDN CONNECT ACKNOWLEDGE message?	IWF. 24=n	M	3.4.2.6.2	Yes__	No__
X__	S__	
IWF. 26	Does the IUT respond to a N-ISDN CONNECT message with a locally-generated N-ISDN CONNECT ACKNOWLEDGE message	IWF. 24=n
IWF. 5=n	M	3.4.2.6.2	Yes__	No__
X__	S__	
IWF. 27	Does the IUT not support timer T313?	IWF. 5=n	M	3.4.2.6.2	Yes__	No__
X__	S__	
IWF. 28	Does the IUT support the restart procedures locally as described in 3.4.2.7?		M	3.4.2.7	Yes__	No__
X__	S__	
IWF. 29	Does the IUT pass N-ISDN codeset 4, 5, 6 and 7 IEs to B-ISDN?		M	3.4.2.8	Yes__	No__
X__	S__	
IWF. 30	Does the IUT generate the ATM traffic descriptor IE as described?		M	3.4.2.8	Yes__	No__
X__	S__	
IWF. 31	Does the IUT generate the AAL parameters IE as described?		M	3.4.2.8	Yes__	No__
X__	S__	
IWF. 32	Does the IUT perform the mapping between the Connection identifier and Channel identifier IEs?	IWF. 5=n	M	3.4.2.8.1	Yes__	No__
X__	S__	
IWF. 33	Does the IUT support physical layer synchronization to the N-ISDN clock?		M	4.2	Yes__	No__
X__	S__	
IWF. 34	If the N-ISDN is not synchronized to the PRS, is a Stratum 4 clock used (at a minimum)?		M	4.2	Yes__	No__
X__	S__	
IWF. 35	Does the IUT have the ability to receive cell streams from unsynchronized sources?		M	4.2	Yes__	No__
X__	S__	
IWF. 36	Upon receipt of a setup request indicating AAL1 for voice, will the IUT reject the call with cause #93? 	IWF. 7=n	M	3.4.4	Yes__	No__
X__	S__	
IWF. 37	If the IUT receives cause #93 in a rejected call, will it re-attempt the call using AAL5?		O	3.4.4	Yes__	No__
X__	S__	
IWF. 38	Will the IUT treat cause #78 the same as it treats cause #93?		M	3.4.4	Yes__	No__
X__	S__	
Comment(s)
O.1 = One of these options must be supported.
O.2 = One of these options must be supported.
O.3 = One of these options must be supported.
O.4 = At least one of these options must be supported.
Note 1 - May be mandatory if the UNI is a public UNI.						
Appendix F - Summary of changes between af-vtoa-0083.000 and af-vtoa-0083.001
(Informative)
This section summarizes the changes between af-vtoa-0083.000 and af-0083.001.
The content of section 6 has been superseded by a new ATM specification on addressing. See section 6 for more details.
The following annexes are new:
Annex C - Interworking with H.320/H.321 terminals
Annex D - Required incremental subset of UNI Signalling 4.0 from UNI 3.1 (already available as the VTOA “Implementation Tip Sheet”
Annex E - Protocol Implementation Conformance Statement (PICS) Proforma
Annex F - Summary of changes between af-vtoa-0083.000 and af-vtoa-0083.001