Technical Committee ATM Trunking using AAL2 for Narrowband Services AF-VTOA-0113.000 February, 1999 (c) 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 Contents 1. INTRODUCTION 1 1.1 OBJECTIVES 1 1.2 SCOPE 1 1.3 ABBREVIATIONS 1 1.4 REFERENCE MODEL 3 1.5 TRUNKING MODES 4 1.5.1 Switched Trunking 4 1.5.2 Non-Switched Trunking 4 1.6 APPLICATIONS 4 1.6.1 Access Trunking to the Public Switched Telephone Network (PSTN) 4 1.6.2 PBX-PBX Trunking 5 1.7 SPEECH ENCODING 5 1.8 ENHANCED SERVICES 6 1.9 PROTOCOL ARCHITECTURE 6 1.10 USER BENEFITS 6 1.11 IWF FUNCTIONALITY 7 1.12 REFERENCES 9 1.12.1 Normative 9 1.12.2 Informative 10 2. INTERFACES SUPPORTED 11 2.1 NARROWBAND INTERFACES 11 2.1.1 Physical Layer 11 2.1.2 Signalling 11 2.1.2.1 CAS 11 2.1.2.2 CCS 11 2.2 ATM INTERFACES 11 2.2.1 Physical Layer 11 2.2.2 Adaptation Layer 11 2.2.3 Signalling Layer 11 3. CAPABILITIES SUPPORTED 12 3.1 IWF-IWF COMMUNICATION 12 3.2 SIGNALLING 12 3.2.1 Signalling Termination 12 3.2.1.1 Control Information Via CCS 12 3.2.1.2 Control Information Via CAS with DTMF and interworking to CCS 14 3.2.2 Transport of Signalling without Termination 15 3.2.2.1 Control Information Via CAS with DTMF 15 3.2.2.2 Control Information Via CCS 16 3.3 ROUTING 18 3.4 VOICE ENCODING SUPPORT 18 3.4.1 Types of Encoding Supported 18 3.4.2 Selection and Changing of Encoding 18 3.5 IDLE CHANNEL SUPPRESSION 18 3.5.1 Idle Call State Determination 18 3.5.2 Idle Code Detection 19 3.6 SILENCE DETECTION AND REMOVAL 19 3.7 ECHO CANCELLATION 19 3.8 NON-CONTROL SIGNALLING DTMF TRANSPORT 20 3.8.1 Use of higher bit-rate encoding 20 3.8.2 Transfer by dialled digits packets 20 3.9 TRANSPORT OF VOICEBAND DATA 20 4. CONTROL OF ATM VCCS AND AAL2 CHANNELS 21 4.1 VCC CHARACTERISTICS 21 4.1.1 Application Identifier (AppId) 21 4.1.2 VCC Identifier (VCCI) 21 4.1.3 Signalling VCC Identifier (SigVCCI) 22 4.1.4 Default SSCS Type 22 4.1.5 Default SSCS Parameter Values 22 4.1.6 AAL2 CPS Parameter Values 22 4.1.7 AAL5 Parameter Values 22 4.2 PROVISIONING PVCS 22 4.3 SIGNALING OF SVCS 23 4.3.1 AppId 23 4.3.2 VCCI 23 4.3.3 SigVCCI 23 4.3.4 Default SSCS Type 23 4.3.5 Default SSCS Parameter Values 23 4.3.6 AAL2 CPS Parameter Values 23 4.3.7 AAL5 Parameter Values 24 4.3.8 Error Conditions 24 4.3.9 Redundant SVC Handling 24 4.4 ESTABLISHMENT AND RELEASE OF AAL2 CHANNELS 24 4.4.1 CID Assignment 24 4.4.1.1 CID Allocation 24 4.4.1.2 CID Association 25 4.4.1.3 CID Selection and Glare Minimization 25 4.4.2 AAL2 Channel Association Procedures 25 4.4.2.1 Non-Switched Mode 25 4.4.2.2 Switched Mode 25 5. NARROWBAND SIGNALLING PROCEDURES 26 5.1 CHANNEL ASSOCIATED SIGNALLING 26 5.1.1 Supervision Signalling 26 5.1.2 Address Signalling 26 5.2 COMMON CHANNEL SIGNALLING 26 5.3 DETECTION/REMOVAL OF IDLE CHANNELS BASED ON SIGNALLING 27 5.3.1 Switched Trunking Mode 27 5.3.2 Non-switched Trunking Mode 27 5.4 TRANSPORT OF SIGNALLING WITHOUT TERMINATION 27 5.4.1 CAS ABCD Bits Transport 27 5.4.2 CCS Information Transport 28 5.4.2.1 CCS Information Transport Using AAL5 28 5.4.2.2 CCS Information Transport Using AAL2 29 5.5 GLARE HANDLING 29 6. ALARMS AND STATUS 30 6.1 NON SWITCHED TRUNKING MODE 30 6.1.1 Faults Detected on the Narrowband Interface 30 6.1.2 Detection of AAL2 Connectivity Faults 31 6.1.3 Detection of ATM Connectivity Faults 31 6.2 SWITCHED TRUNKING MODE 32 6.2.1 Faults Detected on the Narrowband Interface 32 6.2.2 Detection of AAL2 Connectivity Faults 32 6.2.3 Detection of ATM Connectivity Faults 33 7. VOICE COMPRESSION HANDLING PROCEDURES 34 7.1 ENCODING ALGORITHMS 34 7.2 SELECTION OF ENCODING 34 7.2.1 Default Profile for an IWF 34 7.2.2 Default Profile for Each VCC 34 7.2.3 Selection of Profile Entry 34 7.3 SILENCE REMOVAL AND COMFORT NOISE GENERATION 34 7.3.1 Detection 34 7.3.2 Removal and Comfort Noise Generation 34 7.3.3 Start of Talk Spurt 35 7.4 SPECIAL HANDLING OF INBAND SIGNALS 35 7.4.1 Modem Detection 35 7.4.2 DTMF 35 7.4.2.1 Operation of the Originating Side IWF 35 7.4.2.2 Operation of the Destination Side IWF 36 8. ENHANCED TRANSPORT 37 8.1 FAX DEMODULATION AND REMODULATION (FAX RELAY) 37 8.2 CIRCUIT MODE DATA N X 64 KBIT/S 37 8.3 FRAME MODE DATA 37 9. PERFORMANCE CONSIDERATION 38 9.1 PACKET DELAY VARIATION 38 9.2 TIMING CONSIDERATIONS 38 ANNEX A: NON-ITU-T STANDARD ALGORITHMS 39 ANNEX B: ATM FORUM PREDEFINED PROFILES 42 ANNEX C: INFORMATION ELEMENT CONTENTS 44 Preface This specification uses three levels for indicating the degree of compliance necessary for specific functions, procedures, or coding. They are indicated by the use of key words as follows: * Requirements: "Shall" indicates a required function, procedures or coding necessary for compliance. In some cases "shall" used in text indicates a conditional requirement, since the operation described is dependent on whether or not an objective or option is chosen. * Objective: "Should" indicates an objective which is not required for compliance, but which is considered desirable. * Option: "May" indicates an optional operation without implying a desirability of one operation over another. That is, it identifies an operation that is allowed while still maintaining compliance. * 1. Introduction 1.1 Objectives The ATM Trunking using AAL2 for Narrowband Services described in this specification fulfills an urgent market need for an efficient transport mechanism to carry voice, voice-band data, circuit mode data, frame mode data, and fax traffic. Voice transport will include support for compressed voice and non-compressed voice together with silence removal. 1.2 Scope This specification describes the procedures and signalling required to support the efficient transport of narrowband services across an ATM network between two Interworking Functions (IWF) to interconnect pairs of non-ATM trunks. It specifies the use of ATM virtual circuits with AAL2 to transport bearer information and ATM virtual circuits with AAL2 or AAL5 to transport CCS. The virtual circuits used may be PVCs, SPVCs, or SVCs. The specification supports the transport of common channel signalling (CCS) information as well as channel associated signalling (CAS) information. ATM trunking using AAL2 provides both switched and non-switched services to the narrowband network. The scope of this specification is to define the following * The functionality of an IWF * Relationship between the individual functions comprising an IWF * Relevant control plane aspects of ATM trunking using AAL2 * Relevant management plane aspects * Timing and synchronization requirements specific to ATM trunking This specification does not address procedures or signalling that might be required to support the "AAL2 switching" function that is currently under study in SG11, which is intended to allow an intermediate point to switch individual AAL2 packets between different VCCs. When such a capability is recommended by the ITU-T, support for it may be added to a later version of this specification. An IWF complying with in this specification shall conform to all procedures described in I.366.2. 1.3 Abbreviations The following abbreviations as used in this specification: AAL2 ATM Adaptation Layer type 2 AAL5 ATM Adaptation Layer type 5 AAL2 VCC An ATM VCC using AAL2 AAL5 VCC An ATM VCC using AAL5 ADT Assured Data Transfer AIS Alarm Indication Signal AppId APPlication ID ATC ATM Transfer Capability ATM Asynchronous Transfer Mode BCOB-X Broadband Connection Oriented Bearer - subcategory X B-HLI Broadband - High Layer Information CAS Channel Associated Signalling CC Continuity Check CCS Common Channel Signalling CES Circuit Emulation Service CID AAL2 Channel Identifier CLP Cell Loss Priority CO Central Office CPCS Common Part Convergence sublayer CPCS-CI CPCS - Congestion Indication CPCS-LP CPCS - Loss Priority CPCS-UU CPCS - User-to-User indication CPS Common Part Sublayer CVSD Continuously Variable Slope Delta DB-CES Dynamic Bandwidth - CES DPNSS1 Digital Private Network Signalling System number 1 DSS2 Digital subscriber Signalling System number 2 DTMF Dual Tone Multi-frequency FAX Facsimile FM Frequency Modulation FCS Frame Check Sequence GIT Generic Identifier Transport HDLC High-level Data Link Control HDLC-F HDLC - Framing ID Identifier IE Information Element ISDN Integrated Services Digital Network IWF Interworking Function LCD Loss of Cell Delineation LOF Loss Of Frame LOMF Loss Of Multi-Frame LOS Loss Of Signal LPC Linear Predictive Coding MBS Maximum Burst Size MFRAI Multi-Frame RAI N-ISDN Narrowband - ISDN nrt-VBR Non Real Time - VBR OAM Operation Administration and Maintenance OUI Organizational Unit Identifier PBX Private Branch eXchange PDU Protocol Data Unit PCM Pulse Code Modulation PDV Packet Delay Variation PRS Primary Reference Source PSS1 Private Signalling System number 1 PSTN Public Switched Telephone Network PVC Permanent Virtual Circuit QoS Quality Of Service RAI Remote Alarm Indication RDI Remote Defect Indication rt-VBR Real Time - VBR SAAL Signalling ATM Adaptation Layer SAR Segmentation And Reassembly SCR Sustainable Cell Rate SDH Synchronous Digital Hierarchy SDU Service Data Unit SID Silence Insertion Descriptor SONET Synchronous Optical NETwork SPVC Soft Permanent Virtual Circuit SSCF Service Specific Coordination Function SSCOP Service Specific Connection Oriented Protocol SSCS Service Specific Convergence Sublayer SSSAR Service Specific SAR SSTED Service Specific Transmission Error Detection SSTED-CI SSTED - Congestion Indication SSTED-LP SSTED - Loss Priority SSTED-UU SSTED - User-to-User indication SVC Switched Virtual Circuit TED Transmission Error Detection TDM Time Division Multiplexing UNI User Network Interface VBR Variable Bit Rate VCC Virtual Channel Connection (used where it may be a PVC, SPVC, or SVC) VCCI VCC Identifier 1.4 Reference Model This specification is intended to support a broad range of applications involving interconnection of an IWF with narrowband and broadband facilities and interworking with various other telecommunications devices including PBXs, ATM network switches, and far-end IWFs. Figure 1 shows the reference model for ATM trunking using AAL2 for narrowband services. Figure 1: The Reference Model; ATM Trunking Using AAL2 for Narrowband Services The IWF described in this specification is a functional unit, which may be implemented as a stand-alone device, as a part of a larger device, or distributed among several devices. This specification does not dictate the implementation of any one of these configurations. The Reference Model shown in Figure 1 may include various telecommunications devices. The networks at the narrowband side may be PBXs or public or private networks of switches and may connect to an IWF via one or more physical interfaces. These physical interfaces may be based on ISDN common channel signalling (CCS) or may utilize channel associated signalling (CAS). The ATM network may be a full network, a single ATM switching element, or simply a direct interconnection between a pair of IWFs. The virtual circuits through the ATM network shall be SVCs, PVCs, or SPVCs carrying: * bearer traffic and CAS using AAL2 * CCS using AAL2 or AAL5 The IWFs in this reference architecture provide capabilities that may be categorized as switched or non-switched in operation. 1.5 Trunking Modes This specification covers both switched trunking and non-switched trunking. 1.5.1 Switched Trunking Switched trunking involves analysis of the signalling that accompanies an incoming narrowband call and routing of its bearer information to an AAL2 channel within a VCC between IWFs. Similar analysis and routing is required for incoming calls from the ATM network as well. After the narrowband call has ended, subsequent calls occupying the same narrowband channel (TDM timeslot) may be switched to different AAL2 channels and VCCs. In other words, there is no permanent relationship between a narrowband channel and an AAL2 channel. 1.5.2 Non-Switched Trunking In non-switched trunking, the information stream of a narrowband channel is always carried on the same AAL2 channel within the same VCC and vice-versa. In other words, there is a permanent correspondence between a narrowband channel and the AAL2 channel and VCC designated for its support. Non-switched trunking involves no termination of signalling and no routing of narrowband calls in the IWFs. This trunking mode also applies in cases in which there is no narrowband signalling. 1.6 Applications This specification may be used for different applications. The following subsections describe two possible applications. 1.6.1 Access Trunking to the Public Switched Telephone Network (PSTN) This application example, as depicted in Figure 2, connects a PBX to a public network to provide access to that network's services. A typical use would be to provide concentration of a large number of narrowband channels over a broadband facility. The broadband facility between IWFs may be any that provides ATM functionality, such as a direct physical connection (fiber), a SONET ring, or a full ATM network. The IWFs may operate in either the switched or non-switched trunking mode. Figure 2: Access to the Public Switched Telephone Network (PSTN) by a PBX 1.6.2 PBX-PBX Trunking This application example, as depicted in Figure 3, uses multiple IWFs to provide switched trunking between PBXs. A group of IWFs are interconnected by an ATM network to form a network of IWFs. PBX connectivity is achieved by establishing one or more ATM VCCs using AAL2 between each pair of IWFs that need to communicate. Figure 3: PBX-PBX Trunking 1.7 Speech Encoding An IWF should support standard speech encoding schemes. Changes within a family of related algorithms should be possible with no disruption in the audio. An IWF should support silence removal, i.e., suppression of the transfer of AAL2 packets during silent intervals and insertion of the appropriate background noise at the distant end. An IWF should support conversion between 64 kbit/s PCM (from the narrowband side) and any of the supported encodings on the ATM side. 1.8 Enhanced Services An IWF may provide special capabilities to transport the following: * Voice band data through modem detection * Fax data through demodulation and remodulation * Circuit mode data for N x 64 kbit/s channels * DTMF information through DTMF packets * Frame mode data through SAR functionality 1.9 Protocol Architecture Figure 4 depicts the manner in which the services listed above are supported by the various portions of the ATM protocol architecture. Figure 4: ATM Protocols that Support the Services 1.10 User Benefits A major benefit of ATM trunking using AAL2 for narrowband services is bandwidth savings. It can be achieved in these ways: * by compressing voice - bandwidth allocation is less per call * by releasing bandwidth when the voice application does not need it - when the talker is silent or when call is completed * by routing and switching narrowband calls on a per call basis The following table summarizes the benefits of different VTOA trunking specifications. Voice Compression Silence Removal Idle Channel Suppression Switched Concentration CES - - - - DB-CES - - ( - ATM trunking using AAL1 for narrowband services - - ( ( ATM trunking using AAL2 for narrowband services ( ( ( ( 1.11 IWF Functionality The functionality of the IWF described in this specification is depicted in Figure 5. This is intended to be illustrative and does not imply any particular implementation. Figure 5 : IWF Functionality An IWF includes the following functions: * Multiplexer/Demultiplexer function, to combine individual narrowband channels from the Switch into suitable multiplexers for outgoing transmission over the TDM interfaces and to recover the individual narrowband channels from the incoming transmission multiplexes for presentation to the Switch * Switch function, to allow any individual channel from the narrowband interface to be connected, on a call-by-call basis, to any individual AAL2 channel * Signalling Termination, to receive signalling from and insert signalling into both the TDM narrowband and the ATM broadband interfaces * Call Handling, to interpret the call set-up and release signals from the connected narrowband and broadband equipment including selection of the destination for each call * SSCS User functions, including e.g. voice codecs for speech compression and Fax demodulation/remodulation units * AAL2 SSCS functions, to format User information into packets for transport on AAL2 connections * AAL2 CPS functions, for multiplexing AAL2 connections into ATM cells * VCC Management, to allocate and deallocate VCCs to distant IWFs as needed to support the traffic * SAAL functions (comprising SSCF + SSCOP + AAL5 CPCS) to permit signalling information to be exchanged with the distant peer IWF * CID Management, to maintain a record of the status of allocated CID values per AAL2 VCC The operation of the IWF, in terms of the functionality depicted in Figure 5, is described in the following paragraphs for the case of switched trunking. In the case of non-switched trunking, the Signalling Termination and Call Handling function is null and signalling and bearer information is passed through the IWF according to a fixed mapping of narrowband time slots to AAL2 channels. E1/DS1 TDM trunks terminate on a Multiplexer/Demultiplexer function, which distributes the individual 64 kbit/s channels between the trunks and the Switch function. The narrowband signalling associated with the individual 64 kbit/s channels, whether out-of band or -in-band is extracted via the Switch by the Signalling Termination and Call Handling function. The Signalling Termination and Call Handling function performs a routing process, based on the signalling information, to control the Switch such that the 64 kbit/s channels appear on the desired output ports associated with either the TDM domain or the ATM domain as appropriate. Signalling Termination and Call Handling also exchanges signalling concerning narrowband calls with the peer Signalling Termination and Call Handling function in the distant IWF. Transfer of this IWF-IWF signalling information is effected over a separate AAL5 VCC via an appropriate SSCS (SSCF + SSCOP). Alternatively, this signalling information may be exchanged over an AAL2 connection. The alternative involves the Signalling Termination and Call Handling function passing frames of signalling information through an AAL2 SSCS (I.366.1). Signalling Termination and Call Handling communicates with the CID Management function to assign the CID value for a given narrowband call. The CID Management function maintains a record of the status of all allocated CID values for each AAL2 VCC. Individual bearer streams leaving the switch on the ATM side are processed by the SSCS User function. For voice, this comprises a Codec with or without Speech Activity Detection, as indicated by the profile in use on the connection. For facsimile, the SSCS User may comprise a facsimile demodulation/remodulation capability. The resulting SDUs from the SSCS User are passed to an SSCS (either I.366.1 or I.366.2) for AAL2 packetization. The AAL2 packets are then transferred to the AAL2 CPS function for multiplexing into cells for transfer to the ATM function. An inverse set of procedures is followed for information arriving at an IWF in the opposite direction of transmission. 1.12 References 1.12.1 Normative The following references contain provisions that, through reference in this text, constitute provisions of this specification. At the time of publication, the editions indicated were valid. All references are subject to revision, and parties to agreements based on this specification are encouraged to investigate the possibility of applying the most recent editions of the references indicated below. 1. ANSI T1.401-1993, Interface between carriers and customer installations - analog voice grade switched access lines using loops-start and ground-start signaling. 2. ANSI T1.403-1995, Network-to-customer installation - DS1 metallic interface 3. ANSI T1.409-1996, Network-to-customer installation interfaces - analog voice grade special access lines using E&M signaling. 4. ANSI T1.602-1996, Integrated services digital network (ISDN) - Data-link layer signaling specification for application at the user-network interface. 5. ANSI T1.607-1990 (R 1995) and ANSI T1.607a-1996, Digital subscriber signaling system number 1 (DSS1) - layer 3 signaling specification for circuit-switched bearer services. 6. ANSI/TIA/EIA 464-B-1996, Requirements for private branch exchange (PBX) switching equipment. 7. ATM Forum af-sig-0061.000, 1996, ATM User-Network Interface (UNI) Signalling Specification Version 4.0. 8. ATM Forum af-pnni-0055.000, 1996, Private Network-Network Interface Specification Version 1.0 (PNNI 1.0). 9. Bellcore TR-NWT-000170 Issue 2, Jan 1993, Digital Cross-Connect System (DSC 1/0) Generic Criteria. 10. BT BTNR 188 Issue 6, 1995, Digital private network signalling system No. 1 (DPNSS1). 11. ETSI ETS 300 102-1, Dec 1990, Integrated services digital network (ISDN); user-network interface layer 3 specifications for basic call control. 12. ETSI ETS 300 102-2, Dec 1990, Integrated services digital network (ISDN); user-network interface layer 3 specifications for basic call control - SDL diagrams. 13. ETSI ETS 300 125, Sep 1991, Integrated services digital network (ISDN); user-network interface data link layer specification - Application of CCITT recommendations Q.920/I.440 and Q.921/I.441. 14. ETSI ETS 300 402-1, Nov 1995, Integrated services digital network (ISDN); Digital subscriber signalling system no. 1 (DSS1) protocol; Data link Layer; Part 1: General aspects. 15. ETSI ETS 300 402-2, Nov 1995 Integrated services digital network (ISDN); Digital subscriber signalling system no. 1 (DSS1) protocol; Data link Layer; Part 2: General protocol specification. 16. ISO/IEC 11572, 1997, Information technology - Telecommunications and information exchange between systems - Private integrated services network - Circuit mode bearer services - Inter-exchange signalling procedures and protocol. 17. ITU-T G.703, 1991, Physical/electrical characteristics of hierarchical digital interfaces. 18. ITU-T G.704, 1995, Synchronous frame structures used at 1544, 6312, 2048, 8488 and 44 736 kbit/s hierarchical levels. 19. ITU-T G.732, 1988, Characteristics of primary PCM multiplex equipment operating at 2048 kbit/s. 20. ITU-T G.733, 1988, Characteristics of primary PCM multiplex equipment operating at 1544 kbit/s. 21. ITU-T G.735, 1988, Characteristics of primary PCM multiplex equipment operating at 2048 kbit/s and offering synchronous digital access at 384 kbit/s and/or 64 kbit/s. 22. ITU-T G.775, 1994, Loss of signal (LOS) and alarm indication signal (AIS) defect detection and clearance criteria. 23. ITU-T G.962, 1992, Access digital section for ISDN primary rate at 2048 kbit/s. 24. ITU-T G.963, 1993, Access digital section for ISDN primary rate at 1544 kbit/s. 25. ITU-T I.363.2, 1997, B-ISDN ATM adaptation layer type 2 specification. 26. ITU-T I.366.1, 1998, Segmentation and reassembly service specific convergence sublayer for the AAL type 2. 27. ITU-T I.366.2, 1999, AAL Type 2 service specific convergence sublayer for trunking. 28. ITU-T I.432.1, 1996, B-ISDN user-network - Physical layer specification: General characteristics. 29. ITU-T I.432.2, 1996, B-ISDN user-network - Physical layer specification: 155 520 kbit/s and 622 080 kbit/s operation. 30. ITU-T I.432.3, 1996, B-ISDN user-network - Physical layer specification: 1544 kbit/s and 2048 kbit/s operation. 31. ITU-T I.432.4, 1996, B-ISDN user-network - Physical layer specification: 51 840 kbit/s operation. 32. ITU-T I.432.5, 1997, B-ISDN user-network - Physical layer specification: 25 600 kbit/s operation. 33. ITU-T I.610, 1998, B-ISDN Operation and Maintenance Principles and Functions. 34. ITU-T Q.23, 1988, Technical features of push button telephone sets. 35. ITU-T Q.2931, 1995, with draft amendment 2 as contained in COM 11-R122, Broadband Integrated Services Digital Network (B-ISDN) - Digital Subscriber Signalling System No. 2 (DSS 2) - User-Network Interface (UNI) Layer 3 specification for basic call/connection control. 36. ITU-T Q.2941.2, to be determined, Broadband Integrated Services Digital Network (B-ISDN) - Digital Subscriber Signalling System No. 2 (DSS 2): Generic identifier transport (Draft). 37. ITU-T Q.931, 1993, Digital subscriber signalling system No. 1 (DSS 1) - ISDN user-network interface layer 3 specification for basic call control. 38. ITU-T V.8, 1998, Procedures for starting sessions of data transmission over the general switched telephone network. 39. ITU-T V.25, 1996, Automatic answering equipment and general procedures for automatic calling equipment on the general switched telephone network including procedures for disabling of echo control devices for both manually and automatically established calls. 1.12.2 Informative 1. ANSI T1.101-1994, Synchronization Interface Standards for Digital Networks. 2. ISO/IEC 11573-1994, Information technology - Telecommunications and information exchange between systems - Synchronization methods and technical requirements for Private Integrated Services Networks. 3. ITU-T G.114, 1996, One-way transmission time. 4. ITU-T G.131, 1996, Control of talker echo. 5. ITU-T G.164, 1988, Echo Suppressors 6. ITU-T G.165, 1993, Echo cancellers. 7. ITU-T Q.24, 1988, Multifrequency Push Button Signal Reception. 2. Interfaces Supported In order to provide the capabilities identified in Section 3, Capabilities Supported, an IWF shall employ both narrowband and broadband interfaces to carry bearer information. In addition, it may have other interfaces for management and administration purposes, but these are not specified in this document. 2.1 Narrowband Interfaces An IWF should support appropriate narrowband interfaces for the intended application. Following are the most common interfaces. 2.1.1 Physical Layer At the physical layer, an IWF should support DS1 or E1 circuits in accordance with G.703, G.704, or ANSI T1.403-1995, depending on the application. 2.1.2 Signalling At the signalling layer, an IWF shall support one or more of the following signalling systems depending on the intended application. 2.1.2.1 CAS Channel associated signalling systems are: * AB or ABCD channel associated signalling bit extraction in accordance with G.704. * ABCD channel associated signalling bit interpretation in accordance with application specific requirements such as ANSI/TIA/EIA-464, ANSI T1.401-1993, or ANSI T1.409-1996. * DTMF address signalling , in accordance with ANSI/TIA/EIA-464. * Other CAS systems depending on the application. 2.1.2.2 CCS Common channel signalling systems are: * N-ISDN signalling in accordance with Q.921 and Q.931 (DSS1). * N-ISDN signalling in accordance with ANSI T1.602 and ANSI T1.607 (DSS1). * N-ISDN in accordance with the ETSI version of DSS1 as defined in ETS 300 125 and ETS 300 102-1. * PSS1 as defined in ISO/IEC 11572. * DPNSS as specified in BTNR 188. * Other CCS systems depending on the application. 2.2 ATM Interfaces 2.2.1 Physical Layer The interface between an IWF and the ATM network should be any ATM interface defined by the ATM Forum or by the ITU-T I.432.x series of UNI recommendations. 2.2.2 Adaptation Layer An IWF shall implement AAL2 as defined in I.363.2. If AAL5 is used, it shall be as defined in I.363.5. 2.2.3 Signalling Layer If an IWF signals to the ATM network to setup SVCs/SPVCs, the signalling to that network shall be ATM Forum UNI 4.0 (af-sig-0061.000), ATM Forum PNNI 1.0 (af-pnni-0055.000), or ITU-T Q.2931 with extensions specified in this document. 3. Capabilities Supported This section provides a high-level description of the capabilities to be supported by the AAL2 Trunking IWF. It should be noted that an IWF may be realized as a set of functions within a larger device and may reside with other capabilities not identified here. Interoperability requires that two communicating IWFs be aware of the presence or absence of support for these capabilities by the peer IWF. The detailed procedures and signalling to support these capabilities are covered in succeeding sections. 3.1 IWF-IWF Communication Two IWFs can be connected directly over an ATM link or via an ATM network. Multiple VCCs can exist between two IWFs. These can be either PVCs, SPVCs, or SVCs. Bearer traffic and CAS is carried over ATM VCCs using AAL2 and CCS is carried over ATM VCCs using either AAL2 or AAL5. 3.2 Signalling In order to support the two modes of trunking, an IWF shall support the corresponding capabilities of narrowband signalling. These are referred to as * signalling termination (for switched trunking) * transport of signalling without termination (for non-switched trunking) For each, there are differences between the handling of CAS and CCS type signalling which are depicted in the protocol reference models presented in this section. A representation of the call handling application that makes use of these protocols is included in the Figures 6 through 12 to assist in depicting the essential differences between these two cases. 3.2.1 Signalling Termination Signalling termination refers to the set of procedures by which an IWF provides termination of the signalling at layer 3. This includes interpretation, responding, error handling, and the call processing which results from those signals, including routing and switching. Interworking between different signalling systems is permitted. The protocol reference models of Figures 6 through 9 each show a single narrowband interface. More generally, however, calls from multiple narrowband interfaces may be switched by an IWF to AAL2 channels of the same ATM VCC. An instance of switched trunking between peer IWFs is controlled by a single CCS channel. This CCS may be carried as a channel within one of the underlying AAL2 VCCs or over a separate AAL5 VCC. For switched trunking, if CAS is present at a narrowband interface, it must be converted to CCS between the IWFs. 3.2.1.1 Control Information Via CCS Figure 6 shows the protocol reference model for IWFs supporting CCS at the narrowband interface and using CCS for IWF-IWF signalling over the same ATM VCC (using AAL2) as the bearer channels. Figure 7 shows the protocol reference model for IWFs supporting CCS at the narrowband interface and using CCS for IWF-IWF signalling over a separate AAL5 VCC. Figure 6: Protocol Reference Model for switched trunking with CCS interface and CCS over AAL2 between IWFs Figure 7: Protocol Reference Model for switched trunking with CCS interface and CCS over AAL5 between IWFs 3.2.1.2 Control Information Via CAS with DTMF and interworking to CCS Figure 8 shows the protocol reference model for IWFs supporting the termination of CAS control signalling on the narrowband side with interworking to CCS carried over the same AAL2 as the bearer information. The Call Handling function provides the interworking between CAS and CCS. Figure 9 shows the protocol reference model for IWFs supporting the termination of CAS control signalling on the narrowband side with interworking to CCS carried over a separate AAL5 VCC. The Call Handling function provides the interworking between CAS and CCS. Figure 8: Protocol Reference Model for switched trunking with CAS interface and CCS over AAL2 between IWFs Figure 9: Protocol Reference Model for switched trunking with CAS interface and CCS over AAL5 between IWFs 3.2.2 Transport of Signalling without Termination Transport of signalling without termination refers to the situation in which an IWF does not provide layer 3 or full layer 2 termination of the protocol, meaning that it does not interpret, respond to, or process the signals for routing purposes. An IWF does not perform routing and switching. Signalling is passed transparently between the narrowband side and the ATM side. The protocol reference models of Figures 10 through 12 each show a single narrowband interface. More generally, however, time slots from multiple narrowband interfaces may be mapped by an IWF to AAL2 channels of the same ATM VCC. If multiple narrowband interfaces, each with its own CCS channel, are carried by an instance of non-switched trunking, the underlying AAL2 VCC may contain multiple CCS channels. Alternatively, the CCS channels may be carried over multiple AAL5 VCCs or the CCS channels may be carried by a combination of the two methods. 3.2.2.1 Control Information Via CAS with DTMF Figure 10 shows the protocol reference model for IWFs that pass CAS signalling transparently between the narrowband interfaces and the AAL2 channel without termination and interpretation by a call handling application. The CAS signalling is mapped into the same AAL2 channel as the bearer information and may be accompanied by DTMF dialled digits information. Figure 10: Protocol Reference Model for non-switched trunking with CAS transported over AAL2 between IWFs 3.2.2.2 Control Information Via CCS Figure 11 shows the protocol reference model for IWFs that pass CCS information transparently between the narrowband interfaces and the AAL2 channel without termination and interpretation by a call handling application. The only assumption made about the CCS protocol is that its Layer 2 is framed by HDLC with flags, bit stuffing, and a 16-bit CRC. Deframed data units are carried between IWFs using the error detection option of I.366.1. Figure 12 shows the protocol reference model for IWFs that pass CCS signalling transparently between the narrowband interfaces and a separate AAL5 VCC without termination and interpretation by a call handling application. Figure 11: Protocol Reference Model for non-switched trunking with CCS transported over AAL2 between IWFs Figure 12: Protocol Reference Model for non-switched trunking with CCS transported over AAL5 between IWFs 3.3 Routing In order to support the switched trunking mode, an IWF shall provide a call-by-call routing capability. The routing decision may be based on one or more of the following, or additional information not listed here: * information that is administered at an IWF * characteristics of the call as expressed in the received signalling, which may include the called party address and bearer capability * awareness of the current traffic conditions between the IWFs and to the narrowband interfaces * incoming interface and timeslot Routing results in selection of an outgoing facility (e.g., narrowband trunk group or ATM VCC) on which to route the call. Routing may be very simple, with all calls from a given narrowband interface being assigned to the same VCC, or it may involve analysis of the called party address, matching it against administered routing patterns. An IWF may provide the capability to select more than one outgoing facility in order to provide an alternate routing capability. It may also include the capability to establish a new VCC in response to an incoming call when no existing VCC is suitable. Definition of the routing capabilities is beyond the scope of this specification. This specification does not make provision in IWF-to-IWF signalling for the exchange of routing information. For calls received from a narrowband interface, an IWF shall support routing to a distant IWF via the ATM facility. For calls received from an ATM interface, an IWF shall support routing to a destination on a narrowband interface. This specification does not require routing between narrowband interfaces or between ATM interfaces. 3.4 Voice Encoding Support 3.4.1 Types of Encoding Supported The support of voice encoding algorithms is application dependent. IWFs may support any ITU-T standardized voice encoding algorithms. Annexes B through H of I.366.2 identify the currently standardized encoding algorithms. Selection of the algorithms to be supported shall be by mutual agreement between the interconnected IWFs. In addition, an IWF may also support the use of algorithms not identified in Annexes B through H of I.366.2. 3.4.2 Selection and Changing of Encoding Each IWF shall support at least one voice coding profile and optionally may support more. Each coding profile contains one or more entries, with each entry specifying a coding algorithm and information regarding how the data is to be packed into a packet. If multiple profiles are possible, the profile to be applied to each call must be designated prior to call set-up. For information on profiles see I.366.2. 3.5 Idle Channel Suppression For the efficient operation of AAL2 trunking, it is desirable that measures be taken to prevent the use of bandwidth for channels that are idle, either because no call exists or because no audio activity exists. This specification identifies the following methods of Idle Channel Suppression which may be utilized by the transmitting side of the ATM AAL2 connection. 3.5.1 Idle Call State Determination When the transmitting IWF is performing a signal termination and routing function, it is aware of the call state of each possible IWF-IWF connection. Based on the ABCD signalling bits or CCS messages, an IWF may determine whether an IWF-IWF channel is idle or not idle and cease transmitting speech encoded signals to the distant IWF while the call state is idle. When the transmitting IWF is not performing signalling termination, such as when providing the non-switched trunking application, it may still determine the call state by monitoring of the call establishment/ disestablishment signals which it is otherwise passing unchanged. Based on these signals, an IWF may cease transmitting speech encoded signals to the distant IWF when it determines that the channel is idle. 3.5.2 Idle Code Detection This capability depends on an IWF being able to determine that a channel is idle by examining the contents of the bearer information and recognizing certain data as representing an "idle" condition, for example, a certain number of repetitions of a predefined data pattern. Procedures for the use of this method are not included in this specification. Annex A of ATM Forum document af-vtoa-0085 contains informative notes on the application of idle code detection. 3.6 Silence Detection and Removal During non-idle call periods, there are normally periods of silence on a transmission path (actually near-silence), either because the other party is speaking or due to the regular silent intervals in speech. Significant improvements in bandwidth efficiency can be gained by not transmitting during these silent intervals, that is, if the transmitter does not transmit encoded speech information to represent this silence. When using voice encoding schemes that do not include inherent silence suppression, an IWF should monitor the bearer information being transferred to determine when silent periods exist. If it provides this capability, it shall suppress the transmission during these silent intervals and transmit the appropriate Silence Insertion Descriptor at the appropriate time to specify the background noise to be regenerated at the receiving IWF. The methods used to detect silent periods are not specified here. I.366.2 contains procedures to ensure that relative timing is maintained through each silent interval. The decision of when to use silence suppression for a particular call, if allowed, is a local matter for the transmitting IWF. The receiving IWF is required to correctly process all silent periods. 3.7 Echo Cancellation For voice applications, the combination of delay and echo causes an impairment to speech quality which is subjectively determined and which may require measures to be taken to minimize the impact. Since most causes of delay can not be avoided or minimized, reduction of echo must be considered. Delay is introduced into an end-to-end connection by a variety of factors including: * Packetization * Compression algorithms * Physical transmission time * Switching of ATM cells in the network * Queuing * Build-out delay for accommodating PDV Echo is caused by: * Hybrids used to go from 4-wire circuits to 2-wire circuits (typically at analog loops) * Acoustical feed-back at the end user's terminal (especially when the user places a telephone receiver down on a hard surface) Applicable ITU-T Recommendations such as G.131, G.114, G.165, and other references contain information on this subject. Generally, the control of echo is best performed as close to the source of that echo as practicable. This specification addresses neither the methods used to determine the need for nor the procedures for applying echo cancellation. An IWF may support echo cancellation. 3.8 Non-control Signalling DTMF Transport The transport of non-control signalling DTMF refers to DTMF that is passed through an IWF without interpretation either in support of a permanent connection such as described in Section 3.2.2 or after call set-up is complete following routing by an IWF. In both cases, the DTMF needs to be passed transparently through the entire end-to-end connection including the ATM portion between the two IWFs. Since some of the low bit-rate coding algorithms used may not properly pass the DTMF tones, special capabilities must be employed to ensure the tones are not blocked. During a connection period using one of the subject low bit-rate encoding and in which DTMF may occur, an IWF shall monitor for the presence of DTMF on the transmit path to the AAL2 transmission side. Upon detection of a DTMF tone pair, it shall employ one of the following methods. 3.8.1 Use of higher bit-rate encoding Upon detection of DTMF, an IWF may immediately switch to a higher bit-rate encoding. If it does change to a higher bit-rate encoding, it shall continue to monitor for DTMF activity and switch back to the previous bit-rate encoding after a period without further DTMF being detected. 3.8.2 Transfer by dialled digits packets Upon detection of DTMF, an IWF shall block the remainder of the tone pair from being transferred to the speech channel to the other IWF and shall transfer an indication to the other IWF that the DTMF tone pair has started. When a valid silent period occurs to indicate the end of the DTMF tone pair, the originating IWF shall transfer an indication to the other IWF that the DTMF tone pair has ended. The terminating IWF shall transmit the DTMF tone pair to the narrowband interface at its end based on the receipt of indications to start and end the tone pair. 3.9 Transport of Voiceband Data Some of the low bit-rate encoding schemes supported by an IWF may not correctly pass modem signals. When using one of these encoding schemes, an IWF may take special steps to transport voiceband data. If so, the IWF shall detect the 2100 Hz tone used in the handshake of modem calls. Upon detection of this tone, an IWF shall change over to a more suitable encoding scheme for the transmit direction, e.g., G.711. An IWF should detect the end of modem operation and return to a low bit-rate encoding to support voice operation. This specification does not identify which encoding schemes might not correctly pass modem signals and hence require an IWF to change to a different encoding scheme. Alternatively, an IWF may choose to monitor for the presence of facsimile information and employ the FAX demodulation/remodulation procedures of I.366.2. 4. Control of ATM VCCs and AAL2 Channels In this section, CAS and CCS refer to the narrowband signalling over ATM used between IWFs to control calls being assigned to the channels of an AAL2 VCC. CAS between IWFs appears in the same VCC and CID that carries a narrowband call (for the non-switched mode only). CCS between IWFs may be carried within an AAL2 VCC or on a separate AAL5 VCC. In the case of switched mode using AAL2 for CCS, there is at most one CCS channel within each AAL2 VCC and it shall occupy CID=8. In the case of non-switched mode using AAL2 for CCS, there may be multiple CCS channels within each AAL2 VCC which occupy one or more of the CIDs allocated in the range 8-255. In the case of using AAL5 for CCS, each CCS channel occupies the entire AAL5 VCC. In all cases, one CCS channel may control bearer channels on multiple AAL2 VCCs. In the case of switched mode, all bearer channels on an AAL2 VCC are controlled by the same CCS channel. 4.1 VCC Characteristics To create VCCs, their characteristics need to be agreed. This specification defines procedures for VCCs that adhere uniformly to a protocol reference model of Section 3.2. The signalling procedures of this specification do not support the mixing of CAS and CCS or switched and non-switched trunking on the same VCC. Combinations of these characteristics may be created by suitable provisioning under bilateral agreement, but the procedures related to such combinations are beyond the scope of this specification. In these procedures, Soft PVCs (SPVCs) are treated as PVCs. 4.1.1 Application Identifier (AppId) The Application Identifier (AppId) specifies protocol combinations used between IWFs. Values are defined for the following: * Switched mode of trunking using PSS1 between IWFs * Switched mode of trunking using DSS1 between IWFs * Switched mode of trunking using DPNSS between IWFs * Switched mode of trunking using other variety of CCS between IWFs * Non-switched mode using CAS between IWFs (does not apply to AAL5 VCCs) * Non-switched mode using CCS between IWFs (all AAL2 channels within this VCC are controlled by the same narrowband signalling stream) * Unspecified combination (does not apply to AAL5 VCCs) The AppId of a VCC, its AAL type, and the location of its controlling CCS (if any) determine which protocol stacks are used on the VCC, as shown in the figures of Section 3.2. 4.1.2 VCC Identifier (VCCI) To distinguish multiple VCCs, each shall be assigned a VCCI. This applies to both AAL2 and AAL5 VCCs. The creator of an SVC shall assign its VCCI. The VCCI of a PVC is mutually provisioned. The VCCI shall be unique for all VCCs between two IWFs but may be repeated with other peer IWFs. To create two non-conflicting value spaces, the format of a VCCI includes one bit to flag which peer IWF assigned its value, that is, the sender or receiver of a message containing the VCCI. Between two IWFs, a VCCI + CID pair is enough to identify an AAL2 channel. 4.1.3 Signalling VCC Identifier (SigVCCI) More than one narrowband signalling channel can exist between a pair of IWFs. Multiple AAL5 VCCs are possible, as well as multiple AAL2 VCCs, and both can carry CCS. It is important to know which CCS controls a given AAL2 VCC, so that call collisions can be avoided or resolved and restarts can be effected. If the AppId of an AAL2 VCC indicates CCS, the VCCI of the AAL2 or AAL5 VCC that contains the CCS shall be specified. This is the SigVCCI of the AAL2 VCC. If SigVCCI = VCCI, then the AAL2 VCC contains CCS. To make this equality serve as the indicator of when an AAL2 VCC contains CCS, the converse shall also be true - if an AAL2 VCC contains CCS, then SigVCCI = VCCI, that is, the AAL2 VCC shall be controlled by the CCS within it This does not prevent CCS within an AAL2 VCC from also controlling other AAL2 VCCs that do not contain their own CCS. 4.1.4 Default SSCS Type For all AAL2 VCCs, the default SSCS type is I.366.2 4.1.5 Default SSCS Parameter Values The SSCS parameters of operation are used to ensure that interconnected IWFs agree on the set of capabilities to be applied to a VCC. The parameters are defined in I.366.2. From among the SSCS parameter values supported by both IWFs, one specific set of values may be designated the default for an AAL2 VCC. Different AAL2 VCCs between the same two IWFs may have different default SSCS parameter values. In the absence of signalling or provisioning on a per-channel basis, either explicit or implicit, the default SSCS parameter values shall apply to each CID of the AAL2 VCC. 4.1.6 AAL2 CPS Parameter Values AAL2 parameters of the Common Part Sublayer are: * maximum number of CIDs that can be active * maximum packet length 4.1.7 AAL5 Parameter Values AAL5 parameters are: * forward maximum CPCS-SDU size * backward maximum CPCS-SDU size * SSCS type 4.2 Provisioning PVCs For an AAL2 PVC, the following characteristics shall be specified during the provisioning process: * AppId * VCCI * SigVCCI, if the AppId indicates CCS * default SSCS type * default SSCS parameter values * AAL type 2 * AAL2 CPS parameter values For an AAL5 PVC, the following characteristics shall be specified during the provisioning process: * AppId * VCCI * AAL type 5 * AAL5 parameter values 4.3 Signaling of SVCs IWFs require minimum signalling support by serving switches and networks equal to what is specified in UNI 4.0, including mandatory support for the optional service of Generic Identifier Transport. The VCC characteristics listed in section 4.2 for use during the PVC provisioning process shall be signalled between IWFs for establishment of an SVC. The encoding of signalling information into broadband IEs described in this section shall be as defined in sections C.1 and C.2 of Annex C. SVCs created for different kinds of traffic may operate with different default SSCS parameter values. The IWF that initiates the setup of the SVC should indicate these values. The responding IWF shall either accept or reject the values, releasing the SVC if the values are rejected. There is no negotiation in these procedures. 4.3.1 AppId The AppId shall be passed in SETUP as part of the B-HLI IE. Specific values are assigned under the ATM Forum's OUI. The B-HLI IE shall be encoded as described in section C.1.4 and C.1.5 of Annex C. 4.3.2 VCCI The VCCI shall be passed in SETUP as part of the GIT IE. The flag embedded in the VCCI value shall reflect that the value was assigned by the sender of the SETUP message. The GIT IE shall be encoded as described in sections C.1.5 and C.2.5 of Annex C. 4.3.3 SigVCCI The SigVCCI shall be passed conditionally in SETUP as part of the GIT IE. SigVCCI shall be present when the AAL is type 2 and the AppId indicates CCS. The GIT IE shall be encoded as described in section C.1.5 of Annex C. 4.3.4 Default SSCS Type Default SSCS type may be passed in SETUP as part of the AAL Parameters IE. It applies when the AAL is type 2. If a value is omitted, I.366.2 shall be understood. The AAL Parameters IE shall be encoded as described in section C.1.1 of Annex C. 4.3.5 Default SSCS Parameter Values Default SSCS parameter values may be passed in SETUP as part of the AAL Parameters IE. They apply when the AAL is type 2. If a value is omitted for any SSCS parameter, the default value of I.366.2 Section 18 shall apply. The AAL Parameters IE shall be encoded as described in section C.1.1 of Annex C. 4.3.6 AAL2 CPS Parameter Values AAL2 CPS parameter values may be passed in SETUP as part of the AAL Parameters IE. If a value is omitted for any AAL2 CPS parameter, the default value of I.363.2 Section 11 shall apply. The AAL Parameters IE shall be encoded as described in section C.1.1 of Annex C. 4.3.7 AAL5 Parameter Values AAL5 parameter values may be passed in SETUP as part of the AAL Parameters IE. If a value is omitted for any AAL5 parameter, the default value of Q.2931 Section 4.5.5 shall apply. The AAL Parameters IE shall be encoded as described in section C.2.1 of Annex C. 4.3.8 Error Conditions If a valid AppId is not received in SETUP, the SVC shall be released. If a VCCI is not received in SETUP or its value is not unique among all VCCs with the same peer IWF, the SVC shall be released. If a SigVCCI is not received in SETUP when the AAL is type 2 and the AppId indicates CCS or is received under other circumstances, the SVC shall be released. If SigVCCI ( VCCI and the SigVCCI does not match the VCCI of an existing AAL2 or AAL5 VCC with the same peer IWF, the SVC shall be released. If the AppId of the matched VCCI does not indicate CCS or there is any other inconsistency between the SVC and the matched VCCI, the SVC shall be released. 4.3.9 Redundant SVC Handling Peer IWFs, undertaking similar initiatives at roughly the same time, may occasionally duplicate a resource, such as an AAL5 SVC for signalling between them or an AAL2 SVC to carry narrowband calls, when a single instance of the resource would suffice. In such circumstances, if a single resource is desired, one SVC should be favored for continued use. The other SVC should be recognized as redundant and fall into disuse, eventually to be released. The SVC to retain is the one established by the lower ATM address. To determine which of two ATM addresses is lower, any native E.164 address shall first be converted to E.164 AESA (embedded NSAP) with DSP field set to all zeros. Two AESAs shall be compared octet by octet beginning with the first octet, using an unsigned numerical comparison until a mismatch is found. An IWF shall not setup any further narrowband calls using an SVC intended for release (either using it as the bearer channel or signalling channel). Once all existing calls that were setup using the intended SVC have released, the SVC shall be released. 4.4 Establishment and Release of AAL2 channels 4.4.1 CID Assignment Depending on whether it is supporting the switched trunking mode or the non-switched trunking mode, an IWF shall provide the following CID assignment capabilities: 4.4.1.1 CID Allocation For both modes, an IWF shall provide static CID allocation, which means that the CID values to be used on a VCC are allocated at the same time that the VCC is created, whether that is done via management procedures (PVC or SPVC) or via switching (SVC). No use is made of the CID values reserved in I.363.2. Therefore, CID values 1 through 7 shall not be allocated. For the non-switched trunking mode, any subset of CID values from 8 through 255 may be allocated for association to narrowband time slots. For the switched trunking mode, the range of allocated CID value shall be contiguous (without gaps). It shall begin at CID=8 if a channel within the AAL2 VCC is used for IWF-IWF signalling and at CID=9 otherwise. The maximum CID value allocated shall be less than or equal to 255. The maximum CID value is signalled as part of the AAL Parameters IE when an SVC is established. 4.4.1.2 CID Association For the non-switched trunking mode, an IWF shall utilize permanent CID association, which means that it shall maintain a fixed relationship between each of the allocated CID values and a narrowband time slot. This relationship shall be established when the VCC is created. For the switched trunking mode, an IWF shall determine the CID to narrowband channel association on a per-call basis, since this is the essential attribute required for switching. In addition to the association of CID values for bearer channels, an IWF shall reserve CID=8 for use by IWF-IWF signalling. When there is no signalling channel within the AAL2 VCC, CID=8 shall not be used. 4.4.1.3 CID Selection and Glare Minimization For switched trunking, in order to minimize the possibility of glare in the selection of CID values for a call set-up, the two interconnected IWFs should select CID values from the opposite ends of the allocated range for each bearer VCC. The controlling IWF shall select from the lower CID values of the range and the non-controlling IWF shall select from the higher values. The controlling IWF shall be designated as described in section 5.5. 4.4.2 AAL2 Channel Association Procedures 4.4.2.1 Non-Switched Mode For the non-switched trunking mode, AAL2 channels are permanently associated with the narrowband channels, therefore, the procedures of section 4.4.2.2 does not apply. 4.4.2.2 Switched Mode Figure 13 shows how AAL2 channels are related to an ATM VCC. Each channel is identified by a Channel ID (CID) which provides a unique value between the two IWFs within that one VCC. The allocation of the channels to be used within the VCC is determined at the time the VCC is created. Association of CID values to narrowband channels shall be as follows. Figure 13: AAL2 Channels within an ATM VCC For the switched trunking mode, an AAL2 channel shall be selected within an ATM VCC for each individual connection. At each connection set-up, the IWF originating the call shall associate the selected channel with its incoming narrowband time slot and shall send a SETUP message containing a Channel ID IE, encoded as shown in Section C.3 of Annex C, to identify the AAL2 channel (CID value) being used. The SETUP shall be sent on the IWF-IWF signalling channel controlling the AAL2 VCC. The receiving IWF shall change the status of the CID to "active" (unless "glare" occurred). As the receiving IWF selects an outgoing narrowband time slot, it shall associate the selected time slot with the CID. At connection release, each IWF shall remove the channel association The status of the CID is returned to idle state on completion of the applicable release procedure. 5. Narrowband Signalling Procedures In support of the switched trunking mode, an IWF shall signal on the narrowband interfaces according to applicable standards and other specifications governing those interfaces. An IWF shall also provide for the transport of narrowband signalling across the ATM side to the other IWF. An IWF shall support PSS1 for IWF-IWF signalling and may also support other common channel signalling systems. When signalling on the narrowband side is identical to IWF-IWF signalling, no conversion between them is necessary. When they are not identical, interworking between the selected signalling systems is necessary. In support of the non-switched mode, an IWF shall transport signalling from the narrowband side unmodified across ATM to the other IWF. No conversion is performed. The following provides general criteria and objectives that apply. 5.1 Channel Associated Signalling In the context of an IWF signalling procedures, CAS refers to those signalling systems in which the signalling (supervisory and address) is transferred through the narrowband interface directly associated with the channel to which it applies, whether it is transferred by "bit-robbing" from that time slot (as in DS1), by dedicated bits in another time-slot (as in E1), or by in-band tones (such as DTMF). 5.1.1 Supervision Signalling The most common form of CAS supervision signalling consists of the ABCD signalling bits derived from the digital hierarchical systems such as DS1 and E1 as defined in G.704. When interfacing with these or functionally equivalent systems, an IWF shall have the capability to receive/transmit CAS bits. In switched trunking mode, an IWF shall interpret the signalling bits within its Call Processing logic and control the set-up and disconnection of connections accordingly. Corresponding CCS signals, shall be sent on the ATM side for transport to the peer IWF as a result of the interpretation. Signalling bits are not passed directly through the IWF. In non-switched trunking mode, an IWF may have the capability to monitor supervision signalling. If it does so, it shall interpret the signalling bits for the purpose of idle channel suppression. 5.1.2 Address Signalling The most common forms of CAS address signalling consist of DTMF, R1, or R2 in-band tones to indicate the called number, and possibly other information. In switched trunking mode, when interfacing with systems that provide DTMF, R1, or R2 address signalling for call set-up, an IWF shall provide for detection and reception of these tones and interpretation of their meaning. This shall include call routing to the appropriate destination via the ATM interfaces. Corresponding address signals, if supported, shall be sent on the ATM side as CCS for transport to the peer IWF as a result of the interpretation. In-band call set-up tones are not passed directly through the IWF. In non-switched trunking mode, an IWF shall transport address signalling information transparently either as voice packets or as dialled digits packets. 5.2 Common Channel Signalling In the context of an IWF signalling procedures, CCS refers to those signalling systems in which all signalling is transferred in a separate dedicated signalling channel which is shared by a group of channels. In the most common example, each DS1 or E1 interface contains one signalling channel that serves all channels on that DS1 or E1 (referred to as "associated signalling"). An IWF may support this form of signalling at the narrowband interface. It is also possible for a signalling channel on one DS1 or E1 interface to be used to control channels on other DS1 or E1 interfaces, provided that they terminate on the same far end equipment (referred to as "non associated signalling"). An IWF may support this configuration which is described in Annex F of Q.931. An IWF shall support the use of PSS1 for IWF-IWF signalling in switched mode and shall support transparent transport of PSS1 in non-switched mode. Depending on the application, an IWF may also support DSS1, DPNSS, or other signalling systems. It shall signal according to the established procedures for the selected system. 5.3 Detection/Removal of Idle Channels Based on Signalling 5.3.1 Switched Trunking Mode The status of a channel shall be determined by signalling termination and processing in an IWF. As a part of the call routing function, AAL2 channels are selected and released for use as IWF-IWF trunks. For the transmission of bearer information on each channel, an IWF shall conform to existing standards which specify the point in the call set-up at which the transmission path is cut through by the originating and terminating switches. For the use of PSS1 between IWFs, the following apply: * The originating IWF may consider the channel as not idle and begin sending bearer information upon receipt of a PROGRESS, CALL PROCEEDING, or ALERTING message from the other IWF. It shall consider the channel as not idle and begin sending bearer information upon receipt of CONNECT. It shall consider the channel as idle and stop sending bearer information upon sending a RELEASE, RELEASE COMPLETE, or DISCONNECT message * The terminating IWF may consider the channel as not idle and begin sending bearer information upon sending a PROGRESS, CALL PROCEEDING, or ALERTING message to the other IWF. It shall consider the channel as not idle and begin sending bearer information upon sending the CONNECT message or any other message that indicates the use of in-band tones or announcements before answer. It shall consider the channel as idle and stop sending bearer information upon sending a RELEASE, RELEASE COMPLETE, or DISCONNECT message Similar procedures should be followed for other signalling systems. 5.3.2 Non-switched Trunking Mode When operating in the non-switched mode, an IWF does not terminate narrowband signalling, however it may have the capability to monitor the signalling information non intrusively to determine the state of each narrowband channel controlled by that signalling channel. Any narrowband channel in the idle state need not be transported, thereby saving bandwidth. In addition to determining the state of channels by the monitoring of active signalling information, an IWF may also monitor the operation status of the signalling channel itself and cease transmission on all bearer channels controlled by a failed signalling channels after an appropriate time-out. 5.4 Transport of Signalling without termination In a simple AAL2 trunking implementation, an IWF may not have the capability to terminate narrowband signalling. Instead, this signalling information may be transported transparently over the ATM network to be reproduced at the remote end. This section defines the procedure to transport narrowband signalling information transparently without any modification. 5.4.1 CAS ABCD Bits Transport ITU-T recommendation G.704 defines CAS ABCD bits over DS1 and E1 TDM interfaces. As described in G.704, there may be up to four different signalling bits (A, B, C, and D) in a multiframe An IWF may have the capability to transport CAS bits transparently over the same AAL2 channel used for bearer information. If this capability is selected, the CAS ABCD bits shall be transported to the other IWF as packets using AAL2 in accordance with the procedures in Annex L of I.366.2. An IWF may have the capability to debounce the CAS bits before transport over the ATM in order to reduce unnecessary transmission. 5.4.2 CCS Information Transport All narrowband common channel signalling systems use some form of HDLC framing and an error protected transmission system. Frames can be variable length, and error correction operations like retransmission are handled within the layer 2 protocol. When CCS is not terminated in an IWF, frames shall be transported to the other end transparently, and the narrowband devices shall execute the layer 2 protocol between themselves. The IWFs shall simply extract valid frames from the signalling channel and transport them transparently. An IWF shall transport all valid HDLC frames. All invalid frames shall be dropped. Definition of an invalid frame shall be as defined in Q.921 section 2.9 conditions a, b, c, d, and e. An IWF shall not validate HDLC frames based on their SAPI value (condition g of Q.921 section 2.9). Instead, it shall transport all HDLC frames with any SAPI value. The ATM adaptation type to transport these layer 2 messages shall be either AAL5 or AAL2. 5.4.2.1 CCS Information Transport Using AAL5 An IWF may have the capability to transport CCS layer 2 frames transparently using AAL5. When this capability is selected, the IWF shall use the AAL5 CP sublayer without an SSCS layer (see Figure 14) and it shall operate as follows: The ATM VCC used for CCS information transport shall be of type nrt-VBR and shall carry one such narrowband signalling channel. Figure 14: Transparent transport of CCS information using AAL5 The HDLC framing (HDLC-F) layer shown in Figure 14 shall drop all invalid frames and pass all valid frames for transport. The messages shall be transported without flags, stuff bits, and FCS octets. In the opposite direction, this layer shall insert FCS octets and stuff bits, add the necessary flags, and deliver the layer 2 message to the narrowband device. The AAL5 CPCS function shall drop all corrupted AAL5 CPCS-PDUs received as defined in I.363.5. All valid PDUs shall be passed on for delivery. Each layer 2 frame shall be passed as an AAL5 CPCS-PDU. The parameters CPCS-LP, CPCS-CI, and CPCS-UU shall be set to zero when sent and shall be ignored when received. 5.4.2.2 CCS Information Transport Using AAL2 An IWF may have the capability to transport CCS layer 2 messages transparently using the segmentation SSCS I.366.1 and its transmission error detection option without the assured data transfer option. When this capability is selected, the IWF shall operate as follows: Signalling information and bearer information may share a common ATM VCC. Furthermore, an ATM VCC may contain more than one signalling transport channel, each controlling a different set of AAL2 channels. Each signalling channel contained in the ATM VCC shall carry the information from one narrowband signalling channel. Figure 15: Transparent transport of CCS information using AAL2 The HDLC-F layer shown in Figure 15 shall drop all invalid frames and pass all valid frames for transport. The messages shall be transported without flags, stuff bits, and FCS octets. In the opposite direction, this layer shall insert FCS octets and stuff bits, add the necessary flags, and deliver the layer 2 message to the narrowband device. The SSSAR and SSTED sublayer shown in Figure 15 shall be as defined in I.366.1. The SSTED sublayer drops all corrupted data received from the ATM link and passes valid data only. The mapping layer shown in Figure 16 shall pass each layer 2 frame received from the HDLC-F layer as an SSTED PDU and vice-versa. The parameters SSTED-LP, SSTED-UU, and SSTED-CI shall be set to zero when sent and shall be ignored when received. 5.5 Glare Handling Glare is the condition that occurs when two devices seize the same allocated channel at about the same time such that the signalling setup indications cross. For the non-switched trunking mode, the connected narrowband equipment is responsible for detection and handling of glare since the IWFs are not terminating the signalling. For the switched trunking mode, an IWF shall act as controlling side for a call if it established the SVC that contains the IWF-IWF CCS channel which is being used to setup the call. If a PVC contains the CCS, the controlling side shall be configured as part of PVC provisioning. The controlling IWF shall take the role of network side or side A for all the VCCs controlled by the subject CCS. Call collisions shall be resolved according to the applicable narrowband signalling specification, e.g. Annex D.3 of Q.931 or Section 10.3 of ISO/IEC 11572. 6. Alarms and Status Several kinds of faults can be detected at the narrowband or ATM service interface of an IWF. If a fault condition persists for a defined period of time (integration time), a management alarm is raised. With some alarm conditions, the remote IWF should be informed of the local IWF alarm condition, so that appropriate actions can be taken. This section describes these alarm conditions and the procedures that are to be followed during these periods. An IWF shall detect Loss Of Signal (LOS), Loss Of Frame (LOF), Loss of MultiFrame (LOMF), Remote Alarm Indication (RAI), and Alarm Indication Signal (AIS) on narrowband service interfaces and generate the corresponding management alarms. Definition of DS1/E1 service interface faults and alarm conditions is given in G.704, G.732, G.733, G.735, G.775, T1.231, and TR-NWT-000170. An IWF shall detect all physical layer defects and ATM layer defects as defined in I.432.x series, af-uni-0010.002, and various ATM Forum physical layer interface specifications. An IWF may use F5 OAM means to detect ATM VCC connectivity failures as defined in I.610. 6.1 Non Switched Trunking Mode Two IWFs may interwork together to provide narrowband services without any narrowband signalling (nailed-up) or narrowband signalling information may be transported transparently. In both cases, the following procedures shall apply: 6.1.1 Faults Detected on the Narrowband Interface When an IWF detects a fault condition with a narrowband service interface, this information shall be communicated to the remote IWF and to the connected narrowband equipment as follows: When LOS, LOF, or AIS is detected, the IWF shall send external AIS alarm packets downstream on each AAL2 bearer channel that is connected to a channel on the failed narrowband interface. The alarm packets shall be repeated once every second on each such AAL2 channel until the fault clears. Alarm packets shall not be sent in a channel used for signalling information transport. However, no further information shall be transmitted in the signalling transport channel (either AAL2 channel or AAL5 VCC) until the fault clears. Furthermore, a Remote Alarm Indication (RAI) shall be sent in the upstream direction (see Figure 16). When RAI is detected, the IWF shall send external RAI alarm packets downstream on each AAL2 bearer channel that is connected to a channel on the failed narrowband interface. The alarm packets shall be repeated once every second on each such AAL2 channel until the fault clears. Fault indication packets shall not be sent in a channel used for signalling information transport. When LOMF is detected in an E1 service interface with CAS, the IWF shall send external AIS alarm packets downstream on each AAL2 bearer channel that is connected to a channel on the failed narrowband interface. The alarm packets shall be repeated once every second on each such AAL2 channel until the fault clears. Furthermore, MultiFrame Remote Alarm Indication (MFRAI) shall be sent in the upstream direction (see Figure 17). Figure 16: LOS, LOF, and AIS alarms for E1 or DS1 service interfaces Figure 17: LOMF alarms for E1 service interfaces with CAS While sending external AIS alarm packets downstream as the result of a fault condition, an IWF shall cease the transmission of bearer information in that direction. For E1 service interfaces, when an external AIS alarm packet is received for an AAL type 2 channel, an IWF shall transmit the pattern 0xFF on the connected channel on the narrowband side until no external AIS alarm packet has been received for 3.5 seconds or until receipt of valid bearer information from the other end (see Figures 16 and 17). For DS1 service interfaces, when an external AIS packet is received for an AAL type 2 channel, an IWF shall apply trunk conditioning downstream on the connected channel on the narrowband side as described in Bellcore TR-NWT-000170 Issue 2, until no external AIS alarm packet has been received for 3.5 seconds or until receipt of valid bearer information from the other end (see Figure 16). 6.1.2 Detection of AAL2 Connectivity Faults Procedures for handling loss of AAL type 2 connectivity are beyond the scope of this specification. 6.1.3 Detection of ATM Connectivity Faults When loss of ATM connectivity is detected either on the signalling information transport VCC or on the bearer information transport VCC, service interfaces should be conditioned. Loss of connectivity may be detected through ATM port failure indications such as LOS or LCD or through an OAM mechanism such as AIS, loopback, or CC F5 cells. In addition, RDI indicates that a loss of connectivity was detected in the opposite direction. An IWF shall follow the procedures described in I.610 for ATM fault management. When loss of ATM connectivity is detected on a VCC carrying either a signalling information channel, a bearer channel, or both, the IWF shall also apply conditioning to all connected narrowband channels until the condition clears as follows (as shown in Figure 18): * for E1 service interfaces, it shall transmit the pattern oxFF on each signalling channel and on each bearer channel connected to a channel on the failed VCC * for DS1 service interfaces, it shall apply trunk conditioning as described in Bellcore TR-NWT-000170, Issue 2 on each signalling channel and on each bearer channel connected to a channel on the failed VCC Upon detection of an RDI on a VCC carrying either bearer channels or signalling information channels or both, an IWF may apply trunk conditioning on the connected narrowband channels as described above for loss of ATM connectivity. Figure 18: ATM VCC fault detection 6.2 Switched Trunking Mode Two IWFs may be interconnected to provide switched services, which requires the transport of IWF-IWF CCS signalling channels. 6.2.1 Faults Detected on the Narrowband Interface When an IWF detects a fault condition on a narrowband interface, it applies fault procedures to each individual connection active on that interface. When LOS, LOF, or AIS is detected, an IWF shall send Remote Alarm Indication (RAI) in the upstream direction (as in Figure 16). In addition, an IWF shall apply time-outs to any active connections and disconnect each one after the time-out. Furthermore, all new calls to that interface shall be blocked. When RAI is detected, an IWF shall take no action except to block new call set-ups to that interface. When LOMF is detected in an E1 CAS service interface, a MultiFrame Alarm Indication (MFRAI) shall be sent in the upstream direction (as in Figure 16) and new call set-ups to that interface shall be blocked. 6.2.2 Detection of AAL2 Connectivity Faults Procedures for handling loss of AAL type 2 connectivity are beyond the scope of this specification. 6.2.3 Detection of ATM Connectivity Faults When loss of ATM connectivity is detected either on a signalling information transport VCC or on a bearer information transport VCC, action should be taken, after an appropriate time-out, to release calls affected by the fault. The time-out should provide sufficient time for network actions such as protection switching to complete. When loss of ATM connectivity is detected on a VCC transporting a signalling channel, an IWF shall block new call set-ups to the bearer channels and release all calls that are not in the active (stable) state that are controlled by that signalling channel. An IWF may also start a time-out and release active calls upon expiration of that time-out as described in the applicable signalling specification. When loss of ATM connectivity is detected on a VCC carrying bearer information, an IWF shall apply appropriate trunk conditioning into the downstream direction of each connected channel on the narrowband side. An IWF may also start an appropriate time-out and release the affected calls upon expiration of the time-out as described in the applicable signalling specification. 7. Voice Compression Handling Procedures 7.1 Encoding Algorithms In order to allow IWFs to select and manage encoding algorithms according to prearranged agreements, the algorithms are grouped into profiles. A pair of IWFs which are to communicate shall agree on the profile or profiles to be used. The profiles used may be from Annex P of I.366.2, from Annex B of this specification, or from another source. An IWF conforming to this specification shall be capable of operation using the mandatory ITU-T profile #1 "PCM-64 and silence" as specified in Table P-1/I.366.2. [Editor's note: After approval of this specification, draft I.366.2 was changed so that profile #1 is now "PCM-64" and profile #2 is "PCM-64 and silence". It is the intention of this specification that profile #1 is mandatory, the same as in I.366.2.] 7.2 Selection of Encoding 7.2.1 Default Profile for an IWF One or more coding profiles may be established in an IWF. If multiple profiles are possible, a common default profile to be applied to all ATM VCCs with AAL2 may be specified. 7.2.2 Default Profile for Each VCC When an individual VCC is created (PVC or SVC), a common default profile to be applied to all AAL2 channels as described in Sections 4.2 and 4.3.5 may be specified. It shall be from the set of profiles established for an IWF. 7.2.3 Selection of Profile Entry When each IWF transmits the bearer information utilizing the profile determined as above, it indicates the entry within the profile by the procedures defined in I.366.2. A different entry (e.g., encoding algorithm) may be used in each direction. 7.3 Silence Removal and Comfort Noise Generation If a transmitting IWF provides the option of silence removal, it shall do so as described in this section. The receiving comfort noise generation procedures are required if the profile in use includes SID. 7.3.1 Detection The procedures for detection of silent intervals are not described in this specification. They may be implementation dependent and the exact method used does not impact interoperability with the peer IWF. 7.3.2 Removal and Comfort Noise Generation Upon detection of a silence interval, an IWF shall utilize the procedures of I.366.2 to stop sending packets containing speech encoding samples and shall send the appropriate silence descriptor at the appropriate time. For an encoding algorithm that provides a Silence Insertion Descriptor (SID), an IWF shall utilize this SID when operating with this algorithm. For types of encodings that do not provide a SID, an IWF shall insert the Generic SID defined in Annex C of I.366.2 after the last active voice packet of the talk spurt at the first opportunity consistent with the proper operation of sequence numbers. The receiving IWF shall generate comfort noise based on the content of the received SID. 7.3.3 Start of Talk Spurt An IWF shall detect the end of a silence interval, that is, the start of a talk spurt. It shall begin transmitting normal audio encoding packets quickly so that audio loss is minimized. 7.4 Special Handling of Inband Signals 7.4.1 Modem Detection If an IWF uses the method described in section 3.9 to pass voiceband data, it shall monitor for the presence of the 2100 Hz tone in the direction towards the ATM side. This tone is used in the hand shake for modem calls in accordance with V.25 and V.8. An IWF shall detect both the 2100 Hz tone defined in V.25 and the modified, amplitude modulated 2100 Hz tone defined in V.8. Optionally, an IWF may also monitor for the 2100 Hz tone in the direction towards the narrowband side. Upon detection of any of these tones, an IWF shall change over to a suitable bit-rate encoding in the transmit direction which ensures that the 2100 Hz tone is successfully transferred for a sufficient period of time through the IWF-IWF connection as might be required for the proper control of other equipment such as echo cancellers. An IWF may choose subsequent encoding algorithms in the transmit direction based on classification of modem signals. An IWF shall also initiate the sending of the user state control messages for voiceband data as defined in I.366.2. Upon receipt of a user state control message requesting the voiceband data state, an IWF that has not detected the presence of data shall still change over to a suitable bit rate for modem signals in its transmissions. It shall not return to a lower bit rate until it receives a user state control message (either request or response) from the peer IWF permitting a return to the voice state. An IWF should monitor for the end of the data transmission. Upon detection of the end of the voiceband data phase, an IWF should change back to a low bit-rate encoding. The method for detection of end of data phase is beyond the scope of this specification. 7.4.2 DTMF As described in Section 3.8, one of the methods for transparently passing DTMF when using an encoding algorithm not capable of passing the in-band tones is to detect the tones at the originating IWF, transport the information as dialled digit packets as specified in I.366.2, and to regenerate the tones at the terminating IWF. The specific IWF procedures at each end are described in the following sections. 7.4.2.1 Operation of the Originating Side IWF In order to support the transport of DTMF when using a voice encoding algorithm that does not properly carry these dual tone signals, an IWF shall monitor such connections for the presence of DTMF. This specification does not identify which encoding algorithms will not pass DTMF. In fact, whether or not one will successfully pass DTMF is sometimes dependent on the implementation of the DTMF receiver circuit at the distant end and the actual signal level present. When an IWF chooses to apply this method to transport DTMF through the ATM connection, it must ensure that the original DTMF tones do not "leak" through the speech connection, since they could be inadvertently detected at the distant end. If such monitoring is to be performed on a voice connection, an IWF shall monitor the direction of the connection from the narrowband side going to the ATM side. It shall apply validation parameters according to the DTMF signalling specification applicable to the environment of an IWF, i.e., frequency, level, and timing tolerances. However, it shall ensure that all transitions (tone-on and tone-off) last at least 20 ms. In addition, it shall ensure that no more than 20 ms of the DTMF tones is passed through as voice. It is desirable to limit this to 10 ms. In accordance with I.366.2 an IWF shall include a time stamp of the tone-on and tone-off occurrences in the DTMF packets so that the other IWF is able to regenerate the tone with an acceptable tolerance concerning the length. It should be noted that the "tone-off" condition in actuality means that the previous valid tone pair has ended, that is, that one or both of the tones of the pair has ceased. In accordance with I.366.2, an IWF shall specify the signal level in all DTMF packets . It is desirable that an IWF determine the total signal level of the received tones and include the value in the DTMF packets. However, if an IWF is unable to do so, it shall use a pre-set value in all packets. The information described above shall be transmitted to the other IWF using the procedures in I.366.2 Annex H. 7.4.2.2 Operation of the Destination Side IWF The destination side IWF shall turn on and off the designated tone pair in response to the messages from the originating side IWF. It may also apply additional timing requirements according to its environment; for example, ensuring that each tone-on period is at least 40 ms long regardless of the message contents. An IWF shall apply the tone pair at the level specified in the message. While transmitting a tone pair to the narrowband interface, an IWF shall cease transmission of any other audio signal that might be indicated by the received AAL2 packets. Precautions should to be taken to ensure that the echo path signal (DTMF reflected from the distant end) does not cause detection and regeneration of DTMF tones in the opposite direction. 8. Enhanced Transport 8.1 FAX Demodulation And Remodulation (FAX Relay) The procedures given in I.366.2 apply. 8.2 Circuit Mode Data N x 64 kbit/s The procedures given in I.366.2 apply. In non-switched trunking, the selection of circuit mode data for an AAL2 channel is preconfigured. In switched trunking, the selection of circuit mode data for an AAL2 channel depends on the coding of the narrowband Bearer Capability IE included in the SETUP message carried by IWF-IWF signalling and conditionally in the CONNECT message. Circuit mode data is selected if the transfer mode is circuit and the information transfer capability is other than speech or 3.1 kHz audio. The value of N is computed from the information transfer rate. The multirate service category of I.366.2 is selected implicitly for the AAL2 channel, overriding the default SSCS parameters for the VCC. 8.3 Frame Mode Data In non-switched trunking, the selection of frame mode data for an AAL2 channel is preconfigured. In switched trunking, the selection of frame mode data for an AAL2 channel depends on the coding of the narrowband Bearer Capability IE included in the SETUP message carried by IWF-IWF signalling and conditionally in the CONNECT message. Frame mode data is selected if the transfer mode is packet. The SSCS selected implicitly for the AAL2 channel is I.366.1, overriding the default SSCS for the VCC. Frame mode data units shall be octet aligned and shall use the transmission error detection (TED) option of I.366.1. Flags, used to mark the boundaries between data units, shall be removed by an IWF at input and shall be restored at output. Bit stuffing, used for flag transparency, shall be removed by an IWF at input and shall be restored at output. The FCS of each frame, used for error protection, shall be validated and discarded by an IWF at input and shall be regenerated at output. Invalid frames received over the TDM interface and invalid PDUs received over the ATM interface shall be discarded. The parameters SSTED-LP, SSTED-UU, and SSTED-CI shall be set to zero when sending towards the ATM link and shall be ignored when received. 9. Performance Consideration 9.1 Packet Delay Variation Packet delay variation (PDV) is defined by a 2-point measurement across the AAL2 Common Part Sublayer (CPS): between submission to the CPS at one IWF and delivery by the CPS at the peer IWF. The sources of PDV are; * AAL2 common part Timer_CU * Queuing below the CPS interface, in either AAL2 or ATM, to shape output cells to the traffic contract * ATM-level cell delay variation (CDV) An IWF shall have the capability to accommodate a maximum delay variation in packet transport across an AAL2 channel (including the effects of ATM cell delay variation) up to 20 ms. In the absence of signalling or other bilateral agreements about the packet delay variation, an IWF shall operate using the default value of 20 ms. 9.2 Timing Considerations An IWFs shall provide a means by which a time source traceable to a Primary Reference Source (PRS) may be provided to an IWF. An IWFs shall also have the capability to provide this timing at the narrowband interfaces. The technique by which the PRS traceable clock is supplied to an IWF is beyond the scope of this document. Information on the distribution of network timing may be found in ANSI T1.101 and ISO/IEC 11573. Annex A: Non-ITU-T Standard Algorithms This Annex forms an integral part of this Specification. A.1 General This annex identifies the algorithms and data unit formats that may be used, in addition to those defined in Annexes B through H of I.366.2, to construct ATM Forum Predefined profiles. Algorithms identified here have been determined to be used in at least one likely application of voice over ATM and their specifications are available to the public. As in I.366.2, this annex defines the encoding data unit format for each algorithm, that is, the manner in which the information resulting from the encoder is packed into octets for transport in type 1 packets. A.2 Linear Predictive Coding with 10 Reflection Coefficients (LPC-10e) This algorithm in defined in (US) Federal Standard 1015 of November 28, 1984 and is in common use to interconnect government communication facilities. The encoder samples the analog signal at 8000 Hz and produces data at 2,400 bit/s, which is structured into one 54-bit frame every 22.5 ms. This frame contains separate fields to indicate such parameters as: RMS amplitude, reflection coefficients, pitch, and synchronization. Depending on the nature of the audio information, the encoder produces either a "voiced" or a "non-voiced" frame each 22.5 ms. The first bit transmitted is bit 0 (least significant) of RC (1). For simplicity, the synchronization bit shall be carried through the type 1 packets. In addition, the 54-bit frame shall be padded out to 7 whole octets with 2 reserved bits. The format of the data unit transferred in the type 1 packet shall be as shown in Figure A-1 for voiced frames and Figure A-2 for non-voiced frames. These two frame types are distinguished by the content of the 7 bit P field. 8 7 6 5 4 3 2 1 RC(1)-0 RC(2)-0 RC(3)-0 P-0 R-0 RC(1)-1 RC(2)-1 RC(3)-1 1 P-1 R-1 RC(1)-2 RC(4)-0 RC(3)-2 R-2 P-2 RC(4)-1 2 RC(1)-3 RC(2)-2 RC(3)-3 RC(4)-2 R-3 RC(1)-4 RC(2)-3 RC(3)-4 3 RC(4)-3 R-4 P-3 RC(2)-4 RC(7)-0 RC(8)-0 P-4 RC(4)-4 4 RC(5)-0 RC(6)-0 RC(7)-1 RC(10)-0 RC(8)-1 RC(5)-1 RC(6)-1 RC(7)-2 5 RC(9)-0 P-5 RC(5)-2 RC(6)-2 RC(10)-1 RC(8)-2 P-6 RC(9)-1 6 RC(5)-3 RC(6)-3 RC(7)-3 RC(9)-2 RC(8)-3 Sync Reserved 7 P = Pitch R = RMS Amplitude RC(x) = Reflection Coefficient number x -n = bit of field, where bit 0 is the least significant bit Figure A-1: LPC-10 (Voiced frame) encoding data unit format 8 7 6 5 4 3 2 1 RC(1)-0 RC(2)-0 RC(3)-0 P-0 R-0 RC(1)-1 RC(2)-1 RC(3)-1 1 P-1 R-1 RC(1)-2 RC(4)-0 RC(3)-2 R-2 P-2 RC(4)-1 2 RC(1)-3 RC(2)-2 RC(3)-3 RC(4)-2 R-3 RC(1)-4 RC(2)-3 RC(3)-4 3 RC(4)-3 R-4 P-3 RC(2)-4 RC(3)-5 R-5 P-4 RC(4)-4 4 RC(1)-5 RC(2)-5 RC(3)-6 RC(4)-5 R-6 RC(1)-6 RC(2)-6 RC(3)-7 5 RC(4)-6 P-5 RC(1)-7 RC(2)-7 Unused R-7 P-6 RC(4)-7 6 RC(1)-8 RC(2)-8 RC(3)-8 RC(4)-8 R-8 Sync Reserved 7 Figure A-2: LPC-10 (Non-voiced frame) encoding data unit format A.3 Continuously Variable Slope delta (CVSD) 16 and 32 kbit/s This algorithm is defined in (US) MIL-STD-188-113 and is used over both long haul (non-tactical) and tactical communications systems. CVSD is a non-linear, sampled data, feedback system which accepts a band-limited analog signal and encodes it into binary form. The data unit format is based on accumulating 1 ms of data in chronological order and packing it into consecutive octets, beginning with the high order bit of the first octet. Formats for coding rates of 32 and 16 kbit/s are shown in Figures A-3 and A-4. 8 7 6 5 4 3 2 1 1st bit 1 2 3 last bit 4 Figure A-3 - CVSD 32 kbit/s encoding data unit format 8 7 6 5 4 3 2 1 1st bit 1 last bit 2 Figure A-4 - CVSD 16 kbit/s encoding data unit format A.4 Continuously Variable Slope delta (CVSD) 12 kbit/s The use of this algorithm is described in (US) Federal Standard 1023 of 25 Sept 1989. This algorithm is primarily intended to be used over FM radio systems and to utilize encryption equipment operating at 12 kbit/s. The data unit format is based on accumulating 10 ms of data in chronological order and packing it into consecutive octets, beginning with the high order bit of the first octet. The format is shown in Figure A-5. 8 7 6 5 4 3 2 1 1st bit 1 2 . . . . . . . . . 14 last bit 15 Figure A-5 - CVSD 12 kbit/s encoding data unit format Annex B: ATM Forum Predefined Profiles This Annex forms an integral part of this Specification. This annex defines a number of ATM Forum predefined profiles for use by voice/voiceband data connections using UUI codepoints 0-15 with type 1 packets. By making reference to the identifiers of these profiles, an IWFs can agree on the profile to be used for a connection. Inclusion in this Annex does not imply that all implementations are required to support every profile. An implementation may choose to support any or none of the profiles defined here. In addition, an implementation may support one or more profiles defined in I.366.2 or elsewhere. Identifiers for ATM Forum Predefined Profiles Identifier Description of Profile Reference 0 Not used - 1 LPC-10 (High efficiency) Table B-1 2 LPC-10 (Low delay) Table B-2 3 CVSD-32 Table B-3 4 CVSD-16 Table B-4 5 CVSD-12 Table B-5 6 G.723.1 Table B-6 7-255 Reserved for future ATM Forum assignment Note: For the use of these ATM Forum predefined profile identifiers see Table C.1. The table above lists the ATM Forum assigned code points that shall be used to identify predefined profiles and the remaining tables define the individual profiles. The definition of each profile includes the following information for each profile: * UUI codepoint range * Packet length * Reference to a figure (Annex A of this specification) depicting the encoding data unit format * Description of the algorithm * Value of M, the number of service data units in a packet * Packet time * Sequence number interval Table B-1 - Profile using LPC-10e for High Efficiency UUI Codepoint Range Packet Length (octets) Encoding Format Reference Description of Algorithm M Packet Time (ms) Seq. No. Interval (ms) 0 - 15 42 Figure A-1/ A-2 Linear Predictive Coding with 10 Reflection Coefficients 1 135 135 Table B-2 - Profile using LPC-10e for Low Delay UUI Codepoint Range Packet Length (octets) Encoding Format Reference Description of Algorithm M Packet Time (ms) Seq. No. Interval (ms) 0 - 15 14 Figure A-1/ A-2 Linear Predictive Coding with 10 Reflection Coefficients 1 45 45 Table B-3 - Profile using CVSD 32 kbit/s UUI Codepoint Range Packet Length (octets) Encoding Format Reference Description of Algorithm M Packet Time (ms) Seq. No. Interval (ms) 0 - 15 40 Figure A-3 CVSD 32 1 10 10 Table B-4 - Profile using CVSD 16 kbit/s UUI Codepoint Range Packet Length (octets) Encoding Format Reference Description of Algorithm M Packet Time (ms) Seq. No. Interval (ms) 0 - 15 40 Figure A-4 CVSD 16 1 20 20 Table B-5 - Profile using CVSD 12 kbit/s UUI Codepoint Range Packet Length (octets) Encoding Format Reference Description of Algorithm M Packet Time (ms) Seq. No. Interval (ms) 0 - 15 30 Figure A-5 CVSD 12 1 20 20 Table B-6 - Profile using G.723.1 UUI Codepoint Range Packet Length (octets) Encoding Format Reference Description of Algorithm M Packet Time (ms) Seq. No. Interval (ms) 0 - 15 24 Figure D-1/I.366.2 G.723.1 - 6.4 1 30 30 0 - 15 20 Figure D-2/I.366.2 G.723.1 - 5.3 1 30 30 0 - 15 4 Figure D-3/I.366.2 G.723.1 - SID 1 30 30 Annex C: Information Element Contents This Annex forms an integral part of this Specification. C.1 Signalling to Establish an AAL2 SVC The following information elements are used to establish an AAL2 SVC to contain bearer channels for narrowband calls and optionally CCS. These information elements are as defined in af-sig-0061.000 (UNI 4.0), Q.2931, and Q.2941.2. Values are specified for certain fields of the following information elements carried in SETUP: * ATM Adaptation Layer Parameters * ATM Traffic Descriptor * Broadband Bearer Capability * Broadband High Layer Information * Generic Identifier Transport * Quality of Service Parameters Fixed information element header fields and field identifiers that are omitted from the following tables must be inserted at appropriate points in the information elements when SETUP messages are generated. Other information elements listed in Sections 3.1.7 of Q.2931, as updated by Section 2.0 of af-sig-0061.000, remain optional. This specification places no requirements or constraints on the values of their fields. C.1.1 ATM Adaptation Layer Parameters The format of the ATM Adaptation Layer Parameters Information Element shall be as shown in Amendment 2 of Q.2931. The contents shall be encoded as shown in Table C-1. Table C-1: AAL Parameters IE Field Values for Establishment of AAL2 SVC for Trunking Field Value AAL Type (octet 5) '0000 0010' AAL Type 2 Maximum CPS-SDU size (octet 6.1) 45 Maximum number of multiplexed channels (octet 7.1) 8 to 255 (Note 1) SSCS Type (octet 8.1) '0001 0001' ITU-T Rec. I.366.2 (SSCS to provide trunking) Service Category (octet 9.1) '0000' Audio service CMD (octet 9.1) 0: Circuit mode data disabled 1: Circuit mode data enabled FMD (octet 9.1) 0: Frame mode data disabled 1: Frame mode data enabled Fax (octet 9.2) 0: Facsimile demodulation disabled 1: Facsimile demodulation enabled CAS (octet 9.2) 0: Channel associated signalling disabled 1: Channel associated signalling enabled (non-switched mode) DTMF (octet 9.2) 0: DTMF dialled digits disabled 1: DTMF dialled digits enabled MF-R1 (octet 9.2) 0: MF-R1 dialled digits disabled 1: MF-R1 dialled digits enabled (non-switched mode) MF-R2 (octet 9.2) 0: MF-R2 dialled digits disabled 1: MF-R2 dialled digits enabled (non-switched mode) PCM Encoding (octet 9.2) 0: Generic PCM encoded as A-law 1: Generic PCM encoded as (-law Maximum length of frame mode data unit (octets 10.1 and 10.2) 1 to 65535 Profile source (octet 11.1) '00' ITU-T predefined profile '01' Other predefined profile Predefined profile identifier (octet 11.2) 1 to 255 IEEE Organizationally Unique Identifier (octets 11.3, 11.4, and 11.5) Present if and only if the profile source (octet 11.1) is Other predefined profile. Note 1: The value placed in the maximum number of multiplexed channels field (octet 7.1) is the highest number CID value allocated for use. Note 2: To indicate an ATM Forum predefined profile, a profile identifier from Annex B is entered into octet 11.2 and the ATM Forum's OUI x'00A03E' into octets 11.3 to 11.5. C.1.2 ATM Traffic Descriptor The format of the ATM Traffic Descriptor Information Element shall be as shown in Section 4.5.6 of Q.2931 as updated by Section 2.0 of af-sig-0061.000. The contents shall be encoded as shown in Table C-2. Table C-2: ATM Traffic Descriptors IE Field Values for Establishment of AAL2 SVC for Trunking Field Value Forward peak cell rate CLP=0+1 (Octets 7.1, 7.2, 7.3) Must be provided Backward peak cell rate CLP=0+1 (Octets 8.1, 8.2, 8.3) Must be provided Forward SCR CLP=0+1 (Octets 11, 11.1, 11.2, 11.3) Must be provided if the ATC is Real time VBR Backward SCR CLP=0+1 (Octets 12, 12.1, 12.2, 12.3) Must be provided if the ATC is Real time VBR Forward MBS CLP=0+1 (Octets 15, 15.1, 15.2, 15.3) Must be provided if the ATC is Real time VBR Backward MBS CLP=0+1 (Octets 16, 16.1, 16.2, 16.3) Must be provided if the ATC is Real time VBR Traffic management options identifier (Octet 17) Must be omitted Best effort indicator (Octet 18) Must be omitted Note: It is recommend that other fields, for CLP=0, shown in Section 4.5.6 of Q.2931 be omitted. C.1.3 Broadband Bearer Capability The format of the Broadband Bearer Capability Information Element shall be as shown in Section 4.5.7 of Q.2931 as updated by Section 2.0 of af-sig-0061.000. The contents shall be encoded as shown in Table C-3. Table C-3: Broadband Bearer Capability IE Field Values for Establishment of AAL2 SVC for Trunking Field Value Bearer Class (octet 5) '10000' BCOB-X ATM Transfer Capability (octet 5a) '0000101' CBR '0001001' Real time VBR Susceptibility to clipping (octet 6) '00' Not susceptible to clipping User Plane Connection Configuration (octet 6) '00' Point-to-point C.1.4 Broadband High Layer Information The format of the Broadband High Layer Information IE shall be as shown in Section 4.5.8 of Q.2931 as updated by Section 2.0 of af-sig-0061.000. The contents shall be encoded as shown in Table C-4. This information element identifies that the signalling entities are ATM Forum IWFs as specified in this Specification. It also identifies the specific service and signalling approach. Table C-4: Broadband High Layer Information IE Field Values for Establishment of AAL2 SVC for Trunking Field Value High Layer Information Type (octet 5) '0000011' Vendor-Specific Application Identifier Organizationally Unique Identifier (OUI) (octets 6-8) x'00 A0 3E' ATM Forum OUI Application Identifier (AppId) (octets 9-10) x'00 03' Switched trunking using PSS1 between IWFs x'00 04' Switched trunking using DSS1 between IWFs x'00 05' Switched trunking using DPNSS between IWFs x'00 06' Switched trunking using other variety of CCS between IWFs x'00 07' Non-switched trunking using CAS between IWFs x'00 08' Non-switched trunking using CCS between IWFs x'00 09' Unspecified combination between IWFs (beyond the scope of this specification) C.1.5 Generic Identifier Transport The format of the Generic Identifier Transport Information Element shall be as shown in Section 2.1.1 of af-sig-0061.000 and Q.2941.2. The contents shall be encoded as shown in Table C-5. Table C-5: Generic Identifier Transport IE Field Values for Establishment of AAL2 SVC for Trunking Field Value Identifier Related Standard/Application (octet 5) '00001000' Recommendations/application using ATM VCC identifier for trunking (Note 1) Identifier Type (octet 6) '00001000' Bearer VCC identifier for trunking Identifier Length (octet 6.1) '00000010' Two octets Identifier Value (octet 6.2) '0Fxxxxxx' where: F(lag)=0: Message is sent from side that assigns the VCCI 'xxxxxx' the most significant bits of the VCCI Note: In this field, the value F(lag)=1 is invalid. Identifier Value (octet 6.3) '1xxxxxxx' where: 'xxxxxxx' The least significant bits of the VCCI Identifier Type (octet 7) '00001001' Signalling VCC identifier for trunking Identifier Length (octet 7.1) '00000010' Two octets Identifier Value (octet 7.2) '0Fxxxxxx' where: F(lag)=0: Message is sent from side that assigned the SigVCCI F(lag)=1: Message is sent to side that assigned the SigVCCI 'xxxxxx' the most significant bits of the SigVCCI Identifier Value (octet 7.3) '1xxxxxxx' where: 'xxxxxxx' The least significant bits of the SigVCCI Note 1: The name of this code point may change when Q.2941.2 is finalized. Note 2: The VCCI value in octets 6 through 6.3 is mandatory. Note 3: When SigVCCI is omitted and only the VCCI value is signalled, octets 7-7.3 are omitted. SigVCCI is present if and only if the AppId value in the B-HLI IE is x'00 03', x'00 04', x'00 05', x'00 06', or x'00 08'. C.1.6 Quality of Service Parameter The format of the Quality of Service Parameters Information Element shall be as shown in Section 4.5.18 of Q.2931 as updated by af-sig-0061.000. The contents shall be encoded as shown in Table C-6 when operating over networks that are compliant with the ATM Forum specifications and as shown in Table C-7 when operating over networks that are ITU conformant but not ATM Forum compliant. Table C-6: QoS Parameter IE Field Values for Establishment of AAL2 SVC for Trunking (ATM Forum Compliant Network) Field Value Coding Standard (octet 2) '11' Standard defined for the network QoS Class Forward (octet 5) '0000 0001' QoS Class 1 - for CBR '0000 0010' QoS Class 2 - for Real time VBR QoS Class Backward (octet 6) '0000 0001' QoS Class 1 - for CBR '0000 0010' QoS Class 2 - for Real time VBR Table C-7: QoS Parameter IE Field Values for Establishment of AAL2 SVC for Trunking (Non-ATM Forum Compliant Network) Field Value Coding Standard (octet 2) '00' ITU standard QoS Class Forward (octet 5) '0000 0000' QoS Class 0 - Unspecified QoS Class QoS Class Backward (octet 6) '0000 0000' QoS Class 0 - Unspecified QoS Class C.2 Signalling to Establish an AAL5 SVC The following information elements are used to establish an AAL5 SVC for CCS. These information elements are as defined in af-sig-0061.000 (UNI 4.0), Q.2931, Q.2941.1, and Q.2941.2. Values are specified for certain fields of the following information elements carried in SETUP: * ATM Adaptation Layer Parameters * ATM Traffic Descriptor * Broadband Bearer Capability * Broadband High Layer Information * Generic Identifier Transport * Quality of Service Parameters Fixed information element header fields and field identifiers that are omitted from the following tables must be inserted at appropriate points in the information elements when SETUP messages are generated. Other information elements listed in Sections 3.1.7 of Q.2931, as updated by Section 2.0 of af-sig-0061.000, remain optional. This specification places no requirements or constraints on the values of their fields. C.2.1 ATM Adaptation Layer Parameters The format of the ATM Adaptation Layer Parameters Information Element shall be as shown in Section 4.5.5 of Q.2931. The contents shall be encoded as shown in Table C-8. Table C-8: AAL Parameters IE Field Values for Establishment of AAL5 SVC for CCS Field Value AAL Type (octet 5) '0000 0101' AAL type 5 SSCS Type (octet 8.1) For switched trunking: '0000 0001' Data SSCS based on SSCOP (assured operation) For non-switched trunking: '0000 0000' Null C.2.2 ATM Traffic Descriptors The format of the ATM Traffic Descriptor Information Element shall be as shown in Section 4.5.6 of Q.2931 as updated by Section 2.0 of af-sig-0061.000. The contents shall be encoded as shown in Table C-9. Table C-9: ATM Traffic Descriptors IE Field Values for Establishment of AAL5 SVC for CCS Field Value Forward peak cell rate CLP=0+1 (Octets 7.1, 7.2, 7.3) Must be provided Backward peak cell rate CLP=0+1 (Octets 8.1, 8.2, 8.3) Must be provided Forward SCR CLP=0+1 (Octets 11, 11.1, 11.2, 11.3) Must be provided Backward SCR CLP=0+1 (Octets 12, 12.1, 12.2, 12.3) Must be provided Forward MBS CLP=0+1 (Octets 15, 15.1, 15.2, 15.3) Must be provided Backward MBS CLP=0+1 (Octets 16, 16.1, 16.2, 16.3) Must be provided Traffic management options identifier (Octet 17) Must be omitted Best effort indicator (Octet 18) Must be omitted Note: It is recommend that other fields, for CLP=0, shown in Section 4.5.6 of Q.2931 be omitted. C.2.3 Broadband Bearer Capability The format of the Broadband Bearer Capability Information Element shall be as shown in Section 4.5.7 of Q.2931 as updated by Section 2.0 of af-sig-0061.000. The contents shall be encoded as shown in Table C-10. Table C-10: Broadband Bearer Capability IE Field Values for Establishment of AAL5 SVC for CCS Field Value Bearer Class (octet 5) '10000' BCOB-X ATM Transfer Capability (octet 5a) '0001010' Non-real time VBR Susceptibility to clipping (octet 6) '00' Not susceptible to clipping User plane connection configuration (octet 6) '00' Point-to-point C.2.4 Broadband High layer Information Element The format of the Broadband High Layer Information IE shall be as shown in Section 4.5.8 of Q.2931 as updated by Section 2.0 of af-sig-0061.000. The contents shall be encoded as shown in Table C-11. Table C-11: Broadband High Layer Information IE Field Values for Establishment of AAL5 SVC for CCS Field Value High Layer Information Type (octet 5) '0000011' Vendor-Specific Application Identifier Organizational Unit Identifier (OUI) (octets 6-8) x'00 A0 3E' ATM Forum OUI Application Identifier (AppId) (octets 9-10) x'00 03' Switched trunking using PSS1 between IWFs x'00 04' Switched trunking using DSS1 between IWFs x'00 05' Switched trunking using DPNSS between IWFs x'00 06' Switched trunking using other variety of CCS between IWFs x'00 08' Non-switched trunking using CCS between IWFs C.2.5 Generic Identifier Transport The format of the Generic Identifier Transport Information Element shall be as shown in Section 2.1.1 of af-sig-0061.000 and Q.2941.2. The contents shall be encoded as shown in Table C-12. Table C-12: Generic Identifier Transport IE Field Values for Establishment of AAL5 SVC for CCS Field Value Identifier Related Standard/Application (octet 5) '00001000' Recommendations/application using ATM VCC identifier for trunking (Note 1) Identifier Type (octet 6) '00001001' Signalling VCC identifier Identifier Length (octet 6.1) '00000010' Two octets Identifier Value (octet 6.2) '0Fxxxxxx' where: F(lag)=0: Message is sent from side that assigns the SigVCCI 'xxxxxx' the most significant bits of the SigVCCI Note: In this field, the value F(lag)=1 is invalid. Identifier Value (octet 6.3) '1xxxxxxx' where: 'xxxxxxx' The least significant bits of the SigVCCI Note 1: The name of this code point may change when Q.2941.2 is finalized. C.2.6 Quality of Service Parameters The format of the Quality of Service Parameters Information Element shall be as shown in Section 4.5.18 of Q.2931 as updated by af-sig-0061.000. The contents shall be encoded as shown in Table C-13 when operating over networks that are compliant with the ATM Forum specifications and as shown in Table C-14 when operating over networks that are ITU conformant but not ATM Forum compliant. Table C-13: QoS Parameter IE Field Values for Establishment of AAL5 SVC for CCS (ATM Forum Compliant Network) Field Value Coding standard (octet 2) '11' Standard defined for the network QoS Class Forward (octet 5) '0000 0011' QoS Class 3 - for connection oriented protocol QoS Class Backward (octet 6) '0000 0011' QoS Class 3 - for connection oriented protocol Table C-14: QoS Parameter IE Field Values for Establishment of AAL5 SVC for CCS (Non-ATM Forum Compliant Network) Field Value Coding standard (octet 2) '00' ITU standard QoS Class Forward (octet 5) '0000 0000' QoS Class 0 - Unspecified QoS class QoS Class Backward (octet 6) '0000 0000' QoS Class 0 - Unspecified QoS class C.3 Signalling to Associate AAL2 Channel With Narrowband Calls The Channel ID information element as defined in Q.931 Section 4.5.13 is used in the IWF-IWF signalling channel to identify an AAL2 channel of an ATM VCC. The fields shall be coded as shown in Table C-15. Since the channel negotiation procedures do not apply, octet 3 shall be coded to indicate "exclusive". Table C-15: Channel Id IE Field Values for Assignment of AAL2 Channel Field Value (octet 3) '10101001' if octets 3.1.1 and 3.1.2 are omitted (Note 1) '11101001' if octets 3.1.1 and 3.1.2 are present Interface ID (octet 3.1.1) VCCI from GIT IE (Table C.1.5 octet 6.2) (ext bit = 0 + flag + upper 6 bits) Interface ID (octet 3.1.2) VCCI from GIT IE (Table C.1.5 octet 6.3) (ext bit = 1 + lower 7 bits) Coding Standard (octet 3.2) '11' standard defined for the network Number/Map (octet 3.2) '0' Channel is indicated by number Channel Type (octet 3.2) '1011' Channel within ATM VCC Channel Number (octet 3.3.1) CID value (Notes 2, 3) (ext bit = 0 + 000000 + high order bit of CID) Channel Number (octet 3.3.2) CID value (Notes 2, 3) (ext bit = 1 + lower 7 bits of CID) Note 1: If octets 3.1.1 and 3.1.2 are omitted, the CID reference is to the same AAL2 VCC that carries the IWF-IWF signalling message. Octets 3.1.1 and 3.1.2 are required when a separate AAL5 VCC or an AAL2 channel in a different VCC is used for IWF-IWF signalling. Note 2: Channel Number values of 9 - 255 are allowed. Note 3: The encoding of octets 3.3.1 and 3.3.2 is based on ISO/IEC 11572, Table 31, Channel Identification IE, Note 5, "This octet may be extended if the channel number exceeds 127". It departs from the usage of Q.931, where the extension bit is intended to indicate that the next octet contains another channel number in a list, not an extension of a single number to additional bits. End of Document Page af-vtoa-0113.000 ATM Trunking using AAL2 for Narrowband Services ATM Trunking using AAL2 for Narrowband Services af-vtoa-0113.000 Page ATM Forum Technical Committee Page af-vtoa-0113.000 ATM Trunking using AAL2 for Narrowband Services ATM Trunking using AAL2 for Narrowband Services af-vtoa-0113.000 Page ATM Forum Technical Committee Page