^^J^JI^^^^cial Publication 823-3

Computer

Systems North American Integrated

, Technology

Services Digital Network Users U.S. DEPARTMENT OF O

?«yAdminis,,a,ion

National Institute of Forum \

' t Agrcenients O r'^.r: 5 on.' ISDN '

- QC

100

.U57

//823-3

1993
/he National Institute of Standards and Technology was established in 1988 by Congress to "assist

industry in the development of technology . . . needed to improve product quality, to modernize

manufacturing processes, to ensure product reliability . . . and to facilitate rapid commercialization . . . of products based on new scientific discoveries."

NIST, originally founded as the National Bureau of Standards in 1901, works to strengthen U.S.

industry's competitiveness; advance science and engineering; and improve public health, safety, and the

environment. One of the agency's basic functions is to develop, maintain, and retain custody of the

national standards of measurement, and provide the means and methods for comparing standards used

In science, engineering, manufacturing, commerce, industry, and education with the standards adopted

or recognized by the Federal Government.

As an agency of the U.S. Commerce Department's Technology Administration, NIST conducts basic

and applied research in the physical sciences and engineering and performs related services. The Institute

does generic and precompetitive work on new and advanced technologies. NIST's research facilities are

located at Gaithersburg, MD 20899, and at Boulder, CO 80303. Major technical operating units and their

principal activities are listed below. For more information contact the Public Inquiries Desk, 301-975-3058.

Technology Services

• Manufacturing Technology Centers Program

• Standards Services

• Technology Commercialization

• Measurement Services

• Technology Evaluation and Assessment

• Information Services

Electronics and Electrical Engineering

Laboratory

• Microelectronics

• Law Enforcement Standards

• Electricity

• Semiconductor Electronics

• Electromagnetic Fields^

• Electromagnetic Technology^

Chemical Science and Technology

Laboratory

• Biotechnology

• Chemical Engineering^

• Chemical Kinetics and Thermodynamics

• Inorganic Analytical Research

• Organic Analytical Research

• Process Measurements

• Surface and Microanalysis Science

• Thermophysics^

Physics Laboratory

• Electron and Optical Physics

• Atomic Physics

• Molecular Physics

• Radiometric Physics

• Quantum Metrology

• Ionizing Radiation

• Time and Frequency^

• Quantum Physics^

Manufacturing Engineering Laboratory

• Precision Engineering

• Automated Production Technology

• Robot Systems

• Factory Automation

• Fabrication Technology

Materials Science and Engineering

Laboratory

• Intelligent Processing of Materials

• Ceramics

• Materials Reliability^

• Polymers

• Metallurgy

• Reactor Radiation

Building and Fire Research Laboratory

• structures

• Building Materials

• Building Environment

• Fire Science and Engineering

• Fire Measurement and Research

Computer Systems Laboratory

• Information Systems Engineering

• Systems and Software Technology

• Computer Security

• Systems and Network Architecture

• Advanced Systems

Computing and Applied Mathematics

Laboratory

• Applied and Computational Mathematics^

• Statistical Engineering^

• Scientific Computing Environments^

• Computer Services^

• Computer Systems and Communications^

• Information Systems

'At Boulder, CO 80303.

^Some elements at Boulder, CO 80303.
NIST Special Publication 823-3 f,^

North American Integrated

Services Digital Network Users'

Forum Agreements on ISDN

Daniel P. Stokesberry, Kathleen M. Roberts,

and Tish Antonishek, Editors

Advanced Systems Division

Computer Systems Laboratory

National Institute of Standards and Technology

Gaithersburg, MD 20899

January 1993

U.S. DEPARTMENT OF COMMERCE

Ronald H. Brown, Secretary

NATIONAL INSTITUTE OF STANDARDS

AND TECHNOLOGY

John W. Lyons, Director
Reports on Computer Systems Technology

The National Institute of Standards and Technology (NIST) has a unique responsibility for computer

systems technology within the Federal government. NIST's Computer Systems Laboratory (CSL) develops standards and guidelines, provides technical assistance, and conducts research for computers and

related telecommunications systems to achieve more effective utilization of Federal information technology resources. CSL's responsibilities include development of technical, management, physical, and administrative standards and guidelines for the cost-effective security and privacy of sensitive unclassified

information processed in Federal computers. CSL assists agencies in developing security plans and in improving computer security awareness training. This Special Publication 823 series reports CSL re- search and guidelines to Federal agencies as well as to organizations in industry, government, and

academia.

National Institute of Standards and Technology Special Publication 823-3

Natl. Inst. Stand. Technol. Spec. Publ. 823-3, 238 pages (Jan. 1993)

CODEN: NSPUE2

U.S. GOVERNMENT PRINTING OFFICE

WASHINGTON: 1993

For sale by the Superintendent of Documents, U.S. Government Printing Office, Washington, DC 20402
North American ISDN Users' Forum

Agreements on ISDN

ABSTRACT

This document compiles the existing NIU-Forum agreements for an ISDN developed and approved in the NIUForum as of October 1991. These agreements cover: Layer 1 BRI at the U, and S/T reference points; Layer 1 PRI at the U/S/T reference points; Layer 2 BRI and PRI; Layer 3 BRI Basic Call Control for Class I equipment;

Layer 3 PRI Basic Call Control for Class II equipment; and Generic Control procedures for Class I BRI

Supplementary Services. In addition, this document references the Conformance tests which have been

completed by the NIU-Forum. These include: Layer 1 BRI S/T interface; and Layer 2 BRI LAPD. Finally, this document contains the Application Profiles for: four of the Incoming Call Management applications; the

Building Controls appUcation; the Data Conferencing - Point-to-Point application; the ISDN Station Event

Recording application; and tlaree of the Voice Messaging System applications which have been submitted to the

NIU-Forum.

KEY WORDS

application profile; basic call control; basic rate interface; conformance test; customer premises equipment; data

link layer; implementation agreements; ISDN; LAPD; network layer; network termination; NIU-Forum; physical

layer; primary rate interface; S/T interface; terminal adapter; terminal equipment; U Interface.

iii
i

I

i

NOTICE OF DISCLAIMER

I

I

I

I This document compiles NIU-Forum voluntary agreements among participating expert technical \

personnel to the texts of isdn standards, configurations and descriptions that are intended to

promote interoperability and efficiency. these agreements were developed and approved by

organizations participating in the north american isdn users' forum (niuf) meetings as of

October 1991. In the October 1991 meeting, participants in the NIUF Plenary agreed to publish j ALL AGREEMENTS APPROVED AS OF THAT MEETING. NEITHER THE NATIONAL INSTITUTE OF STANDARDS AND

j Technology nor any of the participants in the NIUF make any representation or warranty,

EXPRESS OR implied WITH RESPECT TO THE SUFFICIENCY, ACCURACY, OR USE OF ANY INFORMATION OR OPINION

CONTAINED HEREIN. THE USE OF THIS INFORMATION OR OPINION IS AT THE RISK OF THE USER. UNDER NO

CIRCUMSTANCES SHALL NIST, OR ANY PARTICIPANT IN THE NIUF BE LIABLE FOR ANY DAMAGE OR INJURY

INCURRED BY ANY PERSON ARISING OUT OF THE SUFFICIENCY, ACCURACY, OR USE OF ANY INFORMATION OR

OPINION CONTAINED HEREIN.

NIST does not recommend or endorse products and nothing contained herein is intended as a recommendation or endorsement of any product.

iv
ACKNOWLEDGMENTS

NIST would like to acknowledge all of the members and participants, past and present, in the North American

ISDN Users' Forum for their valuable conU"ibutions to this document.

WORKSHOP AND WORKING GROUP CHAIRS

lUW Chair

nW Chair

Claude Stone

Don Auble

First Nat'l Bank of Chicago

Ameritech Services

NIUF Secretariat NIUF Asst. Secretariat

Dawn Hoffman

Sara (Johnson) Caswell

NIST

NIST

lUW INDUSTRY GROUPS

Computer and Telecommunications

Financial/Services

Government Services

Manufacturing

Small Business

Rick Zipes

Martin Risbergs

James Johnson

Karl Schohl

George Abbott

Mitel

American Airlines U.S. Air Force

GM

North Carolina State University

lUW AD HOC COMMITTEES

Applications Review

Public Policy and Strategic Planning

EDI

Broadband ISDN

Scott Beale

David Norem

Claude Stone

Bob Doxey

Aeronautical Radio, Inc. DoD

First Nat'l Bank of Chicago

Pacific Bell

lUW APPLICATION FAMILIES

Network Management/ISDN

Administration

Call Management

CPE Compatibilities and Capabilities

Network Interconnectivity

Messaging and Answering

Issues

N/A

Scott Beale

Pat Krause

Rick Zipes

Karen Patten

J Karen Patten

•^Bill Selmeier

Aeronautical Radio, Inc. McDonald's Corporation

Mitel

AT&T Bell Labs

AT&T Bell Labs

Dowty Network Systems, Inc. nW EXPERT GROUPS

Applications Analysis

Applications Software Interface ISDN Conformance Testing

Network Management

ISDN Security

Satellite, Radio, and Mobile

Signalling

Supplementary Services

Bob Sherry

Cheng Chen

Matt Martini

Tom Russotto Jonathan Katz

.lohn Kennedy

John Kantonides

Chris Wallace

AT&T Bell Labs

Teleos Communications

NYNEX

American Computer

TASC

Northern Telecom Canada Ltd. AT&T Bell Labs

Bell Northern Research

nW PROFILE TEAMS

Call Management

CPE Compatibilities and Capabilities

Messaging and Answering

Network Interconnectivity

Network Management/ISDN Admin.

Security

George Gawrys

Bob Larribeau

Glenn Ehley

Ira Clark

Tom Russotto William Few

AT&T

Fujitsu

Siemens Stromberg-Carlson

DGM&S

American Computer

DoD

IIW AD HOC COMMITTEES

Versions

Application Profile Development

Gerry Hopkins

Gerry Hopkins

Bell Atlantic

Bell Atlantic

EXECUTIVE STEERING COMMITTEE STANDING GROUPS

Applications Services Group

Finance Committee

Matt ITiomson

James Kendrick

Northern Telecom

Aeronautical Radio, Inc.

V

TABLE OF CONTENTS

ABSTRACT iii

NOTICE OF DISCLAIMER iv

ACKNOWLEDGMENTS v

1 Introduction 1-1

1.1 Purpose of this Document 1-1

1.2 Evolution of this Document 1-1

1.3 Document Organization 1-1

1.4 NIU-Forum Overview 1-2

1.4.1 Purpose of the Forum , 1-2

1.4.2 NIU-Forum/NIST Relationship 1-2

1.4.3 NIU-Forum Organization and Procedures 1-3

1.4.3.1 ISDN Users' Workshop (lUW) 1-3

1.4.3.2 ISDN Implementors' Workshop (HW) 1-4

1.4.4 ISDN Versions 1-4

1.5 Point of Contact 1-4

2 Future ISDN Versions 2-1

3 Implementation Configurations , 3-1

4 Implementation Agreements 4-1

4.1 ISDN Lower Layer Specifications 4-1

4.1.1 Layer 1 Basic Rate Interface (BRI) 4-1

4.1.1.1 U Reference Point 4-1

4.1.1.2 S and T Reference Points 4-1

4.1.2 Layer 1 Primary Rate Interface (PRI) 4-2

4.1.2.1 S, T, and U Reference Points 4-2

4.1.3 Layer 2 BRI and PRI 4-2

4.1.4 Layer 3 BRI and PRI 4-2

4.1.4.1 Circuit-Switched Call Control Procedures 4-3

4.1.4.1.1 Basic Call Control Procedures 4-3

4.1.4.1.2 Supplementary Services Control Procedures 4-3

4.1.4.2 Packet-Switched Call Control Procedures 4-4

4.2 Future Basic Bearer Services Specification 4-5

4.2.1 Future Minimal Set of BRI Services 4-5

4.2.2 Future Minimal Set of PRI Services , 4-5

4.3 Future Supplementary Services Specification 4-6

4.4 ISDN Terminal Adaptation Specification 4-6

4.4.1 Future Circuit-Mode Data Terminal Adaptation 4-6

4.4.2 Packet-Mode Data Terminal Adaptation 4-6

4.5 ISDN Management Specification 4-6

4.5.1 Future Layer 1 BRI 4-6

4.5.2 Future Layer 1 PRI 4-6

4.5.3 Future Layer 2 and 3, BRI and PRI 4-6

4.6 Future Common Channel Signalling — Signalling System #7 . . , 4-7

5 ISDN Conformance Test Specifications 5-1

5.1 Layer 1 BRI 5-1 5.2 Future Layer 1 PRI 5-1

5.3 Layer 2 BRI 5-1 5.4 Future Layer 2 PRI 5-2

5.5 Future Layer 3 5-2

6 Application Software Interface (ASI) 6-1

6.1 Introduction To The ASI 6-1

vii
6.1.1 Overview 6-1

6.1.2 Charter 6-1

6.1.3 Goals 6-2

6.1.4 Purpose 6-2

6.1.5 Scope 6-3

6.1.6 Assumptions 6-4

6.2 Technical Overview 6-5

6.2.1 Application Software Interface Definition 6-6

6.2.2 OSI Reference Model Positioning 6-7

6.2.3 Teleservices Architecture 6-7

6.2.4 ASI Sessions 6-8

6.2.5 ASI Components 6-9

6.2.5.1 Access Methods 6-9

6.2.5.2 Messages 6-9

6.2.5.3 Encoding 6-9

7 Application Profiles 7-1

7.1 NIU-Forum Application Profiles 7-1

7.1.1 Application Profile Conformance 7-1

7.1.2 Application Profile Families 7-1

7.2 ISDN Call Management 7-2

7.2.1 Incoming Call Management 7-2

7.2.1.1 Abstract 7-2

7.2.1.2 User Description 7-2

7.2.1.3 ISDN Application Breakdown 7-2

7.2.1.3.1 Service Logic 7-4

7.2.1.4 Call Transfer with Associated Data Service Element 7-4

7.2.1.4.1 User Environment 7-8

7.2.1.4.2 Alternative Architectures 7-8

7.2.1.4.3 Information Flow 7-8

7.2.1.4.4 Network Signalling Requirements — Protocol

Identification 7-11

7.2.1.4.5 Protocol Description 7-11

7.2.1.5 Call Delivery with Associated Data Service Element 7-14

7.2.1.5.1 User Environment 7-14

7.2.1.5.2 Alternative Architectures 7-16

7.2.1.5.3 Information Flow 7-16

7.2.1.5.4 Network Signalling Requirements — Protocol

Identification 7-19

7.2.1.5.5 Protocol Description 7-19

7.2.1.6 Call Back on Busy/Abandonment Service Element 7-21

7.2.1.6.1 User Environment 7-21

7.2.1.6.2 Architecture 7-21

7.2.1.6.3 Information Flow 7-23

7.2.1.6.4 Network SignaUing Requirements . 7-23

7.2.1.6.5 Protocol Description 7-23

7.2.1.7 Terminal Connectivity Service Element 7-26

7.2.1.7.1 User Environment 7-26

7.2.1.7.2 Information Flow 7-26

7.2.1.7.3 Network Protocol Requirements 7-28

7.2.1.7.4 Protocol Description 7-28

7.2.1.8 Protocol Summary and Status 7-29

7.3 ISDN CPE Compatibility/Capability 7-30

7.3.1 Building Controls 7-30

7.3.1.1 User Description 7-30

7.3.1.2 Terminal Adapter Functional Requirements 7-30

7.3.1.3 Application Architecture 7-31

7.3.1.3.1 Layer 1 Architecture 7-32

7.3.1.3.2 Layer 2 Architecture 7-32

7.3.1.3.3 Layer 3 Architecture 7-32

7.4 ISDN Network Interconnectivity 7-35

viii
7.4.1 Data Conferencing (Point-to-Point) 7-35

7.4.1.1 Scope 7-35

7.4.1.2 Field Of Application 7-35

7.4.1.3 References 7-35

7.4.1.4 Definitions 7-36

7.4.1.5 pAP 810004 Requirements List 7-37

7.4.1.6 pAP 810004 Conformance Requirements 7-39

7.4.1.7 pAP 810004 Configurator 7-39

7.4.1.8 Attachment 1 — Proposed Application Profile (pAP) Overview 7-48

7.4.1.9 Attachment 2 — pAP Taxonomy Overview 7-49

7.4.1.10 Attachment 3 — pAP 810004 Tutorial 7-51

7.4.1.11 Attachment 4 — Application Profile (pAP) Taxonomy 7-54

7.4.1.11.1 Other Profile Taxonomy Matters 7-58

7.4.1.12 Attachment 5 — ISDN RL Structure 7-63

7.5 Messaging and Answering 7-65

7.5.1 Voice Messaging Systems 7-65

7.5.1.1 User Description 7-65

7.5.1.2 ISDN Application Breakdown 7-67

7.5.1.2.1 Call Answering 7-67

7.5.1.2.2 Call Answering With Call Transfer To An Attendant Or Pager

Notification 7-67

7.5.1.2.3 Direct Access To Voice Mail 7-67

7.5.1.3 Service Logic 7-67

7.5.1.4 Messaging And Answering Application Process 7-67

7.5.1.4.1 Subscriber Access 7-67

7.5.1.4.2 Application Process Description 7-70

7.5.1.4.3 Subscriber Notification 7-85

7.5.1.4.4 Subscriber Retrieval 7-94

7.5.1.4.5 Summary of MA processes 7-97

7.6 Future Bandwidth Negotiation 7-99

7.7 Network Management/ISDN Administration 7-100

7.7.1 ISDN Station Event Recording aSER) 7-100

7.7.1.1 Basic Description 7-100

7.7.1.2 Functional Requirements ... 7-100

7.7.1.2.1 Standard Interface Protocol 7-102

7.7.1.2.2 ISER Configuration Profile 7-102

7.7.1.2.3 Standard ISER Data Delivery Format 7-105

8 References 8-1

Appendix A. NIU 90-301 Implementation Agreement of the North American ISDN Users' Forum for Layer 3

Signalling Specification for the Minimal Set of Circuit-Switched Bearer Services for the ISDN Basic Rate

Interface/Class I A-1

A.l Abstract A-1

A.2 Introduction A-2

A.3 NIU 90-301 Delta List A-2

Appendix B. NIU 90-302 Implementation Agreement of the North American ISDN Users' Forum for Layer 3

Signalling Specification for the Minimal Set of Circuit-Switched Bearer Services for the ISDN Primary

Rate Interface/Class 11 B-1

B. l Abstract B-1

B.2 Introduction B-2

B.3 NIU 90-302 Delta List B-2

ix
ii4
1 Introduction

The purpose of the Integrated Services Digital Network (ISDN) Agreements document, its organization and an overview of the North American ISDN Users' Forum (NIU-Forum) are described in the following subsections.

1.1 Purpose of this Document

Participants in the October 1991 NIU-Forum Plenary meeting, approved a motion to publish all agreements reached among the members as of October 1991. This document is a compilation of

these NIU-Forum agreements for an ISDN.

1.2 Evolution of this Document

New versions of this document will be issued as progress is made in developing and approving

implementation agreements, conformance tests, and application profiles within the NIU-Forum.

It is the intent of the NIU-Forum, that each new version be compatible with previous versions.

Therefore, each revision will supersede preceding versions, as each new version will include all of the unchanged agreements from previous versions, as well as errata pages for previously

approved agreements.

1.3 Document Organization

The ISDN Agreements document is organized into specific sections as follows:

• Section 1 Introduction — The purpose of this document, the document organization, and an overview of the structure and organization of the NIU-Forum.

• Section 2

ISDN Versions — A specific interoperable subset of an ISDN which functions in a multivendor environment.

• Section 3

Implementation Configurations — A categorization of the ISDN capabilities, based upon

access and equipment class information.

• Section 4

Implementation Agreements — The Implementation Agreements (lAs) are developed by

both implementor and user representatives participating in the NIU-Forum Expert Working

Groups. The lAs provided in this section allow for expeditious development of ISDN

capabilities, and promote interoperability of ISDN communications equipments.

• Section 5

ISDN Conformance Test Specifications — Conformance Test (CT) suites for an ISDN

aie detailed in this section of the agreements.

NIU-Forum Agreements On ISDN 1-1
• Section 6

Application Software Interface — The Application Software Interface (ASI) section will

focus on the definition of a common application interface for accessing and administering

ISDN services provided by Network Adapters.

• Section 7

Application Profiles — The Application Profiles (APs) contain the recommended set of

agreements and specifications for all layers and aspects of ISDN communication which

must be present to support a particular user's application or set of applications (application

family).

• Section 8

References — The References section provides a listing of documents identified but not

included in this publication.

1.4 NIU-Forum Overview

The following text introduces the NIU-Forum purpose and organization.

1.4.1 Purpose of the Forum

The Integrated Services Digital Network (ISDN) is defined in a group of international

recommendations for a worldwide communications network for the exchange of all information

(voice, data, and image) among all users, independent of any manufacturer, service provider, or implementation technology.

ISDN recommendations are being developed by the International Telephone and Telegraph

Consultative Committee (CCITT). In North America, the ISDN standards are being developed by

Committee Tl, which is accredited by the American National Standards Institute (ANSI) and

sponsored by the Exchange Carriers Standards Association (ECSA).

The result is one extensive standard with a tremendous variety of options and parameters. This

-is necessary to meet all the possible needs and technologies for which the standards could be used.

However, to ensure interoperability and terminal portability within the ISDN network and its attendant terminals and other Customer Premises Equipment (CPE), a uniform subset of these

options and parameters must be selected. Each apphcation usually only requires a subset of

functionality and in order for products to work together in a multi-vendor environment, common

sets of options must be selected.

To cope with this proliferation of choices and to provide practical products and services which

meet users' needs, the specification process must be extended to include Application Profiles,

Implementation Agreements, and Conformance tests to promote interoperability.

1.4.2 NIU-Forum/NIST Relationship

The North American ISDN Users' Forum has created a user voice in the implementation of ISDN

and ISDN applications and has helped to ensure that the emerging ISDN environment meets users'

application needs. The NIU-Forum is sponsored by the National Institute of Standards and

Technology (NIST). The precise relationship of the NIU-Forum, NIST, and other business

NIU-Forum Agreements on ISDN
concerns is defined by the "Cooperative Research and Development Agreement: The Consortium on ISDN Based Systems."'

1.4.3 NIU-Forum Organization and Procedures

The actual work of the NIU-Forum is accomplished in two workshops; the ISDN Users' Workshop

(lUW) and the ISDN Implementors' Workshop (IIW). These workshops, which consist of various

working groups and special project teams, meet several times a year and develop the following

products: Application Requirements, Application Analyses, Application Profiles, Implementation

Agreements, Conformance Criteria, and an Applications Software Interface. The lUW produces

Application Requirements which describe potential apphcations of ISDN and the features which

may be required.

The IIW develops Application Analyses, Application Profiles, Implementation Agreements,

Conformance Criteria, and an Applications Software Interface which provide the technical detail

necessary to implement an Application Requirement in an interoperable manner.

The activities within the two workshops are coordinated by the NIU-Forum Executive Steering

Committee. While specifics of the NIU-Forum organization follow, particulars relating to the

procedures for the NIU-Forum are found in the "North American ISDN Users' Forum Practices

Manual."^

1.4.3.1 ISDN Users' Workshop (lUW)

The lUW is responsible for identifying, defining, and prioritizing user requirements, as well as working with the IIW to define and approve agreements necessary to support the implementation

of user requirements. Membership in the lUW is open to any organization. Users participating

in the IlAV are organized into seven Industry Groups: Manufacturing Industries, Process

Industries, Service Industries, Small Business, Financial Services, Government, and Computing and

Telecommunications Industries. The lUW organization emphasizes the synergy present when

organizations from the same industry segment work together to define applications. Activities

within the lUW are coordinated by the lUW Steering Committee.

The lUW work program is based on identifying potential user applications and structuring the IIW

work to satisfy the user applications. Any user can request consideration for a particular ISDN

application. The request should be for an application which could be used to support business

related operations. It is important that ISDN solutions to business problems be based on business

considerations which include:

• cost reductions

• prcxluctivity enhancements

• standard application interfaces

• and performance improvements.

'For more information, contact the NIU-Forum Administrator (see sec. 1.5).

^Ibid.

NIU-Forum Agreements On ISDN 1-3
For a detailed description of the "User Application" Processing within the ISDN Users' Workshop,

please refer to "North American ISDN Users' Forum Practices Manual."^

1.4.3.2 ISDN Implementors' Workshop (HW)

The nw is responsible for developing Application Analyses, Application Profiles, Implementation

Agreements, Conformance Criteria, and an Applications Software Interface in support of lUW

defined Application Requirements. The IIW also provides technical advice and consultafion to the

lUW, sponsors multi-vendor demonstrations and trials, and provides formal liaisons with

appropriate organizations such as the Corporation for Open Systems (COS), the Open Systems

Interconnection (OSI) Implementors' Workshop (OIW), or the ANSI Accredited Standards

Committee Tl. Membership in the IIW is open to any organization.

The IIW Steering Committee is responsible for coordinating the activities of the IIW groups. The

IIW is organized into the following groups:

• Applications Analysis Working Group (WG)

• Application Profile Teams

• Expert WGs

• ISDN Conformance Test aCOT) WG.

The Applications Analysis WG develops an analysis of the user's application requirements, which

serves as a basis for development of the Application Profile by the Applications Profile Teams.

The Expert WGs produce the Implementation Agreements that are generally based on ANSI

standards. In addition, there is an Expert WG defining an Applications Software Interface. The

ICOT WG defines conformance requirements and develops abstract test suites for Implementation

Agreements and Application Profiles.

1.4.4 ISDN Versions

A version defines and specifies ISDN as it exists at a certain point in time as derived from existing

national and international standards and other consensus activities. Each version should be

-Completely compatible with earlier versions. Manufacturers and service providers would be

expected to develop ISDN offerings based on a particular version.

1.5 Point of Contact

Further information about the NIU-Forum, including information on specific groups or activities within the NIU-Forum can be obtained by contacting:

NIU-Forum Secretariat

National Institute of Standards and Technology

Building 223, Room B364

Gaithersburg, Maryland 20899

(301) 975-2937

^Ibid.

1-4 NIU-Forum Agreements on ISDN
2 Future ISDN Versions

Editor's Note: This section is reserved for future agreements on the definition and specification

of ISDN Versions.

NIU-Forum Agreements On ISDN 2-1

3 Implementation Conflgurations

The ISDN architecture is intended to interconnect all user and network equipments, in a ubiquitous

fashion, to provide a common network encompassing all possible conmiunication scenarios.

Because of this broad scope, the national standards for the ISDN could not be universally applied

to all the conceivable combinations of equipment types, access arrangements and applications. The

concept of implementation configurations is introduced to allow specific ISDN capabilities

(procedures) to be associated with a class of equipment, an access arrangement, or an application.

The use of the equipment class/access arrangement terminology permits clarification of the

circumstances under which a certain capability should be available (i.e., when a particular

equipment class is in use). It also permits a mechanism for indicating that a particular capability

applies only to a subset of four possible configurations.

The implementation configurations, which were defined by the NIU-Forum Signalling Working

Group (SWG), have been applied to tlie layer 3 circuit-switched signalling protocols only. Future

work will evaluate the implementation configuration concept for applicability to all agreements

emerging from the NIU-Forum.

The following text provides the current description of implementation configurations from the

SWG:

The concept of equipment classes is introduced in this document to permit certain procedures to be associated with a particular application or class of equipment, e.g., station equipment versus

Private Branch Exchange (PBX). Specifically, two classes of equipment are defined on the basis

of two fundamental attributes.

The first attribute relates to the possibility of an exchange of signals occurring beyond the pubhc

network's point of contact with the interface (i.e., between the equipment directly connected to the

public network and ISDN terminals or telephones connected to that equipment). For example,

some user equipment may support subtending Basic Access digital subscriber loops and/or analog

telephone loops. For Class I equipment, the network makes no provision for such an arrangement

and assumes the Class I equipment constitutes the endpoint of the communication. Conversely,

in the case of Class II equipment, the procedures at the network take into account that

communication between Class II equipment (with which it communicates directly) and other

equipment (with which the network does not have direct contact) may occur. As an example. Class

II equipment may support digital and/or analog subscriber loops. Use of Class 11 equipment also

involves the possibility of having interworking occur beyond the equipment with which the network

has direct contact. Therefore, it is reasonable for Class II equipment to provide the network with an interworking notification, for both outgoing and incoming calls, when either the calling or called

party respectively, is a non-ISDN user. Class II equipment may also send an interworking

notification, if a private network exists beyond the Class II equipment and interworking to a non- ISDN facility within that network takes place. When an interface is associated with Class I equipment, it is assumed that multiple pieces of equipment may exist and communicate with the

network over the D-channel. However, in this case, all equipment is assumed to be ISDN-capable

and is considered as the endpoint of tlie communication. Therefore, interworking notification

should not be accepted from Class I equipment.

The second attribute relates to tiie manner in which a SETUP message, the message which initiates an ISDN call, should be presented to the user equipment. When Class I equipment is applied on

NIU-Forum Agreements On ISDN 3-1
a particular interface, the network should broadcast the SETUP message associated with each call

that terminates on that interface, since interaction between the network and multiple pieces of user equipment should be supported. On the other hand, the network should not broadcast SETUP

messages associated with terminating calls to an interface on which Class II equipment is being

used. Here, a single piece of user equipment is assumed to be involved in all communication with

the network.

To the extent possible, it is desirable to have one set of requirements for ISDN call control apply

to all ISDN user configurations. However, in cases for which integrated procedures are not

appropriate, the call control procedures associated with Equipment Class I will differ from those

associated with Equipment Class II. Unless otherwise noted, the assumption should be that a

particular procedure/capability should be provided for both classes of equipment on both basic and

primary rate access. However, use of the equipment class terminology permits clarification of the

circumstances under which a certain capability should be available (i.e., when a particular

equipment class is in use). It also permits a mechanism for indicating that a particular capabihty

applies only to a subset of four possible configurations which are labeled as follows.

Table 3-1. Implementation Configurations

Class I Class n

BRI

PRI

IB IIB

IP IIP

BRI: Basic Rate Interface

PRI: Primary Rate Interface

In other words, a capability that applies to Class I equipment may be provided on basic access

interfaces {IB) and/or primary rate access interfaces {IP). Similarly, a capability that applies to

- Class II equipment may be provided on basic access interfaces {IIB) and/or primary rate access

interfaces {IIP).

The notation shown in the table above is used within this implementation agreement to indicate

when protocol or procedures are only expected to be supported for a particular class and/or are limited to a particular type of interface, i.e., basic or primary rate interface.

NIU-Forum Agreements on ISDN
4 Implementation Agreements

The Implementation Agreements (lAs) generated by the NIU-Forum IIW provide the agreements

for implementing the American National Standard (ANS) specifications for an ISDN. These lAs were developed and approved by both industry and user representatives participating in the Expert

Working Groups, as well as the NIU-Forum Plenary. The lAs exist to expedite the development

of ISDN capabilities, to promote interoperability of ISDN communications equipments, and to provide a universal, multi-vendor implementation. The following text details the lAs.''

4.1 ISDN Lower Layer Specifications

The ISDN lower layer specifications define the layer 1, 2, and 3 requirements of an ISDN.

Network signalling, via the D-channel, is the focus of these agreements but, where appropriate, user data specifications of layers 1, 2, and 3 have been included. These I As were developed in

the Signalling Expert Working Group (SWG) of the IIW. These IAs provide a framework and a

set of protocol procedures for accessing an ISDN, so that systems implemented according to these

agreements can successfully interoperate. The following text details the ISDN lower layer lAs.

4.1.1 Layer 1 Basic Rate Interface (BRI)

The ISDN Basic Rate Interface (BRI) physical layer specifications are defined for their specific

reference point of application. These reference points are S, T and U, providing the user and

network interfaces for Terminal Equipment (TE) and Network Termination (NT) equipments. The

following lAs are defined for the BRI physical layer.

4.1.1.1 U Reference Point

The I A Basic Access Interface for Use on Metallic Loops for Application on the Network Side of

the NT — Layer 1 Specification (NIU 89-101) states: "The physical layer of the Basic Access

Interface at the U reference point is specified in ANS Tl.601-1988, Integrated Services Digital

Network — Basic Access Interface for Use on Metallic Loops for Application on the Network Side

of the NT — Layer I Specification, (Ref. [12]).

This lA adopts ANS T1.601-I988 (Ref [12]) without exception."

4.1.1.2 S and T Reference Points

The lA Basic Access Interface at S and T Reference Points —Layer 1 Specification, (NIU 89-105)

states: "The physical layer of the Basic Access Interface at the S and T reference points is specified in ANS Tl.605-1989, Integrated Services Digital Network — Basic Access Interface at

S and T Reference Points — Layer I Specification, (Ref [16]).

This lA adopts ANS Tl.605-1989 (Ref [16]) without exception."

"The NIU-Forum Plenary document numbers (e.g., NIU 89-101) are included for reference purposes

only, as every numbered implementation agreement is included in the present document in its entirety.

NIU-Forum Agreements On ISDN 4-1
4.1.2 Layer 1 Primary Rate Interface (PRI)

The ISDN Primary Rate Interface (PRI) physical layer specifications are defined for the S, T, and

U reference points. These reference points provide the user and network interfaces for TE and NT

equipments. The following lA is defined for the PRI physical layer.

4.1.2.1 S, T, and U Reference Points

The lA Primary Rate Customer Installation Metallic Interfaces, Layer 1 Specification (NIU 89-

103R1) states: "The physical layer of the Primary Access Interface is specified by ANS T1.408-

1990, ISDN Primary Rate — Customer Installation Metallic Interfaces, Layer 1 Specification, (Ref.

[11]).

This lA applies to the Primary Rate S, T, and U reference points.

This lA adopts ANS Tl.408-1990 (Ref [11]) without exception."

NOTE: Previous revisions of this lA were based upon the ANS Tl.403-1989 (Ref [10]), (the DSl

specification) and can be found in NIST Special Publication 500-195, North American ISDN Users

Forum Agreements on ISDN (Ref [51]).

4.1.3 Layer 2 BRI and PRI

The ISDN Basic Rate Interface (BRI) and Primary Rate Interface (PRI) access arrangements

specifies one common lA for the D-channel layer 2 data link.

The lA Data Link Layer Signalling Specification for Application at the User-Network Interface

(NIU 89-210) states: "The data link layer of the D-channel is specified in ANS Tl.602-1989,

ISDN Data Link Layer Signalling Specification for Application at the User-Network Interface, (Ref

[13]).

This lA adopts ANS Tl.602-1989 (Ref [13]) with the following, additional clarifications:

1) Both automatic and non-automatic Terminal Endpoint Identifier (TEI) assignment terminals

shall be allowed to connect to a passive bus. Automatic TEI assignments are preferred, since it would be the responsibility of the user to ensure that different TEIs are used by each different

terminal for non-automatic TEI allocation equipment.

2) It is recommended that the data link monitor function be operated on at least one link

associated with each TEI."

4.1.4 Layer 3 BRI and PRI

The ISDN BRI and PRI access arrangements will utilize the layer 3 Signalling protocol as defined

by ANS Tl.607-1990, ANS Tl.608-1990 and ANS Tl.610-1990 (Refs. [17, 18, 20]). These

specifications apply to two distinct connection types: circuit-switched and packet-switched. The

following text details the lAs for ISDN layer 3 signalling.

4-2 NIU-Forum Agreements on ISDN
4.1.4.1 Circuit-Switched Call Control Procedures

The circuit-switched layer 3 signalling protocol shall be responsible for the establishment,

maintenance and tear-down of basic signalling connections and supplementary service signalling

connections which utilize circuit-switched access. The following text details the circuit-switched

call control procedures.

4.1.4.1.1 Basic Call Control Procedures

The lAs (NIU 300 Series) for the ISDN Basic Call Control procedures state: the circuit-switched

network layer protocol is specified in the ANS Tl.607- 1990, Digital Subscriber Signalling System

No. 1 (DSSl) — ISDN Layer 3 Signalling Specification for Circuit-Switched Bearer Service, (Ref.

[17]).

The lAs have adopted ANS Tl .607-1990 (Ref. [17]), according to the implementation

configuradons, as follows:

• Class I BRI {IB)

The Class I BRI {IB) basic call control signalling lA Layer 3 Signalling Specification for the

Minimal Set of Circuit-Switched Bearer Services for the ISDN Basic Rate Interface/Class I is included in Appendix A.

• Future Class I PRI {IP)

Editor's Note: This section is reserved for future agreements on Class I PRI {IP) basic call control

signalling.

• Future Class II BRI {IIB)

Editor's Note: This section is reserved for future agreements on Class II BRI {IIB) basic call control signalling.

• Class 11 PRI {IIP)

The Class II PRI {UP) basic call control signalling lA Layer 3 Signalling Specification for the

Minimal Set of Circuit-Switched Bearer Services for the ISDN Primary Rate Interface/Class II is included in Appendix B.

4.1.4.1.2 Supplementary Services Control Procedures

The lAs (NIU 310 Series) for the ISDN Supplementary Services Control procedures are based

upon ANS Tl .610-1990, Digital Subscriber Signalling System No. I (DSSI ) — Generic Procedures

for the Control of ISDN Supplementary Services, (Ref. [20]). The following text details the lAs.

• Class I BRI {IB)

The lA (NIU 89-311 ) for the Class I BRI {IB) Supplementary Services Control procedures states: The generic procedures for the control of ISDN Supplementary Services for Class I equipment on

a Basic Rate Interface (BRI) is specified in ANS Tl .610-1990 (Ref. [20]).

NIU-Forum Agreements On ISDN 4-3
The following changes shall apply to the ANS Tl.610-1990 (Ref. [20]) specification:

1. In section 4, the Keypad protocol only applies during the establishment phase of a call;

2. In section 5.2.2.1, the option of using the dummy call reference for sending a call- associated feature request is removed.

3. In section 2.1.3, section 6, and Appendix I, the Common Information Element Category

of the Functional Protocol is removed;

4. In section 7, the FACILITY and REGISTER messages are removed;

5. In section 8, the Facility information element is removed;

6. In Annex A, the Terminal Identification procedures for assignment of USID and TED at subscription time are removed;

7. In Annex B, section 2.1, the words "in the Called party number information element in one or more INFORMATION messages" should be changed to "in the Called party

number information element in one INFORMATION message";

8. Remove Appendix III General Description of Component Encoding Rules.

9. The scope of this implementation agreements is applicable only to the ISDN Basic Access

Rate as applied to Class I equipment.

• Future Class I PRI (IP)

Editor's Note: This section is reserved for future agreements on Class I PRI (IP) Supplementary

Services Control procedures.

• Future Class II BRI (7/5)

Editor's Note: This section is reserved for future agreements on Class II BRI (7/5) Supplementary

Services Control procedures.

• Future Class II PRI (77P)

Editor's Note: This section is reserved for future agreements on Class II PRI (IIP) Supplementary

Services Control procedures.

4.1.4.2 Packet-Switched Call Control Procedures

The Lower Layer Special Interest Group (LLSIG), of the OIW, has the responsibility of developing

the lAs for packet-switched Connections. Their work overlaps with the packet-switched services

provided by an ISDN. Therefore, the SWG has the responsibility to review the LLSIG' s lAs and

provide to the LLSIG any additional information/clarification necessary to ahgn these lAs with

those defining the ISDN.

The packet-switched layer 3 signalling protocol shall be responsible for the establishment,

maintenance and tear-down of basic signalling connections and supplementary service signalling

connections which utilize packet-switched access. The following text details the packet-switched

call control procedures.

NIU-Forum Agreements on ISDN
The lA (NIU 89-320) for the ISDN Basic Call Control procedures states: the packet-switched

network layer protocol is specified in the CCITT Recommendation Q.93 1-1988 (also designated

CCITT Reconunendation 1.451-1988), ISDN User-Network Interface Layer 3 Specification,^ (Ref.

[26]).

The following agreements have been reached concerning the use of CCITT Recommendation

Q.931-1988, (Ref. [26]):

1. On a BRI supporting the ISDN virtual circuit service, all of CCITT Recormnendation Q.931-

1988 (Ref. [26]) section 6, except for 6.1.1 and 6.2.1 (the sections covering the circuit-switched access case), shall apply. The following sections also apply; 3.2 (messages for packet-mode access connection control), 4-4.5 (section specifying general information element handling and encoding),

4.7 (information elements for packet communications).

2. On a PRI supporting the ISDN virtual circuit service all of Q.931-1988 (Ref. [26]) section 6,

except for 6.1.1 and 6.2.1 (the sections covering the circuit-switched access case), 6.1.2.2, 6.2.2.2

and 6.4.2 (the sections specifying the D-channel ISDN virtual circuit service case), shall apply.

The following sections also apply: 2.2 (packet-mode access connection states), 3.2 (messages for

packet-mode access connection control), 4-4.5 (section specifying general information element

handling and encoding), 4.7 (information elements for packet communications).

3. On a BRI or PRI supporting the Unrestricted 64 kbit/s circuit-mode service, CCITT

Recommendation Q.931-1988 (Ref. [26]) sections 6.1.1, 6.2.1, 6.4.1 and 6.4.3 shall apply. The

following sections also apply: 2.1 (circuit-mode connection states), 3.1 (messages for circuit-mode

connection control), 4-4.5 (section specifying general information element handling and encoding).

4.2 Future Basic Bearer Services Specification

The ISDN basic bearer services specifications define the minimal set of bearer services provided

by an ISDN. The specifications outline the set of essential bearer services, and their attributes, to be provided by an ISDN. The lAs developed for the bearer services will provide a specification

outlining the required bearer services and their respective characteristics. The following text will

detail the ISDN basic bearer services lAs.

4.2.1 Future Minimal Set of BRI Services

Editor's Note: This section is reserved for future agreements on the minimal set of ISDN Basic

Rate Interface (BRI) bearer services (Refs. [15], [30, 31]).

4.2.2 Future Minimal Set of PRI Services

Editor's Note: This section is reserved for future agreements on the minimal set of ISDN Primary

Rate Interface (PRI) bearer services (Refs. [14], [30, 31]).

'This lA will be aligned with ANS Tl.608-1990, Digital Subscriber Signalling System No. I (DSSI) — Signalling Specification for X.25 Packet Switched Bearer Service (Ref. [18]) when ANS Tl.608-1990

is stable. Please refer to section 4.1.4.2 of the North American ISDN Users' Forum (NIU-Forum) Working

Agreements for the Integrated Services Digital Network (ISDN) — Publication I (Ref. [32]) for more

information on this alignment.

NIU-Forum Agreements On ISDN 4-5
4.3 Future Supplementary Services Specification

Editor's Note: This section is reserved for future agreements on the ISDN supplementary services

specifications (Ref. [20]).

4.4 ISDN Terminal Adaptation Specification

The ISDN Terminal Adaptation specifications define the requirements for attaching a non-ISDN

terminal to an ISDN. This attachment is performed across the R reference point, with the

specification of the R reference point providing the necessary characteristics, attributes and

functions such that successful interoperabiUty between the non-ISDN and the ISDN is achieved.

The lAs developed for terminal adaptation provide a specification of the R reference point

requirements. The following text details the ISDN terminal adaptation lAs.

4.4.1 Future Circuit-Mode Data Terminal Adaptation

Editor's Note: This section is reserved for future agreements on circuit-mode data terminal

adaptation which will define the R reference point requirements when circuit-switched connections

are provided by an ISDN.

4.4.2 Packet-Mode Data Terminal Adaptation

The packet-mode data terminal adaptation lAs define the aspects of the packet-mode services to be used by the packet-mode Data Terminating Equipment (DTE), the access requirements, and the

functions of the Terminal Adapter provided across the R reference point. These lAs were

developed in the LLSIG of the OSI Implementors' Workshop. Refer to the NIST OSI

Implementors' Workshop Stable Implementation Agreementsfor OSI Protocols (Ref. [52]), section

7.

4.5 ISDN Management Specification

The ISDN Management specifications provide the operations and maintenance requirements for the

various access interfaces and protocol levels of the ISDN. The lAs are to be developed in the

Network Management Expert Working Group (NMWG) of the IIW. The following text details the

ISDN Management lAs.

4.5.1 Future Layer 1 BRI

Editor's Note: This section is reserved for future agreements on layer 1 ISDN management

specification, for a Basic Rate Interface (BRI) (Ref. [7]).

4.5.2 Future Layer 1 PRI

Editor's Note: This section is reserved for future agreements on layer 1 ISDN management

specification, for a Primary Rate Interface (PRI) (Ref. [8]).

4.5.3 Future Layer 2 and 3, BRI and PRI

Editor's Note: This section is reserved for future agreements on layer 2 and 3 ISDN management

specification, for a Basic Rate Interface (BRI) and a Primary Rate Interface (PRI) (Ref. [9]).

NIU-Forum Agreements on ISDN
4.6 Future Common Channel Signalling — Signalling System #7

Editor's Note: Tliis section is reserved for future agreements on common channel signalling

system, ANSI Signalling System #7 (Refs. [1, 2, 3, 4, 5, 6, 19].

NIU-Forum Agreements On ISDN 4-7

5 ISDN Conformance Test Speciflcations

The NIU-Forum's Confonnance Test (CT) specifications provide test suites to be used to verify

the confonnance of ISDN equipments to the designated specification. They are written in abstract

form so that multiple test equipment vendors may provide implementations of the test suite. The

ISDN Conformance test specifications are developed in the ISDN Conformance Test (ICOT)

Working Group, and its subordinate Expert Working Groups: the Abstract Conformance Test

Group for layer 1 (ACTl) and the Abstract Conformance Test Group for layers 2 and 3 (ACT23).

The following text details the Conformance Tests for ISDN equipments.

5.1 Layer 1 BRI

The Basic Rate Interface (BRI) Layer 1 Conformance Test specifications provide the requirements

for verifying equipment conformance at layer 1 of the ISDN BRI user-network interface. The

following text details the Conformance Tests for layer 1 operation of a BRI.

• Future "U" Interface

Editor's Note: This section is reserved for future agreements on the layer 1 BRI conformance test abstract test suites, and conformance criteria to the ANS Tl.601-1988 (Ref [12]).

• The "S/T" Interface

The CT defining the conformance criteria and abstract test suites to verify equipment

implementation conformance to the BRI S and T interface as specified in ANS Tl.605-1989 (Ref

[16]) is defined by the NIU-Forum specification, NIU 90-002 (NIU-F/IIW/ICOT-90-040) Integrated

Services Digital Network (ISDN) Conformance Testing, Layer I Basic Rate S/T Interface, User

Side, (Ref [33]).

5.2 Future Layer 1 PRI

Editor's Note: This section is reserved for future agreements on the layer 1 PRI conformance test abstract test suites, and conformance criteria to the ANS Tl.408-1990 (Ref [11]).

5.3 Layer 2 BRI

The layer 2 Conformance Test specifications, for the BRI and PRI access arrangements, provide

the requirements for verifying equipment conformance at layer 2 of the ISDN BRI/PRI. The ISDN

test suite development process is aligned with International Standards Organisation (ISO) 9646

(Ref [54]), OSI Conformance Testing Methodology and Framework, Parts 1-3. The following text

details the Conformance Tests for layer 2 operation of an ISDN.

The CT defining the abstract test suites to verify equipment implementation conformance to the

layer 2 of an ISDN at the user-network interface is defined by the NIU-Forum specification, NIU

91-007^ (NIU-Forum/IIW/ICOT/ACT-9 1/22.2 VI.2) Integrated Services Digital Network (ISDN)

Conformance Testing, Layer 2 Basic Rate Interface, Link Access Procedure, D-channel (LAPD),

User Side, (Ref [34]). This conformance test suite is for the Link Access Procedure, D-channel

^In order to accuiately represent the Layer 2 Confonnance tests, the reference was changed from NIU

89-001 (NIU-Fonim/IIW/IC(JT/89-065.2) to the final, and NIU-Forum approved document NIU 91-007

(NIU-Forum/IIW/ICOT/ACT23-9 1 -22.2 V 1 .2).

NIU-Forum Agreements On ISDN 5-1
(LAPD) data link protocol and is described in Tree and Tabular Combined Notation (TTCN). Its use is for ISDN terminal equipments attaching to the user side of a Basic Access interface.

The CT defines the conformance criteria to the ANS Tl.602-1989 (Ref. [13]) and to the CCITT

Recommendation Q.921-1988 (Ref. [25]) (Note: These specifications are the same text). The

purpose of the Abstract Test Suite is to provide the most complete protocol conformance test coverage as is possible, not to be completely exhaustive. The LAPD Test Suite has many

additional test cases for TEI Management procedures and system related cases which are covered

in the body of the CCITT Reconunendation Q.921-1988 text (Ref. [25]) but not in the CCITT

Recommendation Q.921-1988 state transition tables.

5.4 Future Layer 2 PRI

Editor's Note: This section is reserved for future agreements on the layer 1 PRI conformance test

abstract test suites, and conformance criteria to the ANS Tl.602-1989 (Ref. [13]).

5.5 Future Layer 3

Editor's Note: This section is reserved for future agreements on the layer 3 Conformance Test

specifications, for BRl and PRI access arrangements.

NIU-Forum Agreements on ISDN
6 Application Software Interface (ASI)

This section includes the introductory material for the specification for an Application Software

Interface (ASI) defined by the NIUF. The complete ASI documents are published separately.

6.1 Introduction To The ASI

6.1.1 Overview

Part 1 of the ASI provides an initial specification intended to allow implementors to begin using

the ASI for implementations of applications requiring a limited subset of ISDN services within a

limited set of operating systems. The specification includes the following components:

• introduction to the ASI concepts,

• description of the ASI architecture,

• description of the ASI access functionality,

• ASI command messages to support a basic subset of ISDN services,

• and ASI data structures.

Future parts of the ASI specification will expand the above list to include:

• ASI access method for DOS, UNIX/POSIX, OS/2, Windows, etc.,

• additional ASI command messages to support additional ISDN services,

• formal specification of the ASI,

• expansion to include the full teleservices architecture,

• and conformance tests.

6.1.2 Charter

The Application Software Interface focuses on the definition of a common application interface for

accessing and administering ISDN services provided by hardware commonly referred to in the

vendor community as Network Adapters (NAs) and responds to the applications requirements

generated by the ISDN Users' Workshop (lUW).

The characteristics of this Application Interface shall be:

• portable across the broadest range of system architectures,

• extensible,

• abstracted beyond ISDN to facilitate interworking.

NIU-Forum Agreements On ISDN 6-1
• and defined in terms of services and facilities consistent with OSI layer interface

standards.

6.1.3 Goals

The primary goal of the ASI is to provide a consistent set of application software interface services

and application software interface implementation agreement(s) in order that an ISDN application

may operate across a broad range of ISDN vendor products and platforms.

The application software interface implementation agreements will be referenced by (and tested

against) the lUW generated applications. It is anticipated that the vendor companies involved in

the development of these implementation agreements will build products for the ISDN user marketplace which conform to them.

ASI Implementation Agreements are likely to become a U.S. Government Federal Information

Processing Standard (HPS).

ASI specifications are expected to serve as a contribution for further North American or

International standards activities.

6.1.4 Purpose

Today there exists an ever increasing number of ISDN Network Adapters (NAs) from different

manufacturers, each with the same basic subset of features, plus additional features the

manufacturers hope will differentiate them from the competition. This environment is illustrated

in figure 6-1.

Figure 6-1. Typical Proprietary Interface Enviroiunent.

6-2 NIU-Forum Agreements on ISDN
Currently, each NA vendor presents a different software interface to the ISDN application. This

produces constant frustration to the ISDN applications developer. Each interface represents the

efforts on the part of the vendor to provide access to all ISDN services provided by the NA; yet

each, done in isolation, differs from the others. In developing an ISDN application, therefore, the

developer is faced with the task of (a) binding with an initial NA (hopefully a popular one), and

(b) once his application is fielded, working to enhance his application product to interface with

other NAs as well. Exemplifying this process are products in the market today which advertise

"currently works with Network Adapters A, B, and C; will support Network Adapters D and E in the near future."

6.1.5 Scope

Figure 6-2 conceptualizes a solution to the application interface incompatibility problem.

Figure 6-2. ASI Environment.

The ASI is a software interface between an application and a NA within an operating environment

(the operating environment includes the operating system, hardware platform, bus, etc.). Elements on the network side of the interface are referred to as the "ASI Entity (AE)." Elements on the

application side are referred to as the "Program Entity (PE)."

The ASI does not guarantee interoperability between the end to end applications that may use the

ASI.

The ASI places emphasis on a common application interface as opposed to a common hardware

device interface for two main reasons:

NIU-Forum Agreements On ISDN 6-3
1. The most important user benefit is derived from a large selection of commercially

available ISDN applications which can operate over a correspondingly large selection of

NAs. The number of applications will be most influenced by the existence of a common

application interface that allows the application provider to easily migrate applications to different NAs or operating system environments.

2. It is much more difficult to specify a standard hardware device interface. Vendors

want to provide different NA hardware interfaces to appeal to different markets. For

example, some NAs will be built for performance while others will be built for low cost. The market that a vendor desires to sell into, will determine the hardware device interface

(i.e., memory mapped, polled I/O, interrupt driven, direct memory access (DMA) driven,

shared memory, etc.). Vendors are accustomed to providing drivers or libraries which

interface to their specific hardware implementation.

The conversion from the common ASI to the NA hardware device interface becomes the job of

the adapter developer. The conversion function can, for instance, reside in a device driver which

is provided by the adapter manufacturer. The application developer should have to do as little as possible to port an application written for one operating system to a different operating system

(e.g., to re-compile or re-link is perceived as minimal effort). Also, within one operating system,

the application developer should be able to design applications independently of the NA (e.g., the

application should work the same and without modification on the variety of NAs available),

assuming the NA provides equivalent services.

The conceptual objective of the ASI is to be as independent as possible of:

• Hardware Platform,

• Operating System,

• Data Protocol Type,

• Programming Language,

• and Compiler.

Although the ASI takes the approach of developing a common set of services which are applied

across a broad range of environments, the access methods are environment dependent. This is true because of hardware restrictions within different operating environments, performance issues, and

fundamental operating system differences.

As applicable ISDN standards evolve it is expected that the ASI will evolve to accommodate those

applicable standards.

6.1.6 Assumptions

Several assumptions have gone into the development of the current ASI specification. These

assumptions are described as follows:

• ISDN primary rate and basic rate access are assumed to be the network interface to the

NA. This does not preclude application of this interface to NAs which interface to other

ISDN access methods.

NIU-Forum Agreements on ISDN
• The ASI provides a uniform software interface defined between the NA and the

application. Throughout the ASI specification, the term "ASI entity" is used to refer to the ISDN service provider, and any associated hardware, network adapter card, or terminal

equipment, while the term "Program Entity" is used to refer to the application which uses

the ISDN service.

• This specification does not address peer-to-peer protocol or interoperability issues.

• The ASI interface is assumed to be at the OSI layer three to layer four boundary.

• ANSI Standards, NIUF Agreements, and CCITT Reconmiendations are the basis for

this ASI specification.

• No default values for parameters are assumed by the interface. All parameter values

necessary for a message must be suppUed in the applicable data structures.

6.2 Technical Overview

This section presents an overview of the ASI architecture and the motivation underlying the chosen

approach.

The goal of the ASI is to provide a portable, extensive, and layered software interface to ISDN

hardware, call control, and services. Portability allows applications to be developed independent

of any particular vendor's ISDN offering, and hence ties the success of the application to the

penetration of ISDN rather than the future of a single vendor. Portability favors the application

developer by making the application available for a wider audience. But widespread application

availability will make it easier to use ISDN services, hastening deployment of ISDN Hues, and thus

ultimately benefitting the hardware (or ISDN capable computer platform) vendors as well.

ASI applications run on a computer platform employing ISDN interface hardware from different

vendors without recompilation or linking. The same application is portable to a different computer

platform (with the same operating system) by recompiling without changes to the source code.

There may be some code changes required for a different operating system to accomodate

differences in the access method.

A problem with designing application software interfaces to ISDN teleservices is the range of level

of functionality such an interface could support. A high level interface would provide generic

telephony interface functions, while a lower level would more closely match ISDN-specific

message and event types. The ASI favors a layered approach, based on experience with the OSI

model and numerous examples in distributed computing.

As such, the ASI incorporates a model with several reference points. A multi-tasking operating

system will enable multiple processes to gain access to ISDN services through a server architecture

which will provide a high level functional interface and event filtering to minimize ISDN-specific

knowledge required of the application. This server, or the single application for a server-less or

single threaded operating system, in turn communicates with ISDN call conttol over a lower level

interface which more closely mirrors the ISDN protocol. The various reference points will be

illustrated later in this section.

The current release of the ASI specification defines the core subset of the lower level reference

point. It is to this reference point which vendors must supply ASI support, and, once written, early

NIU-Forum Agreements On ISDN 6-5
applications can be developed immediately. No vendor-specific software need operate above this reference point, although a vendor may choose to provide higher level support for added value to an ISDN product.

The ASI defines a reference point and a message protocol across that reference point. ISDN call control and hardware specific interfaces will operate below the ASI and be provided by specific

vendors. Vendors may also supply an application library, in some specific programming language,

to compose messages in the ASI format.

The ASI specifies a complete interface composed of an operating system dependent access method,

an operating system independent message set, and an operating system independent message

encoding method. An operating system dependent access method allows the rest of the ASI to

exist independent of the OS.

Because the message set and encoding method are identical between the various implementations

of the ASI for different operating systems, application portability is greatly simplified.

The ASI message set and operating system specific access methods provide an asynchronous

interface to ISDN call control. The application makes requests through the ASI, and the ISDN call control beneath the ASI transmits confirmation messages and event indication messages back

through the ASI as appropriate. Any blocking or synchronous interface to the ASI should be

provided as a Ubrary of function calls on the application side of the ASI.

For example, an application places a call by sending an Nb-CONNECT request. After issuing the

request, the application can continue execution. Call control may generate various Nb-EVENT

indication messages as the call proceeds through the network. When the call completes to the

called party, an Nb-CONNECT confumation message will be sent up through the ASI. To

implement a blocking call request, the application would send the Nb-CONNECT request, and

await the Nb-CONNECT confiimation.

6.2.1 Application Software Interface Definition

' The Apphcation Software Interface (ASI) is a common interface for accessing ISDN services

provided by ISDN network adapters (NAs). The ASI is a way for an application and an ASI entity

to communicate within an operating environment (the operating environment includes the operating

system, hardware platform, bus, etc.). The translation of the ASI message set to and from the

instructions needed to operate any hardware interfaces is accomplished by AE vendor supplied

software. The conversion function, can, for instance, reside in a device driver provided with the

AE.

The application developer should be able to design applications independent of the NA with which

it might be used. Within a given operating environment (e.g., a PC running DOS), applications

should be able to run on any ASI-compliant AE. Finally, the application developer should have

to do as little as possible (e.g., recompile/relink) in order to move from one operating system to another. Tlie ASI allows any ISDN application written against the ASI specification to communicate with any ASI-compliant ISDN network service provider.

NIU-Forum Agreements on ISDN
6.2.2 OSI Reference Model Positioning

The ASI is positioned at the Service Access Point (SAP) between layers 3 and 4 in the OSI

Reference Model. Conceptually, the ASI is an asynchronous message stream between the ISDN

network services provider (layers 1-3) and the user (layers 4+) of those services.

If, for example, a non-empty transport layer protocol is positioned above the ASI, then that

transport protocol, and not the higher layer application, is the actual user of the ISDN bearer

services provided through the ASI. Likewise, the term "ASI entity" is meant to apply to any

provider of ISDN network services that meets certain qualifying assumptions. The ASI is a local

interface between layer 4 and layer 3 only; it is not, itself, a layer within the OSI Reference Model,

nor is it an end-to-end protocol. Such features as interoperability or end-to-end integrity must be

provided by protocols above the ASI, using ISDN network services accessed through the ASI.

6.2.3 Teleservices Architecture

The environment in which the ASI is expected to operate assumes an architecture including a

generic teleservices server. Such a server may offer teleservices to applications on the local

machine or on the local area network without requiring the applications to implement the details

of ISDN, plain old telephone service (POTS)/public switched telephone network (PSTN), or other

possible teleservices media.

It would be the responsibility of a server interface definition to allow for multiple client

applications to access the services provided by a single interface adapter.

The teleservices architecture has been spUt into several layers. Issue 1 ASI is identified as the

message stream at reference point "B" in this architecture.

The definition of the Reference Points is as follows, and is depicted in figure 6-3:

• In ASI Draft 1, the "A" reference point is not an exposed interface. It is defined to be

the interface between the "standard" portions of Q.931 and the non-standard portions.

Only the non-standard portions of ISDN need to be customized for each market.

• The "B" reference point is the interface between the ISDN signaling, management and

user planes, and a server or dedicated application. Direct multi-client access is not

allowed.

• The "C" reference point presents a generic teleservices interface to the server or dedicated application.

• The "D" reference point allows a server to provide a generic teleservices interface to multiple client applications. This interface also presents a simplified programming model

to the application or toolkit developer.

• The "E" reference point is the programming interface provided by a high level library.

This interface is the one most desired by typical applications developers.

NIU-Forum Agreements On ISDN 6-7
Teleservices Architecture for Call Control

Applicatioq | App. 1 1 App.

Toolkit

i

Toolkit

Teleservices Server

Events

Resource Manager ;:; Database

Policy Mechanism

ISDN to Generic POTS to Generic Teleservices

MMMNMhMMMHMMMMMHnMMHMMMMnMMnMMMMMMMi^^ Q.931 Call Control

Q.93 1 Protocol Layer

Q.921 Hardware

In ASI Draft 1,

this implementadon

is supplied by

the hardware

vendor.

Figure 6-3. Teleservices Architecture for Call Control.

6.2.4 ASI Sessions

The Application Entity (AE) and Program Entity (PE) communicate across the ASI by reference

to sessions. A session is a local virtual path between the PE and the AE which carries all requests

and responses for a given instance of a service, e.g., a voice call. Once established, a session is

referred to by a session ID.

Sessions are created dynamically by either the AE or the PE according to the rules defined by the

ASI protocol. To allow for dynamic creation of sessions by either side, each side may create session IDs without consulting the other side. The AE's session ID is referred to as the AEI, while

the PE's session ID is referred to as the PEL Either side may refer to a session using the other's

ID. An ID of all zeros indicates that the other side's ID is unknown or is not used.

Retiring and reuse of old IDs is carefully managed by the protocol.

6-8 NIU-Forum Agreements on ISDN
6.2.5 ASI Components

The ASI, or any other interface in the architecture, must contain definitions for the following:

• access methods for each operating environment (DOS, Unix, etc.), for passing messages,

• a set of message types and associated parameters,

• precisely defined encodings for the above messages,

• and a formal description of the protocol semantics.

6.2.5.1 Access Methods

An access method, as defined by this document, is an operating system dependant set of procedures

for passing messages between layers of software. The messages may contain control, management,

or user plane information.

This architecture requires that any access method provides asynchronous message passing between

software layers.

Access methods are described in the Application Software Interface Part 1: Overview and

Protocols (Ref. [53]), section 4.

6.2.5.2 Messages

In order to meet the portability and network transparency requirements of the architecture, all messages are required to be self contained. Messages containing pointers, or other references, to external data structures are not legal.

Messages and their semantics are described in Application Software Interface Part I: Overview

and Protocols (Ref. [53]), section 5. Message parameters are described in Application Software

Interface Part 1: Overview and Protocols (Ref. [53]), section 6.

6.2.5.3 Encoding

Message definition will be described using ASN.l.

Actual message encoding will be done using an ASI specific method. The method is chosen to promote ease of implementation and improve performance while providing for future expansion

of the protocol.

NIU-Forum Agreements On ISDN 6-9
ii
7 Application Profiles

Since the inception of the NIU-Forum, the goal has been to provide an ISDN that users want and

need, and to do so in a way that promotes application interoperability in a multi-vendor

environment. Application profiles are the final step in the functional standardization process to achieve this goal.

7.1 NIU-Forum Application Profiles

An application profile provides an overall specification of the ISDN elements and the application

elements necessary to provide a specific, interoperable application for an ISDN. A profile supports a particular application, or a set of applications, specifying the ISDN standards to use, the options

to implement within each standard, the layered protocol configuration and the application's usage

of the ISDN's attributes. Please refer to the North American ISDN Users' Forum (NIU-Forum)

Working Agreements for the Integrated Services Digital Network (ISDN) — Publication 1, (Ref.

[32]), section 7.1.1, for a description of the process for developing Application Profiles.

7.1.1 Application Profile Conformance

It is essential that the Application Profile teams identify criteria that the implementor must meet

in order to claim compliance with the Application Profile. It is intended that a tester agency be

established (e.g., the Corporation for Open Systems) which applies ICOT-derived conformance tests

in order to verify a product's relative sufficiency of interoperability against a testbed which applies

standardized tesUng methodologies (e.g., ISO 9646, Ref. [54]). Real multi-vendor interoperabihty

is achieved in an interoperabihty testing environment which validates the Application Profile's

compliance amongst participatory users and vendors.

7.1.2 Application Profile Families

The NIU-Forum ISDN applications have been categorized into one of six "application families."

The families provide a means of assimilating applications based upon a commonality of usage.

Each family has been assigned its own Application Profile team to develop the Application Profiles

for tlie family. The following Application Profile teams have been identified:

• ISDN Call Management

• ISDN CPE Compatibility/Capability

• ISDN Network Interconnectivity

• Messaging and Answering

• Bandwidth Negotiation

• Network Management/ISDN Administration

The following sections detail the Application Profile lAs.^

^The NIU-Forum Plenary document numbers (e.g., NIU 90-003) are included for reference purposes

only, as every numbered application profile is included in the present document in its entirety.

NIU-Forum Agreements On ISDN 7-1
7.2 ISDN Call Management

7.2.1 Incoming Call Management

The ISDN Call Management Profile team has completed an Application Profile, NIU 90-003, for

incoming call management which covers all of the following apphcations:

Title User Req't Document Number

• Database Information to Corporate Security 810005

• New Account Customer Inquiry Handhng 840023

• Customer Service Call Handling 840024

• Automatic Callback for Financial Services 840025

7.2.1.1 Abstract

This application profile provides the User Descriptions, Alternative Architectures, Information

Flows, and recommended Protocol Stacks for the Incoming Call Management Applications (User

Application Requirements Data Form Numbers: 810005, 840023, 840024, 840025, Refs. [36, 37,

38, 39]). The Incoming Call Management Applications involve customer service agents who

currently receive incoming calls, ask the caller for their member number, and input that data into a terminal connected to a host application. ISDN will be used to automate the transfer of the

Caller's ID to the host. In addition, agents may transfer the call to an additional agent who should

be able to continue the call without having to request the same information from the caller again.

ISDN will be used to effect the call transfer and allow the second agent to bring up the right

application screen without repeating questions. Finally, when all the agents are busy, the caller's number should be captured for later callback. ISDN will be used to capture the caller's number

and allow callback later. ISDN can be used to connect the agent's terminal to the host.

7.2.1.2 User Description

Customer service agents currently receive incoming calls, ask the caller for their member number,

and then input the member number into a terminal connected to a host application to obtain the

customer information. Agents may transfer the customer to another agent to provide a different

service. The second agent has to again ask for the member number and enter a transaction to receive the customer information. The second agent may access a different host application. In addition, when all agents are busy, the caller's number should be captured for later callback.

7.2.1.3 ISDN Application Breakdown

The user's proposed application and the breakdown of the application into service elements can be seen in figure 7-1.

• Call Transfer with Associated Data Service Element

Agent 1 wishes to transfer a voice call from the Customer to agent 2. The voice call is transferred to agent 2. Certain information associated with the terminal session is transferred to the host to which agent 2 is attached, so that the appropriate screen can be

delivered to agent 2.

NIU-Forum Agreements on ISDN
• Call Delivery with Associated Data Service Element

The customer places a voice call in order to speak to an agent. The call arrives at a

Central Office (Co) or Customer Premises switch (PBX). The switch delivers the voice

CALLER

Call Deliveiy

with

Associated

Data

AGENT 1

ISDN or TOTg)

Call Back

on

Busy/

Abandonment

ISDN Network

(PBX/CO AVith ACD)

4. Tenriinal Connectivity

DATA NETWORK

1. Call Transfer

with

Associated Data

ODD

0 0 0 0 0 0 AGENT 2

Figure 7-1. User Proposed Application Service Breakdown.

NIU-Forum Agreements On ISDN 7-3
call to agent 1. Certain information that is delivered to the switch with the voice call (probably the calling party's number) is delivered to a host application, so that the host

application can deliver an appropriate screen to agent 1.

• Call Back on Busy/Abandonment Service Element

This service allows an available agent to place calls to customers who have received busy

or abandoned the call prior to delivery to an agent.

• Terminal Connectivity Service Element

The agents data terminal is connected to the host via an ISDN hnk.

7.2.1.3.1 Service Logic

Figure 7-2 shows the sequence of services put together to provide Incoming Call Management

Applications. The Terminal Connectivity Service Element may be optional and a Call coming in without the associated data (Calling Line Identification (CLID) may be available for Call Transfer

with associated data.

7.2.1.4 Call Transfer with Associated Data Service Element

In this service a call is ah-eady active between agent 1 and the caller. Agent 1 could then perform

any of the following:

1. Blind Transfer — Transfer the call to a second agent and disconnect before the

second agent answers.

2. Transfer with Consulting — Transfer the call to a second agent, discuss the call with

the second agent, then complete the transfer.

3. Consult — Agent 1 calls the second agent to discuss the call and then disconnects

agent 2.

The components are shown in figure 7-3.

The sequence of events for each type is:

Blind Transfer

a. Agent 1 places the caller on hold.

b. Agent 1 places a call to agent 2 and invokes transfer.

c. Agent 1 hangs up.

d. Agent 2 is selected directly or by an intervening CO/PBX (Automatic Call

Distributor (ACD) function).

The topic of how the switch decides to deliver the call to a particular agent has not been described as part of this application, but may have some bearing on implementation.

7-4 NIU-Forum Agreements on ISDN
Terminal

Connectivity

Direct Connect

Terminal

Incoming Call

Incoming Call With

Associated Data

Disconnect

Call Back on Busy/Abandonment-

(Receive Call)

Call Back on Busy/Abandonment

(Place Call)

Disconnect

Transfer

Call Transfer

with

Associated Data

END

Figure 7-2. Incoming Call Management Application Logic Flow.

NIU-Forum Agreements On ISDN 7-5
Figure 7-3.

Agent 2

D B B

a B B

a Q a B B B

Caller

Screen

ISDN Network

Voice.Gaii

Other Data"

(e.g,...eLID, Key)

HOST

May

be

the

Same

Call Transfer with Data Service Element Description.

a D 0 BOO

ODD

Caller

Screen

HOST

Agent 1

7-6 NIU-Forum Agreements on ISDN
e. Agent 2 receives the voice call, while concurrently a host^ application brings up

an appropriate screen based on some information delivered with the call to agent

2.

Transfer with Consulting

a. Agent 1 places the caller on hold.

b. Agent 1 places a call to agent 2.

c. Agent 2 is selected directly or by an intervening CO/PBX (ACD function).

d. Agent 2 receives the voice call, while concurrently a host application brings up

an appropriate screen based on some information delivered with the call to agent

2.

e. Agent 1 talks with agent 2.

f. Agent 1 transfers the caller to agent 2 and disconnects.

Consulting

a. Agent 1 places the caller on hold.

b. Agent 1 places a call to agent 2.

c. Agent 2 is selected directly or by an intervening CO/PBX (ACD function).

d. Agent 2 receives the voice call, while concurrently a host application brings up

an appropriate screen based on some information delivered with the call to agent

2.

e. Agent 1 talks with agent 2.

f. Agent 2 disconnects.

The information being passed along with the call will be called the Key. The Key may be any of

the following:

• a database key used by the agent's application,

• the Calling Party Number,

• an Application or Screen ID,

• some other information used by the users application,

• or a combination of the above.

^The host that the application is running on may be the same for both agents or different.

NIU-Forum Agreements On ISDN 7-7
7.2.1.4.1 User Environment

Some of the users' descriptions of the service have specified a hardware and software environment

in which the service should work. At a minimum, the service should work in the following

environment:

IBM 3270^ type terminals

An IBM-compatible host

• SNA (Systems Network Architecture) host networks.

These are minimum requirements and the actual description of the service is more general in that

it will work with other terminals, hosts, and networks.

7.2.1.4.2 Alternative Architectures

Two architectures for this application have been proposed and adopted (March 1989 and June 1989

NIU-Forum). The first architecture calls for the Call information to be delivered to the agent's

station or terminal adapter (TA)'° and then have that device transmit it to the host application (see

fig. 7-4). If the agent's station is sufficiently intelligent (e.g., a personal computer), the station

could run the application locally.

The second architecture calls for the Host to provide the central office or customer premises switch

with the Key, and that Key is passed to agent 2's Host (see fig. 7-5). The call is delivered to the

agent's station normally. The data terminal could be attached to the host directly or be attached

using the ISDN Terminal Connectivity Service Element described in section 7.2.1.7.

7.2.1.4.3 Information Flow

The information flow diagrams show that data that must be sent between nodes necessary to provide the service described. Signalling messages that are normally present (i.e., confirmation

messages, error messages, disconnect) are not shown for simplicity if they are not necessary to explain the working of the service.

The information flow for Architecture 1 — Smart Terminal/TA can be seen in figure 7-6.

Agent I places a call (Call Setup) which is deUvered to agent 2's station with the Key (carried as User to User information). Agent 2's station could generate an appropriate screen using the Key

^Trademark of IBM Corporation

'"This requires intelligence not normally associated with a TA to satisfy the requirement that any 3270-

like device were to be able to use this service. A separate functional entity, and Intelligence Unit (lU), will

be described as providing the service of relaying Call information to the host. In effect this unit would

upgrade the 3270 to an intelligent terminal with an attached voice terminal. The TA-intelligence unit will

have to be able to have a separate session to the host running, so the data can be passed. Alternately, but more complex, the Intelligence Unit would have to be able to understand the screens being passed between

the host and the terminal and insert information in the data stream.

7-8 NIU-Forum Agreements on ISDN
Figure 7-4. Call Transfer with Data Service Element Architecture 1 — Smart Terminal/TA.

NIU-Forum Agreements On ISDN 7-9
Agent 1 Agent 2

PBX/CO

Call Setup

(Key)

PBX/CO

Call Setup

(Key)

Figure 7-6. Call Transfer with Data Service Element Smart Terminal/TA — Information Flow

Diagram.

7-10 NIU-Forum Agreements on ISDN
or the station could then transfer the Key to the host. The host application would then select and

transmit the appropriate screen to agent 2's terminal.

The information flow for Architecture 2 — Switch Host interface can be seen in figure 7-7.

The call would be initiated by agent 1 selecting to transfer via the terminal. The terminal would

transfer this information to the host ("Init Call"). The host would then transmit this to the PBX/CO

along with the Key as User to User information ("Init Call (Key)"). The PBX/CO the second agent

is attached to would transmit the call setup information to agent 2's station. Simultaneously the

PBX/CO would send the call setup information (including the user to user information containing

the Key) to the host computer. The host selects and transmits the appropriate screen to agent 2's

terminal.

In both flows, if consulting is desired instead of completing the transfer, agent 2 would disconnect.

7.2.1.4.4 Network Signalling Requirements — Protocol Identification

The network signalling requirements for providing this service with each architecture are shown

in figures 7-8 and 7-9. Not shown is how the call was originally received, since it may have come

in via ISDN or POTS. The requirement for this capability is that the end-points involved in the

call transfer must be connected via end-to-end ISDN signalling so that user-to-user information can be exchanged.

In figures 7-8 and 7-9, any connection between two devices without a specific protocol marked

may use any applicable protocol including a proprietary one.

7.2.1.4.5 Protocol Description

The messages and protocol elements desaibed below are only those required by the service being

described. Other messages and protocol elements are not discussed if they are not used by the

application being described, even through they may be required for other reasons, such as routing

of the call.

7.2.1.4.5.1 Call Setup User Information

The Key can be carried from the origination to destination terminal in the SETUP message

described in NIU 90-301 (see Appendix A) and NIU 90-302 (see Appendix B). The SETUP

Message described as sent to the network and by the network to the called user to initiate call estabhshment.

The information element used to carry the Key would be the User-User information element

described as follows: "The purpose of the User-user information element is to convey information

between ISDN users. This information is not interpreted by the network, but rather is carried

transparently and delivered to the remote user(s). There are no restrictions on the content of the user information."

NIU-Forum Agreements On ISDN 7-11
Agent 1 Agent 2

Host 1 and Host 2 may be the same PBX/CO and PBX/CO' may be the same Figure 7-7. Call Transfer with Data Service Element Switch Host Interface — Information Row

Diagram.

Agent 1 Agent 2

0 B D SOD

ODD

0 0 0

ISDN\ ISDN

HOST

Figure 7-8.

ISDN ISDN

BRI

PBX/CO

(ACD)

PBX/CO

(ACD) HOST

Call Transfer with Data Service Element Smart Terminal/TA

Requirements.

Network Signalling

7-12 NIU-Forum Agreements on ISDN
Agent 1 Agent 2

ISDN

Network

Figure 7-9. Call Transfer with Data Service Element Switch Host Interface

Requirements.

Network Signalling

NIU-Forum Agreements On ISDN 7-13
7.2.1.4.5.2 Call Transfer

Proposed baseline text for the Normal Call Transfer supplementary service exists within TIS 1.2/91-

309, Supplementary Service — Normal Call Transfer Stage 1, 2, and 3, (Ref. [22])." There is no consensus on the protocol description for this service yet.

7.2.1.4.5.3 Host-Switch Messages

The functions that need to be provided to allow this service are the following:

• Send User-User information (Key) and initiate a call.

• Receive User-User information (Key) on an incoming call. Possibly initiate the call transfer operation, this could be done from the voice terminal

directly.

The Host Computer messages are being described in the ANSI Switch-Computer Applications

Interface (SCAI) Draft Proposed Standard, TIS 1/92-629 (Ref. [23]).

7.2.1.5 Call Delivery with Associated Data Service Element

In this service an agent is available to receive an incoming call. When a customer's call is presented to the agent an appropriate screen is displayed on the agent's data terminal that relates

to the caller or the application being provided by the agent (see fig. 7-10).

The sequence of events is as follows:

a. Caller places a call to the phone number of the "Call Delivery service user" (800

number in some user's application).

b. An agent is selected by the CO/PBX (ACD function).

c. The agent receives the voice call, while concurrently a host application brings up an

appropriate screen (based upon the calling party's number).

7.2.1.5.1 User Environment

Some of the users' descriptions of the service have specified a hardware and software environment

in which the service should work. At a minimum, the service should work in the following

environment:

• IBM 3270 type terminals

• An IBM-compatible host

SNA host networks.

These are minimum requirements and the actual description of the service is more general in that

it will work with other terminals, hosts, and networks.

"There is also ongoing work within ANSI to define Explicit Call Transfer and Single Step Call Transfer

Supplementary Services.

744 NIU-Forum Agreements on ISDN
ISDN Network

Caller

Calling Party/

Number

Figure 7-10. Call Delivery with Data Service Element Description.

NIU-Forum Agreements On ISDN
7.2.1.5.2 Alternative Architectures

Two architectures for this application have been proposed and adopted (March 1989 and June 1989

NIU-Forum). The first architecture calls for the Call information to be delivered to the agent's

station or terminal adapter (TA)'^ and then have that device transmit it to the host application (see

fig. 7-11). If the agent's station is sufficiently intelligent (e.g., a personal computer), the station

could run the application locally.

The second architecture calls for the Host to provide the central office or customer premises switch

with the Key, and that Key is passed to agent 2's Host (see fig. 7-12). The call is delivered to the

agent's station normally. The data terminal could be attached to the host directly or be attached

using the ISDN Terminal Connectivity Service Element described in section 7.2.1.7.

7.2.1.5.3 Information Flow

The information flow diagrams show the data that must be sent between nodes necessary to provide

the service described. Signalling messages that are normally present (i.e., confirmation messages,

error messages, disconnect) are not shown for simphcity, if they are not necessary to explain the

working of the service.

The information flow for Architecture 1 — Smart Terminal/TA can be seen in figure 7-13.

The call is delivered to the agent's station with the Calling Party Number (CPN). The station will

generate an appropriate screen locally or by interacting with a host application.

The information flow for Architecture 2 — Switch Host interface can be seen in figure 7-14.

The Switch transmits the call setup information to the agent's station and the host computer

simultaneously. The host selects and transmits the appropriate screen.

'^This requires intelligence not normally associated with a TA to satisfy the requirement that any 3270-

like device were to be able to use this service. A separate functional entity, and Intelligence Unit (lU), will

be described as providing the service of relaying Call information to the host. In effect this unit would

upgrade the 3270 to an intelligent terminal with an attached voice terminal. The TA-intelligence unit will

have to be able to have a separate session to the host running, so the data can be passed. Alternately, but more complex, the Intelligence Unit would have to be able to understand the screens being passed between

the host and the terminal and insert information in the data stream.

7-16 NIU-Forum Agreements on ISDN
Agent 1

0 0 D

0 a

0 a D

a a D

Caller

lU

TA

ISDN

Switched Network

Calling

Party

Number

Figure 7-11. Call Delivery with Data Service Element Architecture 1 — Smart Terminal/TA.

Caller

Agent 1

ISDN

Switched Network

Calling Party

Number

HOST

Figure 7-12. Call Delivery with Data Service Element Architecture 2 — Switch Host Interface.

NIU-Forum Agreements On ISDN 7-17
PBX/CO

Call Setup

PBX/CO

Call Setup

(CLID) Call Setup

(CLID) Call Setup

[CLID)_

Callinfo

(CLID)

SEND(SCREEN)

Figure 7-13. Call Delivery with Data Service Element Smart Terminal/TA — Information Flow

Diagram.

PBX/CO

Call Setup

PBX/CO

Call Setup

(CPN) Callinfo

(CPN) SEND(SCREEN)

Figure 7-14.

Call Setup

(CPN)

CaU Delivery with Data Service Element Switch Host Interface

Diagram.

Information Flow

7-18 NIU-Forum Agreements on ISDN
7.2.1.5.4 Network Signalling Requirements — Protocol Identification

In order to implement this service, certain signalling capabilities are required in the user and carrier

networks. Figures 7-15 and 7-16 identify what are the signalling requirements at each point in the

network. As can be seen in the diagrams the requirements for signalling within the network are

the same for the smart terminal and switch-host scenarios, but there are differences within the

premises.

EAMF stands for Equal Access Multi-Frequency which can be used to pass the Calling Party

Number. Any connection between two devices without a specific protocol marked may use any

applicable protocol including a proprietary one.

7.2.1.5.5 Protocol Description

The messages and protocol elements described below are only those required by the service being

described. Other messages and protocol elements are not discussed if they are not used by the

application being described, even through they may be required for other reasons, such as routing

of the call.

7.2.1.5.5.1 Call Setup User Information

The Calling Party Number can be carried from the origination to destination terminal in the

SETUP message described in NIU 90-301 (see Appendix A) and NIU 90-302 (see Appendix B).

The SETUP message is described as sent to the network and by the network toward the called user

to initiate call establishment.

The Information needed to carry the Calling Party Number is described in a paragraph titled Calling Party Number. "The Purpose of the Calling party number information element is to identify the origin of the call." The information element may say that the number is not available,

the application must be able to handle this situation appropriately.

7.2.1.5.5.2 Host-Switch Messages

The necessary function required by this service is the handling of the incoming Calling Party

Number.

The Host Computer messages are being described in the ANSI Switch-Computer Applications

Interface (SCAI) Draft Proposed Standard, TIS 1/92-629 (Ref. [23]).

NIU-Forum Agreements On ISDN 7-19
Agent Station

Caller

ISDN

or POTS

Originating

Office

ISDN

or EAMF

ISDN

BRI

Transit

Switch

or CO

ISDN PBX/CO

(ACD)

Figure 7-15. Call Delivery with Data Service Element Smart Terminal/TA

Requirements.

Caller

Screen

HOST

Optional

Network Signalling

Caller

ISDN

or POTS

Agent Station

Originating

Office

ISDN

Transit

Switch

or CO

ISDN PBX/CO

(ACD)

ISDN

or HOST

EAMF SCAI

Figure 7-16. Call Delivery with Data Service Element Switch Host Interface — Network Signalling

Requirements.

7-20 NIU-Forum Agreements on ISDN
7.2.1.6 Call Back on Busy/Abandonment Service Element

In this service, no agents are available to receive an incoming call. The caller may do any of the

following:

• receive Busy (possible reasons: all agents busy, maximum queue size),

• receive an Announcement (i.e., "All Lines are Busy, An agent will call you back

when one becomes available") followed by disconnect,

• or be placed in a queue (possibly with an announcement "Wait for the next available

agent, if you hangup, an agent will return your call") for the next available agent and

then disconnect.

The caller's phone number will be recorded so that an agent can call back later (see fig. 7-17).

This service cannot be invoked, unless the call is delivered to the final switch.

The sequence of events is as follows:

1. Caller places a call to the phone number of the "Call Delivery service user" (800

number in one user's apphcation).

2. The calling line id is recorded by a host application.

3. The treaunent may be busy, an announcement and disconnect, or being placed in a

queue. If the caller was placed in a queue, they are subsequently disconnected.

4. Agent obtains the number from the application software and places a call.

7.2.1.6.1 User Environment

Some of the users' descriptions of the service have specified a hardware and software environment

in which the service should work. At a minimum, the service should work in the following

environment:

IBM 3270 type terminals

• An IBM-compatible host

• SNA host networks

These are minimum requirements and the actual description of the service is more general in that

it will work with other terminals, hosts, and networks.

7.2.1.6.2 Architecture

Two ai'chitectures for this application have been proposed and adopted (March 1989 and June 1989

NlU-Forum). The first architecture calls for the information to be delivered to the agent's terminal

and the second to a host computer. Only the second architecture is considered here because there

NIU-Forum Agreements On ISDN 7-21
Caller

Figure 7-17. Call Back on Busy/Abandonment Service Element Description.

7-22 NIU-Forum Agreements on ISDN
is no mechanism to pass information about calls that have never reached a station (i.e.. Caller

disconnects, PBX returns busy) to a station.

7.2.1.6.3 Information Flow

The flow diagrams show the general information flow necessary to provide the service described.

Some messages that are normally present (i.e., confirmation messages, error messages, disconnect)

are not shown if they are not necessary to explain the working of the service.

The flow diagram for call abandonment can be seen in figure 7-18. The call setup information,

including Calling Party Number (CPN) goes across the network. The Switch transmits the call setup information (CPN) to the host computer. The caller then "Disconnects" and the host

computer is informed, so it puts the number in a list for later callback. At a later time, the agent

interacts with the host and selects a callback number. The agent can then either generate the call via the host or dial the number using the phone. Figure 7-19 is the flow diagram for the case where the caller receives busy or hears an announcement.

7.2.1.6.4 Network Signalling Requirements

The network signalling requirements for this service are the same as for Call Delivery using the

Switch to Host interface (see fig. 7-16).

7.2.1.6.5 Protocol Description

The messages and protocol elements described below are only those required by the service being

described. Other messages and protocol elements are not discussed if they are not used by the

application being described, even through they may be required for other reasons, such as routing

of the call.

7.2.1.6.5.1 Call Setup User Information

The Customer identifier can be carried from the origination to destination terminal in the SETUP

message described in NIU 90-301 (see Appendix A) and NIU 90-302 (see Appendix B). The

SETUP message is described as sent by the calling user to the network and by the network to the

called user to initiate call establishment.

The Information needed to carry the Calling Party Number is found in the paragraph titled Calling

Party Number. "The purpose of the Calling party number information element is to identify the

origin of the call." The information element may say that the number is not available, the

application must be able to handle this situation appropriately.

7.2.1.6.5.2 Host-Switch Messages

The necessary function required by this service is the handling of the incoming Calling Party

Number.

The Host Computer messages are being described in the ANSI Switch-Computer Applications

Interface (SCAI) Draft Proposed Standard, TIS 1/92-629 (Ref. [23]).

NIU-Forum Agreements On ISDN 7-23
II

III

It PBX/CO

Call Setup

sconnect

Call Setu£

<-——

PBX/CO

Call Setup

(CLID)

Call Setup

Cut Through

HOST

Init Call

(CLID)

Notificatic

. Initi

00

D a D

D 0 0 ODD

Query Di sconnects

n of Call

ation

CLIDs

Place CalKCLIDIi.

* Placement of the Call could be from a Phone

Figure 7-18. Call Back on Busy/Abandonment Service Element Information Flow Diagram

Abandonment.

7-24 NIU-Forum Agreements on ISDN
oil oil

oil

oil PBX/CO

Call Setup

PBX/CO

Call Setup

(CPN)

Call Setup

Cut Through

HOST

Callinfo

(CPN/Busy)

Init Call

(CPN)

Notificati on

Initia

0 a II DOB

0 a 0

0 a D

Query Disconnects

C LIDs

Place C

of Call

tion

ll(CPN)*

* Placement of the Call could be from a Phone

Figure 7-19. Call Back on Busy/Abandonment Service Element Information Flow Diagram — Busy.

NIU-Forum Agreements On ISDN 7-25
7.2.1.7 Terminal Connectivity Service Element

This service provides connectivity between a terminal and a host using an ISDN link. This is

illustrated in figure 7-20.

The sequence of events is as follows:

a. The user causes a call to be placed from the terminal to a port on the

host/controUer.'^

b. Upon connection of the call the data transport protocol is initiated.

c. When the data session is complete the call is disconnected.

7.2.1.7.1 User Environment

Some of the users' descriptions of the service have specified a hardware and software environment

in which the service should work. At a minimum, the service should work in the following

environment:

• IBM 3270 type terminals

• An IBM-compatible host

• SNA host networks.

These are minimum requirements and the actual description of the service is more general in that

it will work with other terminals, hosts, and networks.

7.2.1.7.2 Information Flow

The information flow diagrams show the data that must be sent between nodes necessary to provide

- the service described. Signalling messages that are normally present (i.e., confirmation messages,

error messages, disconnect) are shown for simphcity if they are not necessary to explain the

working of the service.

The flow diagram in figure 7-21 shows the general information flow necessary to provide the

described service.

'^The use of some ISDN features for security (i.e., CLID) may be required, but are not part of the user

application description (text or figures).

7-26 NIU-Forum Agreements on ISDN
BRI BRI or PRI

Figure 7-20. Terminal Connectivity Service Element — Description.

Terminal CO/PBX CO/PBX HOST

Call Setup

(Phone Number)

Connect

Call Setup

Connect

Call Setup

Connect

Normal Call

Initiation Sequence

Channel Open

Data Message

Data Message

Data Message

Data Message

Disconnect Disconnect

Data Communication

Protocol

Conversation Complete

Disconnect Normal Call

Completion

(Either side may

initiate)

Figure 7-21. Terminal Connectivity Service Element Flow Diagram.

NIU-Forum Agreements On ISDN 7-27
7.2.1.7.3 Network Protocol Requirements

The network protocol requirements for this service can be seen in figure 7-20. As shown in that

figure, there needs to be ISDN connectivity between the terminal and the point where it is attached

to the computer or controller.

The higher layer protocols for carrying the user data are not described here. The Network

Interconnectivity Profile Team should provide the higher level protocol specification when

completing Application Profiles for the User Application Requirements Data Forms numbered:

830008, 830009, 960009 (Refs. [40, 41, 42]).

7.2.1.7.4 Protocol Description

The messages and protocol elements described below are only those required by the service being

described. Other messages and protocol elements are not discussed if they are not used by the

application being described, even through they may be required for other reasons, such as routing

of the call.

The protocol described in NIU 90-301 (see Appendix A) and NIU 90-302 (see Appendix B) can be used for the setup and breakdown of the call being made to carry the data protocol.

The only information element that may have a direct bearing on the service is in the SETUP

message described as "sent by the calling user to the network and by the network to the called user

to initiate call establishment." The information element is the Bearer Capability Informafion

Element. The user can ask for the appropriate information transfer capability and transfer mode.

7-28 NIU-Forum Agreements on ISDN
7.2.1.8 Protocol Summary and Status

The following is a summary of the protocol requirements of the Incoming Call Management

Application.

Table 7-1. Protocol Requirements for Incoming Call Management Application Profile

Application

Service Element

Protocol Element Document

Call Transfer

With Associated Data

User—User NIU 90—301 & NIU

90—302 Implementation

Agreements

Call Transfer TIS 1.2/92—185 (Ref. [22])

Hn<jt Switch TlSl/92 629 SCAI Draft

Proposed Standard, (Ref.

[23])

Call Delivery

With Associated Data

Calling Party Number NIU 90—301 & NIU

90—302 Implementation

Agreements

Host—Switch TIS 1/92—^29 SCAI Draft

Proposed Standard, (Ref.

[23])

Terminal Connectivity Bearer Capability NIU 90—301 & NIU

90—302 Implementation

Agreements

Higher Layer Network Interconnectivity

Family

Call Back Calling Party Number NIU 90—301 & NIU

90—302 Implementation

Agreements

Host—Switch TIS 1/92—629 SCAI Draft

Proposed Standard, (Ref.

[23])

NIU-Forum Agreements On ISDN 7-29
7.3 ISDN CPE Compatibility/Capability

7.3.1 Building Controls

This application profile, NIU 91-002, provides User Descriptions, Terminal Adapter Functional

Requirements and Application Architecture Analysis for the Building Controls Application

830013.0, (Ref. [43]).

7.3.1.1 User Description

The Building Controls application consists of a variety of control functions carried out with the

objective of monitoring and managing a building and its facilities in a cost effective manner. Some

of the representative functions are:

• Control of heating/ventilation and air conditioning equipment.

• Energy management.

• Comfort control.

• Fire monitoring and facility control in a fire situation.

• Security monitoring and control.

• Control of personnel access to restricted areas.

The application currently consists of the following components:

• Sensors that are attached to key metering equipment.

• The sensors are connected to control processors which either store information or

initiate action based on the sensor readings. This connection is proprietary in nature and

will not utilize ISDN services.

• Up to 31 control processors can be connected to a central processor in a multidropped,

polled environment. The central processor stores, sorts and relays data received from its associated control processors. Additionally it provides an operator interface and transmits

stored information to the end customer's host computer.

In the typical implementation in-house wiring is used to connect the central processor and its associated control processors. The interface used is RS-485 providing synchronous communication

between 1200 and 9600 bps.

Control processors can also be connected remotely over private line facilities. The physical

interface in this implementation is RS-232 providing synchronous or asynchronous communication

between 1200 and 9600 bps. The asynchronous format is more common and utilizes either an 8

bit or 9 bit data format.

The link from the central processor to the customer's host utilizes an RS-232 interface which

provides synchronous or asynchronous communication at 2400 bps.

This profile will focus on uulizing ISDN services for connections between 1) the control and

central processors, and 2) the central processor and customer host computer.

7.3.1.2 Terminal Adapter Functional Requirements

Table 7-2 provides a summary of the basic functionality required for terminal adapters to operate

in this application. This summary assumes the use of D-Channel permanent virtual circuits and BChannel packet services between the central and control processors.

7-30 NIU-Forum Agreements on ISDN
The link from the central processor to the host computer will utilize B-Channel circuit data

services. The Application Architecture discussion in section 7.3.1.3 describes the ISDN data

services to be used.

Table 7-2. Building Control Application Functional Requirements

Feature Central

Processor

T A

Control

Processor

TA

Customer

Host

TA

RS-232 Async "R" Interface Option Yes Yes

RS-232 Sync "R" Interface Yes Option Yes

RS-485 Sync "R" Interface

Proprietary Protocol

Option Option No

9 Bit Async Data Option Option Option

8 Bit Async Data Option Yes Yes

NOTES:

1) An answer of "Yes" means that support for this feature is required.

2) An answer of "Option" means that support for this feature appears desirable but may

not be required.

3) An answer of "No" means that support for this feature is not required.

4) The round trip transit time for a poll and corresponding response through the network

should not exceed 50 ms. This is exclusive of processing time at the Control Processor.

5) The data word formats used are 8 data bits + no parity and 8 data bits + 1 parity bit.

6) Currently the Central Processor can support up to 31 Control Processors. This number

may be increased at a future date.

7.3.1.3 Application Architecture

The application architecture is based on the use of D-Channel permanent virtual circuits to each

control processor. A nailed-up B-Channel packet service is used to connect the appropriate control

processors to the central processor. This approach implies that the cenu-al processor will substitute

X.25 for layers 1, 2 and 3 of the proprietary protocol that is currently used. The use of PVC's and

nailed-up connections reasonably emulates the current multidropped environment and negates any

requirement for the processor and terminal adapter to exchange commands for call setup or call clearing.

The central processor uses a file transfer facility to transmit information to the customer's host

computer. Either D-Channel packet or B-Channel circuit switched data services could be used to support this requirement.

Figure 7-23 illustrates the topography of this application.

NIU-Forum Agreements On ISDN 7-31
7.3.1.3.1 Layer 1 Architecture

The layer 1 architecture for this application is fully supported by T1.605 (Ref. [16]). Each control

processor will function in a Point to Point environment; however, Point to Multipoint arrangements

may be considered where distance limitations can be met.

7.3.1.3.2 Layer 2 Architecture

The layer 2 architecture for this application is fully supported by X.25 (Ref. [28]) LAPB

procedures on the B-Channel and T1.602 (Ref. [13]) LAPD procedures on the D-Channel.

7.3.1.3.3 Layer 3 Architecture

The layer 3 architecture for this application is fully supported by T1.608 (Ref. [18]).

7.3.1.3.3.1 Central Processor Terminal Adapter Architecture

Terminal adapters attached to the cenu-al processor would utilize B-Channel packet services to allow the central processor to poll up to 3 1 control processors. This implementation requires that the central processor utilize X.25 for layers 1, 2 and 3 of the proprietary protocol and imphes that the X.25 data will presented in a standard HDLC format.

The physical interface provided would be RS-232 and would support speeds up to 9600 bps. The

requirement to support RS-485 is discussed in section 7.3.1.3.3.5 (Issues And Limitations).

The terminal adapter used for data transfer to the customer's host would utilize B-Channel circuit

data services. The physical interface provided is RS-232 and it would support either asynchronous

or synchronous data formats at speeds up to 9600 bps.

7.3.1.3.3.2 Control Processor Terminal Adapter Architecture

A terminal adapter attached to a control processor would utilize D-Channel PVC packet services.

PVC's are required to support the following requirements:

• Round trip delay within network should not exceed 50 ms. The use of virtual circuits

would not meet this requirement.

• Control processor must be able to transmit alarm information immediately to the central

processor.

The terminal adapters utilizing D-Channel packet services would interface to control processors as follows:

• RS-232 interface

• Asynchronous data

• 8 bit word format

• Speeds up to 9600 bps

The following interface support is discussed in section 7.3.1.3.3.5 (Issues And Limitations):

• RS-485 interface

• Synchronous data

• 9 bit word format

7-32 NIU-Forum Agreements on ISDN
7.3.1.3.3.3 Customer Host Terminal Adapter Architecture

The customer host terminal adapter would utilize B-Channel circuit data services to communicate

with the central processor. D-Channel packet services could be considered, however, the terminal

adapter could not currently support synchronous data.

The physical interface required is RS-232 and will support speeds up to 9600 bps. The data format

can be either asynchronous or synchronous.

In the asynchronous mode the terminal adapter may have to provide a command interface to allow

the establishment and clearing of calls. Alternatively an autodial mechanism may be provided

which will dial a stored number when the DTE provides an appropriate signal e.g., Data Terminal

Ready.

In the synchronous mode an autodial mechanism could also be considered.

7.3.1.3.3.4 Protocol Architecture Overview

The protocol stack shown below illustrates the peer to peer communications in the architecture

described above.

CENTRAL

PROCESSOR

TA

HIGHER

LAYER

PROPRIETARY

PROTOCOL

LAYER 3

T1.608

LAYER 2

X.25 LAPB

LAYER 1 T1.605

NETWORK

LAYER 3

T1.608

LAYER 2

T1.602

X.25 LAPB

LAYER 1 T1.605

CONTROL

PROCESSOR

TA

HIGHER

LAYER

PROPRIETARY

PROTOCOL

LAYER 3

T1.608

LAYER 2

T1.602

LAYER 1 T1.605

Figure 7-22. Building Controls Protocol Stack.

7.3.1.3.3.5 Issues And Limitations

The following issues are raised by this architecture:

1) There are currently no standards that define the interface between a synchronous DTE

and X.25 packet assembler/disassembler (PAD).

NIU-Forum Agreements On ISDN 7-33
2) There are currently no standards that support the use of 9 bit data from a start/stop

DTE on an X.25 network. The requirement to octet align the data for transport on the

network may require significant development.

3) The addition of RS-485 interfaces to terminal adapters will require significant

development.

4) The requirement for a 50 ms round trip transit time for a poll and response may not

be achievable in all cases.

The following limitations are imposed by this architecture:

1) The central processor will have to substitute X.25 for layers 1, 2 and 3 of the

proprietary protocol.

B-CH

Circuit

D-CH

PVC

RS-485

RS-232 RS-485

Control

Processor xi

TA Control

Processor

D-CH

PVC

RS-485

RS-232

TA Control

Processor

D-CH

PVC

RS-232

TA Control

Processor

D-CH

PVC

RS-232

TA Control

Processor

Figure 7-23. Building Controls Application Topography.

7-34 NIU-Forum Agreements on ISDN
7.4 ISDN Network Interconnectivity

7.4.1 Data Conferencing (Point-to-Point)

This proposed Application Profile (pAP) for application 810004 (Ref. [35]) Data Conferencing

(Point-to-Point) is distinguished from that of ISP application profiles for ISDN/OSI functional

standards.

The Attachments are either tutorial in nature or provide information as to extensions for pAP

810004. When pAP is progressed through the IIW Expert Working Groups, it will then achieve

a status of approved Apphcation Profile (aAP). As contained herein, pAP 810004 is a first-order

approach to identifying particular profiles that need to be expanded in the sense of Implementors'

Conformance Statements (ICS), PICS, and Requirements List (RL) that encompass both the

application environment and the ISDN/OSI environment.

7.4.1.1 Scope

The pAP 810004 delineates a set of profiles that identify the service/protocol specifications needed

in order to comply with the ISDN functional standards (de jure) for aAP 810004.

pAP 810004 is point-to-point data conferencing. Multi-way (multi-peer) data conferencing is outside the scope of pAP 810004. pAP 810004 is limited to circuit-switched profiles. pAP 810004

logical or physical reahzations are outside this scope, unless they are implicit in the cited reference

model or standards for pAP 810004.

De facto aspects (NETbios) of pAP 810004 have been mandated by the lUW of the NIU-Forum.

Circuit switched facilities are also stipulated by the lUW. OSI profiles are cited if they have been

defined by other SPOs'.

7.4.1.2 Field Of Application

pAP 810004 in its future state (aAP 810004) coupled with NIU Forum implementation agreements

will govern compliant product implementations (physical realizations) of point-to-point data

conferencing over public or private wide-area ISDNs.

Customer premise environments have either BRA or PRA network termination and may involve

LANs, PBXs or Private Switched Networks (PSN).

7.4.1.3 References

ISO DISP AFTnn-1: 1989 (E); Source: Standards Promotion and Application Group (SPAG).

COS Profile Selection (1989-1990) Final Draft Version 2.0, May 25, 1989.

ISPBX Networking by ECMA, TR/NTW, 2nd Draft, agreed, April 1988.

ISO XX: 1989 (E), Information Processing Systems - XX - Common Upper Layer Requirements.

NetBIOS Interface to ISO Transport Services and Name Service Protocol Specification 89-00-0001-

TNS (MAP/TOP)

'Standards PromoUon Organizations such as NIST, ETSI, INTAP, COS, MAPA^OP. et al.

NIU-Forum Agreements On ISDN 7-35
ISO TR/10000, Information Processing Systems - International Standardized Profiles, ISO/IEC

JTCl/SGFS

Part 1 - Taxonomy Framework N109, 1989-02-15

Part 2 - Taxonomy of Profiles N126, 1989-04-13

CCITT I.Series Bluebook

ISO 9646 OSI Conformance Testing Methodology and Framework

7AAA Deflnitions

Table 7-3. Definitions

Definitions pAP - oriented

1. ICS*

2. ISPICS'

3. pAP/ICS

4. PICS

5. Profile*

6. Requirements List

(RL)

'adapted from DTR/10000-1

Implementation Conformance Statement is a

statement by the vendor (as constrained by the

applicable profiles and PICS) regarding the

implemented product's compliance with the base

standard(s), profiles, PICS and the requisite

conformance options.

International Standardized Profiles Implementation

Conformance Statement which aligns ISP features, functions or options in the sense of static conformance requirements.

This alignment includes base standards, the profiles, and

implementation choices.

is equivalent to a pAP/RL (which is provided for each profile

in a pAP) but shows the general options of the profile (as a whole) coupled with a list of protocols selected and combined

in the Profile as reflected in the PICS

protocol implementation conformance statement

a profile makes explicit the relationships between a set of

standards used together. A pAP/ICS is the equivalent of a

PICS. The pAP/ICS emphasizes function, service options and

features. The PICS concentrates on the protocol parameters,

ranges, or characteristics.

it is the purpose of an RL to specify the NIU-Forum pAP/RL

Profile's constraints on what may appear in the "Support" and

"non-support" (values etc.) columns in the relevant pAP and

PICS pro forma.

7-36 NIU-Forum Agreements on ISDN
7.4.1.5 pAP 810004 Requirements List

Table 7-4. General Level Plus Scenario Level

Field of Application (RL) 810004

A.A PUBLIC Services

A.B PRIVATE Services

A.C HYBRID Services

User/Provider Feature Set (RL) 810004

X.U Peer User(s) Types

X.R Server Types

X.D Domain Types

Table 7-5. General Level plus Scenario Level plus Functional Level

Field of Application (RL) 810004

A.Al User's CPE - Public Service

A.A5 Peer User CPE - Public Service

A.Bl User's CPE - Private Service

A.B6 Peer User's CPE - Private Service

A.C1 User's CPE - HYBRID Service

A.C7 Peer User's CPE - HYBRID Service

User/provider Feature Set (RL) 810004

X.IF no peer user X.2F one (1) peer user X.5F server co-incident with user X.6F servers are symmetric

X.4F one domain (multi-in-sessions)

X.8F symmetric peer domains (multiin-sessions)

NIU-Forum Agreements On ISDN 7-37
Table 7-6. All 810004 "leafs"

Field of Application (RL) 810004 branch

leafs

A.All TEl PUBLIC

A.A12 TE2 PUBLIC

A.A13 NT2 PUBLIC

A.A14 PSN ism PUBLIC

A.A57 NTl (T) PUBLIC

A.A58 peer user LLP PUBLIC

A.A59 peer user HLF PUBLIC

A.Bll TEl PRIVATE

A.B12 TE2 PRIVATE

A.B13 NT2 PRIVATE

A.B14 PSN (SAT) PRIVATE

A.B67 NTl (T) PRIVATE

A.B68 peer user LLP PRIVATE

A.B69 peer user HLP PRIVATE

A.Cll TEl HYBRID

A.C12 TE2 HYBRID

A.C13 NT2 (sm HYBRID

A.C14 PSN (sm HYBRID

A.Cll NTl (T) HYBRID

A.C78 I>eer user LLP HYBRID

A.C79 peer user HLP HYBRID

Table 7-7. Requirements List

User/provider Feature Set (RL) 810004

leafs

X.15d file transfer, NetBIOS (no peer)

X.25d file transfer, NetBIOS (pt-to-pt)

X.55d file transfer, NetBIOS (co-incident)

X.65d file transfer, NetBIOS (symmetric)

7-38 NIU-Forum Agreements on ISDN
7.4.1.6 pAP 810004 Conformance Requirements

See reference section 7.4.1.5 for details.

Table 7-8. Conformance Requirements

RT pAProfiles r^nn form Jin pAP Supported on option

810004

features

rPF ISDN

A.Al X, M,Q I, M m

A.A5 X, M,Q I, M m

A.Bl X, M,Q I, M 0

A.B6 X, M,Q I, M 0

A.Cl (ffs) Q, V I, M o A.C7 (ffs) Q, V I, M 0

X.2 X, M.Q 1, M m

X.6 X, M,Q I, M m

X.8 (ffs) X, M,Q I, M 0

X.25d X, M, Q I, M m

X.65d (ffs) X, M,Q I, M 0

M profiles are different at CPE than ISDN environments

m = mandatory conformance

o = optional conformance

ffs = for further study

7.4.1.7 pAP 810004 Configurator

Note: the following section contains all of the information from the 810004 application

requirements and application analysis documents.

Figure 7-24, Figures 7-26 and 7-27, and Table 7-13 used in this section depict the basis for a pAP

810004 Configurator. The notion of a "configurator" enables functional (e.g., service overviewTable 7-13) and logical (figs. 7-24, 7-26 and 7-27) models to abstract Uie pAP 810004 application

and connectivity details.

NIU-Forum Agreements On ISDN 7-39
Table 7-9. Requirements Stipulated by the lUW as Augmented by the IIW/AAG

NIU-Forum/810004 must want

interworking public private (PSN)

de facto industry LAN protocols NETbios PC/LAN

LAN-type access to databases X

LAN-type ACCESS to data server X

bearer service (ckt. switched) 64 kb/s 128 kb/s

bearer service demand BRA or PRA

file transfer & sharing X

image (graphics) flow X

PCs and servers (IBM compat.) X

host with TA

multi-peer X

multi-sessions X

voice future

security No No

performance (128 kb/s synch'd) ckt. switched ffs

access arrangements departmental nationwide

application-independent X

PBX/CO-LAN/VPN/CCS #7/PSN X

LAN media-independent X

Addressing and/or signalling I.Series PSN

NOTE: ffs = for further study

Adapting the ISDN Reference Configuration, the pAP 810004 configurator is depicted in figure

7-24. This figure implies an end-to-end set of interworking (general-level) profiles based on the

preceding values for the "must" requirements. This set of profiles is in Table 7-10.

7-40 NIU-Forum Agreements on ISDN
Table 7-10. General-Level pAP 810004 Profiles

Source Wide-Area Destination

a) M (MAP/TOP NETBIOS)

b) V (file xfr, file sharing)

c) Q = M = I = LLF

d) X = (.U, .R, .D)

e) A = PUBLIC

I. Series

I. Series

I. Series

I. Series

I.Series

M (NETbios)

V (file xfr. ...)

Q (...)

X ...

A ...

NOTES:

a) adopts the MAP/TOP NETbios Interface document and the Name Service Protocol

functions.

b) enables high level functions (HLF) that denote file transfer and file sharing as utilized by

application-independent means (e.g., elec. publishing, document sharing, screen sharing,

etc.).

c) determines circuit switched bearer service of 1 or 2 transparent B channels on-demand.

d) addresses the user CPE as to access arrangements for types of users, types of servers, types of domains, etc.

e) isolates the field of application aligned with bearer, supplementary or teleservice

functions.

NIU-Forum Agreements On ISDN 7-41
USER

TE NT12

NETWORK

PUBLIC

ISDN

Where network facilities are circuit switched

Where TE may be a host (via TA&R reference point)

* TE

* - NT2 or NULL

Where NT12 may be: A) PSN of one or more ISxyz: Where xyz may be

B) Sub-network configuration of one or more of

I) ISLAN

II) ISPBX

III) Centrex/CO-LAN

IV) LAN GAV or IWU

Figure 7-24. pAP 810004 Reference Model

7-42 NIU-Forum Agreements on ISDN
Figure 7-26 further refines or simplifies figure 7-24 to the extent that the "basic" pAP 810004

products need only deal with symmetric CPE environments and interoperability, namely:

v,x

M, A

x,v

A,M

Q,A A,Q

I, A

I,M

wide-area A, I

CPE CPE

Source Destination

Figure 7-25. pAP Profile Stacks

This aligns the prior figure 7-24 discussion with the above stacks as follows:

b), d) = V, X c), e) = Q, A

a), e) = M, A e), (w/a) = 1, A

See notes a-e after General-level Profile in this section.

This alignment reveals that wide-area (w/a) ISDN connectivity is based upon I. Series and SPO [M]

profiles that are to evolve via NIST(NIUF), ETSI(EWOS), INTAP(AOW), etc. for provider

services.

NIU-Forum Agreements On ISDN 7-43
c

o

U

3 u

Bou

.a

CO m

2

9

Z

1c

u

B

3 B

X

J3

= ui

.. 6

7 U.

NIU-Forum Agreements on ISDN
Figure 7-27 is the "extended" pAP 810004 configurator which is outside the scope of this pAP

810004 (point-to-point) "basic" configurator.

The purpose of including the pAP 810004 extended configurator is to encourage vendors to adopt

general-purpose architectural criteria when setting out to meet pAP 810004 requirements.

Table 7-11. Extended pAP 810004 Configurator*

ISDN customer Private Switched I premise end-point (NT12) network (ISDN)

on-demand on-demand

open (B) null dial-up (P)

on-demand on-demand on-demand

open (B) (p) open availability dial-up (P)

(p,P) shared-facility (E) + exclusive-use (P) dial-up

CUG (E) exclusive-use (P) dial-up

(P) off-net (E) gateway (p/P) dial-up

open (B) null CO-LAN

CUG (B) null PVN

I SDN carrier

network

dedicated end-point

leased

leased

dedicated end-point

leased

leased

pre-established-channels (E)

channel assoc. signalling

pre-established-channels (E)

shared facility

CUG

off-net

shared facility

CUG

off-net (ffs)

(B)

(E)

(B)

(E)

(p) permanent

dedicated (leased)

(p) pure ckt. switched

(P) ckt. switched/ISDN

signalling control

null

permanent (p)

channel assoc. signalling

channel assoc. signalling

channel assoc. signalling

+ gateway (p/P)

permanent (p)

intra-PSN

intra-PSN

intra-PSN

dedicated (leased)

pure ckt. switched

ckt. switched/ISDN signalling

control

dedicated (leased)

pure ckt. switched

ckt. switched/ISDN signalling

control

permanent (P)

ckt. switched/ISDN signalling

ckt. switched/ISDN signalling

ckt. switched/ISDN signalling

ckt. switched/ISDN signalling

permanent (P)

invisible

invisible

invisible

P = public

p = private

inUa-PSN = PVN

B = basic configurator

E = extended configurator

*deduced from ECMA ISPBX TR/XX

NIU-Forum Agreements On ISDN 7-45
NIU-Forum Agreements on ISDN
Table 7-13 is the overall framework for the pAP 810004 configurator. It is also an overview of

a service model. The properties of this framework are addressed in the Attachments.

The key aspects of the table 7-13 framework include:

• the notion that the carrier backbone network is augmented by a private network backbone in the sense of ISDN ISP profiles

• such augmentation is facilitated by profiles for Basic low layer functions (BLLF) that are aligned

end-to-end across private and/or public sub-networks. Similarly, Additional LLPs are so aligned

(ALLF). High-level functions may also be augmentations to both the (basic and additional) carrier

and private backbones

• these Basic and Additional functions are provider-oriented in the sense of supporting the user's

application environment. This notion of augmentation, when extended into the user's application

environment, leads to further value-added application(s) augmentation as the following examples

depict:

Table 7-12. pAP Configurator Descriptors (E) (examples only)

User/Provider user provider

Feature Set Aspects VLLF VHLF VLLF VHLF

service B B, A B, A

application S N S N

features

interfaces S S

• the substance of the above notions, augmentations and alignments, are administered via

requirements list(s) at each plateau (carrier, private, CPE). The RLs are the fundamental

application of the pAP taxonomy which is detailed in the Attachments. Viewed as a tree with

trunk, branches and leaves, it enables each pAP/RL to denote work items or work-to-be-done in the sense of implementation agreements.

backbone-related descriptors

where V = value-added B = basic LLF or HLF

S = supported A = additional LLF or HLF

N = non-support

- = profile RLs

NIU-Forum Agreements On ISDN 7-47
Table 7-13. pAP 810004 Service Overview

Customer

Premise

Environment

Wide-Area

Network

pAP-8 10004

User/Provider 810004 Field of Application

Feature Set RL

AHLF PSN BHLF

ALLF RL BLLF

AHLF ISDN BHLF

ALLF RL BLLF

RL - Requirements List

HLF - High Layer Function(s)

LLF - Low Layer Function(s)

PSN - Private Switched Network

B = Basic

A = Additional

NOTE: PSN and ISDN HLF and LLF May differ

7.4.1.8 Attachment 1 — Proposed Application Profile (pAP) Overview

The following pAP concerns are separate:

I. ISP Profiles per part 1, section 6 of TR/IOOOO

A. Standards

B. Registration Mechanisms

C. Conformance

II. IIW Profiles per the NIU-Forum

A. Environment (Application)

1. Application Requirements (lUW)

2. Application Analysis (IIW)

B. User/Provider Interaction

C. Application Requirements List

D. SPO Profile Selection

E. I. Series Services

F. NIU-Forum Conformance

The following pro forma outline of a pAP is based on the notion that a service-oriented model

should convey a sufficient set of properties of a pAP which are aligned with standardized functions

and options (in the sense of profiles) to enable implementors' to succeed in having their pAP

derived products interoperate.

7-48 NIU-Forum Agreements on ISDN
pAP products may be realized via application, product, service, or combinations thereof:

pAP pro forma

1. Scope

1.1 Functional Model (Service-oriented)

1.2 Objective Criteria

1.3 Field of Application

2. Services

2.1 Service Elements/Class

2.2 Features/Functional Units

2.3 Facilities/Interworking

3. Profiles

3.1 Identify

3.2 Requirements List - pAP

3.3 Implementors' Conformance Statement (ICS) pAP

4. Conformance Requirements

The root structural identifier for a proposed Application Profile (pAP) is designated as

This identifier assumes the Application Environment definitions per the fUW treatment of xxxxxx

which is the numeric lUW identifier for each ISDN-oriented application.

7.4.1.9 Attachment 2 — pAP Taxonomy Overview

The pAP identifier structure is extended for user/provider interplay and for user/network, or

user/user signalling: The general form of the schema is

where

Y = the major structural identifier for the general-level

A = the minor structural identifier for sub-levels of organization of the general-level

yjX - ^6 particular sub-levels as defined by A

if A = S it signifies the scenario-level of interaction within a particular general-level

pAP xxxxxx

identifier

if A s F it signifies the functional-level of interaction within the scenario-level

identifier(s)

if A s f P It signifies the protocol-level of interaction within the functional-level

identifier which is within the scenario-level (s 0

finally, where A is Physical-level

.D

.B.E

.H

signalling channel

basic rate access primary rate mux channel

wide-band rate access

NIU-Forum Agreements On ISDN 7-49
the schema shifts so that the physical-level identifier always occupies first position in the schema

following the decimal point;

thus y.xxxx is .D s f p

.B s f p

.E s f p

.Hsfp

The latter identifiers are the most subordinate in the pAP Taxonomy and are the "leaf of the pAP

Taxonomy "tree" of profiles. These leaf profiles may enable such details and options like

attachment speeds and connectors to be registered by the pAP identifier. This specificity is for

further study.

pAP Schema Overview

The pAP Application Environment resides within the Customer Premises Environment unless

Enhanced Service Providers are part of the service interworking.

The root identifier [pAP xxxxxx] and related definition of the Application Context (signals from

the environment) is linked to general-level profile identifiers such as:

X user/provider feature set R requirement list A field of application

M Standards Promotion Organizations (SPO) profile selection

I ISDN I.Series base standards

NOTE: M profiles may encompass I profiles

When the general-level designator <M> is used in the sense of the I profiles, it extends the schema

and profile descriptor's beyond the Application Environment designators <X>, <R>, and <A> to the standardized ISP realm of profiles.

When Y-A is M.A it depicts SPO general-level profiles

and if A is it is general-level

2 1.200 Series

3 1.300 Series

4 1.400 Series

5 1.500 Series

6 1.600 Series

The pAP AppHcation resides on customer premise sub-networks/equipment /environment. Such

CPE may be as small as one sub-network or an extensive private switched network. The structural

profile identifiers for the CPE/PSN backbone are

Q Low Layer Compatibility Functions

V High Layer Compatibility Functions

7-50 NIU-Forum Agreements on ISDN
7.4.1.10 Attachments — pAP 810004 Tutorial

Organization

The service framework depicted in table 7-13 [pAP 810004 Service Overview] is structured in a top-down manner. This structure incorporates two (2) independent stacks of profile factors; the

field-of-application stack and the user/provider feature-set stack which are separated by

Requirements List (RL) identifiers.

NOTE: The profile factors "stack" should not necessarily be interpreted as protocol stacks.

The structure depicted in table 7-13 is an integrated layered-view of the properties of the pAP

810004 taxonomy (based on Attachment 4), the pAP 810004 application and the pAP 810004

configurator (basic and extended - pages 7-39 through 7-48).

The middle column of table 7-13 depicts pAP 810004, PSN and ISDN requirement lists (RL)

which are descriptors that are dependent on the two (2) types of profile stacks mentioned in the

first paragraph. This means that particular realizations of pAP 810004 will encompass RL selected

profile factors, services, features and conformance requirements. These RLs are directly related

to pAP 810004 profile attributes in contrast to generic properties of the taxonomy, configurator,

application, service, conformance, or features.

NOTE: Attachment 1 is also an attempt to separate pAP 810004 intrinsic matters, e.g., services,

from pAP 810004 extrinsic reahzation matters, e.g. profile ICSs.

Reference Model

Returning to table 7-13, the structure discussed in "1. ORGANIZATION" above displays the

following dependencies whereby the application (pAP 810004), premises (CPE, PSN and provider

support), and intervening networks (ISDN WAN) are unified in terms of services, application,

function, features, reference configurations and everything short of particular de facto logic and

implementation details.

The table 7-13 depiction suggests the "pAP 810004" top-most-level is the "umbrella" for all the

subsidiary levels and profile stacks. It may also imply that this umbrella dictates the contextual

requirements and context/scope for the underlying levels/sub-networks/networks.

The level below pAP 810004 is labelled "Customer Premise Environment" and this level has two

(2) sub-levels. The major sub-level directly addresses pAP 810004 user/provider feature sets and

services that are distinguished from underlying PSN provider functions, services, support and

interworking. The PSN sub-level is an intervening sub-networking infrastructure which visibly (to

the user sub-level) connects the various premise interfaces to the user/application service elements

or functional groupings per the reference configurations.

The orientation of table 7-13 with A = additional ~ at the left profile stack ~ and B = basic - at the right hand profile stack - means that the BLLF and BHLF may be designated for either the

ISDN WAN and/or PSN intervening networks whereas the ALLF and AHLF are considered user- premise extensions. In other words, "Basic" is a property of intervening provider facilities, and

Basic facilities may only be overlaid by "Additional" user provisioned resources, albeit networked,

which are not visible to intervening provider resources.

Table 7-14 (which follows) is an attempt to consolidate the foregoing pAP 810004 "tutorial"

notions by recasting table 7-13 in order to depict a more traditional end-to-end topology for the

NIU-Forum Agreements On ISDN 7-51
pAP 810004 application "umbrella." Table 7-13 was designed to stress the types of profile factors

needed to adequately describe pAP 810004 in generic terms - independent of source or destination

realizations.

Table 7-14 stresses user/provider feature sets in the form of high-level (HLF) or low-level (LLF)

functions "stacked" according to basic (B), additional (A) and value-added (V) service interworking

across the ISDN WAN (the basic capability), the ISDN PSN (the additional capability), and the

ISDN user functions (the value-added capability).

Using table 7-14 and beginning at p. 7-36 [section 7.4.1.5. pAP 81004 RL (General-plus scenariolevel)], it should be discemable what might be the particular properties of a point-to-point pAP

810004 profile — including configurator and conformance parameters.

7-52 NIU-Forum Agreements on ISDN
NIU-Forum Agreements On ISDN
7.4.1.11 Attachment 4 — Application Proflle (pAP) Taxonomy

NOTE: See Attachment 2 for definitions and summary details.

When the general-level is distuiguished using the schema and scenario-level, it enables "trees" to be

structured which have their roots in the general-level identifiers, for example:

when

y.A

IS

and when is A.S A.A

and when is A.S A.B

A.S it is the scenario-level of the field of application

it signifies that this profile is based on PUBLIC services

it signifies that this profile is keyed to PRIVATE services

although public wide-area or transit networks may underlie the

PRIVATE networks

and when is it signifies that the profile is a HYBRID of public/private

A.S A.C services, e.g., a virtual private network (VPN) using pubhc services

By extending the field of application tree <A> to the functional-level, it enables several "branches" which

isolate the particular areas of the pAP 810004 Service Overview (depicted in table 7-13) as follows

when is it is Y-Ax A.Ax the functional-level of the field of apphcation for PUBLIC

services

and when is it is A.Ax A.Al the user's CPE profile that is being addressed

A.Ax A.A2 the provider's Low Layer service profile that is being addressed

A.Ax A.A3 the provider's High Layer service(s) profile

A.Ax A.A4 the provider's value-added (teleservices) diat are distinguished

A. Ax A.A5 the profile for the peer user using PUBLIC services

A.Ax A.A6 the profile for multi-peer users using PUBLIC Services

NOTE: peer (recipient) user's of PUBLIC services are virtually the same as the originating user's profile.

when is it is y.Ax A.Bx the functional-level of the field of application for PRIVATE

services

and when is it is A.Bx A.Bl the profile for the user's (originator) CPE

A.Bx A.B2 the profile for the user's (originator) PSN Low Layer

Functions

A.Bx A.B3 the profile for the user's (originator) PSN High Layer

Functions

A.Bx A.B4 the profile for the user's (originator) PSN value-added

(teleservice)

A.Bx A.B5 the proflle for the user's (originator) PSN value-added

provider, i.e., ESP

A.Bx A.B6 the profile for the peer user (recipient) CPE

A.Bx A.B7 (same as A.B2) for the peer user PSN LLFs

A.Bx A.B8 (same as A.B 3) for the peer user PSN HLFs

7-54 NIU-Forum Agreements on ISDN
A.Bx A.B9 (same as A.B4) for the peer user PSN VAFs

A.BX A.BO (same as A.B5) tor the peer user PSN ESP

NOTE: A.B6 thru A.B9 & A.BO apply to the recipient peer user

when is it is y.Ax A.Cx the functional-level of the field of appUcation for HYBRID

services.

and when is it is A.Cx A.C1 the profile for the user's (originator) CPE using HYBRID

services

A.Cx A.C2 the profile signifies a user's (originator) PSN's use of

HYBRID services

A.Cx A.C3 the profile for the user's VPN using PUBLIC service(s)

A.Cx A.C4 the profile for the user's VPN using PRIVATE service(s)

A.Cx A.C5 the profile for user's CENTREX/CO-LAN using PUBLIC

services

A.Cx A.C6 the profile A.C5 but using PRIVATE services

A.Cx A.C7 the profile for the peer (recipient) user's CPE using HYBRID

services

A.Cx A.C8 peer (recipient) user's PSN use of HYBRID services

A.Cx A.C9 peer (recipient) user's VPN using PRIVATE services

A.Cx A.CO peer (recipient) user's CENTREX/CO-LAN using PRIVATE

services

NOTE: peer (recipient) user's of PUBLIC services are virtually the same as the originating user's profile

when is it is y.Axx A.s f P the protocol-level of the field of application

and when it is A.A f P the protocol-level of the field of application for PUBLIC

services

likewise are A.B f P the protocol-levels of the field of application for PRIVATE

and HYBRID and services respectively

A.C f P

is it signifies the profile

A.s f P A.s f 1 for TEl

A.S f P A.s f 2 for TE2

A.s f P A.s f 3 for NT2 (S/T)

A.s f P A.s f 4 for PSN (S/T)

A.s f P A.s f 5 for PSN (Nx)

A.s f P A.s f 7 for NTl (T)

A.s f P A.s f 8 for peer user LLF

A.s f P A.s f 9 for peer user HLF

A.s f P A.s f a for peer provider LLF

A.s f P A.s f b for peer provider HLF

A.s f P A.s f c for peer provider value-added (teleservice)

NIU-Forum Agreements On ISDN 7-55
NOTE (1): when the above profiles have an f=l; it signifies the user's (originator) CPE use of visible

PUBLIC services for the intervening ISDN WAN

NOTE (2): both "a" and "b" and "c" may associate with the N^, reference point to another ISDN

NOTE (3): for the above profiles, when s = A or B and f = 2, 3, or 4 respectively for the above profiles

p = 7, 8, and 9

NOTE (4): A.s f 6 and A.s f d are reserved for future use

is it signifies the profiles for: A.S f P A.s f k peer provider LLP and IWF is inside ISDN

A.s f P A.s f 1 peer provider HLF and IWF is inside ISDN

A.S f P A.s f m peer provider value-added (teleservice) and IWF is inside

ISDN

A.s f P A.s f n peer provider LLF and IWF is outside ISDN

A.s f P A.s f 0 peer provider HLF and IWF is outside ISDN

A.s f P A.s f p peer provider value-added (teleservice) and IWF is outside

When the functional-level (f=2) then P=k at the protocol-level and N (sub) x=IWF is (inside) ISDN

When the functional-level (f=3) then P=l at the protocol-level and N (sub) x=IWF is (inside) ISDN

When the functional-level (f=4) then P=m at the protocol-level and N (sub) x=rWF is (inside) ISDN

When the functional-level is f=2, 3, or 4 and P=n, o, or p respectively, then N (sub) x=IWF is (outside)

ISDN in each case

when is it signifies the protocol-level functions for

Y.Axx A.A f P PUBLIC Services

A.B f P PRIVATE Services

A.C f P HYBRID Services

and when it designates the following protocol-function categories

P=H Connection Handling

P=Z Routing

P=R Resources Handling

P=S Supervision

P=M Operation and Main

P=I Interworking

P=C Charging

P=P L-2/-3 data unit handling (packet mode)

For the general-level user/provider feature set the specific structural identifiers for the scenario-level follow:

when is it is y.A X.S the scenario-level of the user/provider feature set

and when is X.S X.U the variable U signifies the number of conferencing users (peer-to-peer)

7-56 NIU-Forum Agreements on ISDN
so when it signifies

U=l no peer user U=2 one peer user i.e., point-to-point

U=3 multi-peer users

and when is X.S X.R the variable R signifies the number of independent server domains

so when it signifies the

R=5 server is co-incident with the user CPE

R=6 servers are synmietric with peer users (point-to-point) or multipeer users R=7 server(s) is asymmetric with peer users including being in a

separate CPE from peer users or multi-peer users

and when is X.S X.D the variable D signifies the type of CPE domains that contain users and/or servers

so when it signifies

D=4 one domain which encompasses U=l and R=5 but may have

multiple users in-session with their respective servers D=8 symmetry of peer-to-peer domains and encompasses U=2 or 3

and R=6 but may signify multi-in-sessions between peer

domains

D=9 multi-peer domains which are symmetric as to users and

servers U=3 and R=6 but may signify multi-in-sessions

between multi-peer domains

D=0 multi-peer domains which are asymmetric as to users and

associated servers U=3 and R=7 but may also signify multi-insessions between multi-peer users and asymmetric server domains

when is it is y.Ax X.S F the functional-level of the user/provider feature set

when then

Functional Components

F=i Hold Invocation (disconnect & reservation)

F=f Retrieve (reestablish)

F=n Notify (inform, no response)

F=e Inquire

F=t Transfer

F=j Join (multiparty)

F=a Adjourn

F=r Reroute (to alternate address)

F=m Monitor (watch for Event)

F=x Restart

F=s Split (from a multipart connection)

NIU-Forum Agreements On ISDN 7-57
7.4.1.11.1 Other Profile Taxonomy Matters

The capabihties of the user/provider feature set encompasses the Application/Service/User Program set, the

Application Layer (7) Systems servicing the former set(s), the Upper Layer Architecture as regards directory

services, Security and Network Management, and all Application Platforms whether software or hardware

which form the infrastructure to support the former set(s).

The pAP Taxonomy reserves a number of structural identifiers for several types of serviceindependent/scenario profiles for user-type CPE/PSN environments, as follows:

Identifier User Processing Environment

X.V Application Programs

X.W Communications Processes

X.Q Application Platforms

The user/provider feature set may also address the classical OSI Reference Model application-layer.

when is extended to X.s F the OSI Funcdonal-level

and is a Provider Feature Set

F=l Directory

F=2 Security

F=3 Management

F=4 (reserved)

F=5 File Transfer

F=6 Virtual Terminal

F=7 Message Handling

F=8 Transaction Processing

F=9 Remote Database Access

F=0 Job Transfer & Manipulation

This enables the functional-level designator to distinguish the particular protocol-level by the following

extension

when is extended to the Protocol-level

X.sfP .

and when is X.s 5 file transfer

then is Protocol-identifier

X.s 5 a FTAM (file transfer access and management)

X.s 5 b FTP (file transfer protocol)

X.s 5 c NFS (network file system)

X.s 5 d NetBIOS

X.s 5 e (reserved)

when is it is y.A 2.S the scenario- level for the CCITT 1.200 series which

identifies types of services

7-58 NIU-Forum Agreements on ISDN
9Li

if A - 7 Y Y

if A - "7

if A — A — A,D,L-,.

if A =

is the

type of ISDN service described in the CCITT 1.200 series

types of CCITT 1.200 bearer services, e.g., circuit-mode

types of CCITT 1.200 supplementary services of basic functional components

types of CCITT 1.200 signaling channel management services

types of CCITT 1.200 management services

NOTE: .... = any unused alpha designator

when is then

y.A 2.S CCITT 1.200 services may be registered at the

scenario-level

thus is category

2.x circuit-mode

2.Y packet-mode

2.Z signaling-mode

or is Supplementary Service function (SS)

2. a Number Identification

2.b Call Offering

2.C Call Completion

2.d Multiparty

2.e Conrununity of Interest

2.f Charging

2.g Additional Information Transfer

when signifies Supplementary Service

2.a Number Identification

then is

2.a I Direct Dialing In (DDI)

2.a 2 Multiple Subscriber No. (MSN)

2.a 3 Calling Line ID Presentation( CLIP)

2.a 4 Calling Line ID Restriction (CLIR)

2.a 5 Connected Line ID Presentation (COLP)

2.a 6 Connected Line ID Restriction (COLR)

2.a 7 Malicious Call Identification (MCI)

2.a 8 Sub-addressing (SUB)

when signifies Supplementary Service

2.b Call Offering

then is 2.b 1 Call Transfer (CT)

2.b 2 Call Forwarding Busy (CFB)

2.b 3 Call Forwarding No Reply (CFNR)

2.b 4 Call Forwarding Unconditional (CFU)

2.b 5 Call DeflecUon (CD)

2.b 6 Line Hunting

NIU-Forum Agreements On ISDN 7-59
when

then

2.C

2.C 1 2.C 2

2.C 3

signifies

IS

Supplementary Service

Call Completion

Call Waiting (CW)

Call Hold (HOLD)

Completion of calls to busy subscribers (CCDS)

when

then

when

then

when

then

signifies

when

then

when

then

when

2.d

2.d 1 2.d 2

2.e

2.e 1

2.e 2

2.f

2.f 1 2.f 2

2.f 3

2.g

2.g 1

IS

signifies

IS

signifies

IS

signifies

is

A = A,B,C.

signifies

2.A

2.B

2.C

2.D

2.E

2.F

IS

Supplementary Service

Multiparty SS

Conference Calling (CONF)

Three Party Service (3PTY)

Supplementary Service

Community of Interest SS

Closed User Group (CUG)

Private Numbering Plan (PNP)

Supplementary Service

Charging SS

Credit Card Calling (CRED)

Advice of Charge (AOC)

Reverse Charging (REV)

Supplementary Service

Additional Information Transfer

User-to-User Signalling (UUS)

It IS types of CCITT 1.200 signalling channel management services

.14 category

Telephony (E)

Telephony (A)

Teletex (A)

Telefax 4 (A)

Mixed Mode (A)

Videotex (A)

it is

3.S the scenario-level of the CCITT 1.300 Series

and when is S ISDN reference points

"from 1.230:

(E) an essential access arrangement or bearer service category

(A) an additional access arrangement or bearer service category

7-60 NIU-Forum Agreements on ISDN
then is S=K existing telephony n/w or dedicated

S=M specialized service provider

S=N another ISDN

S=P specialized n/w resource

when is it is y.A 4.S the scenario-level of the 1.400 Series

NOTE: previously, in these Appendices, the schema was extended to identify profiles encompassing

channel types, B, D, E, and H by shifting the schema at the physical-level, e.g., B s f where "s" is also the

scenario-level shifted right one character.

when

then

such as

when

then

when

when

then

and when

y.A

S(or s)

S=R

S=S

S=T

S=U

S=V

IS

may be

is y.Ax

S(or s)

4.S

is 4.B1

4.B3

4.B5

is y.Axxx y.AsF

signifies

F

it is F=l

F=t

F=p

F=c

F=k

or

4.S 4.Bs, 4.Ds, 4.Es, 4.Hs

ISDN Reference Points

or

signifies

4.Bs, 4.Hs

scenario-level based upon types of service

15 scenario-types

Dedicated (pre-established) systems connections

Permanent Public network connections

On-demand Public network connections

at the functional-level

an extension of the various types of scenario-level facilities with

designations for category of connections

,16 connection category

link

transmission system

purely circuit switched

circuit switched/ISDN signalling

circuit switched/packet

'^adapted from ECMA ISPBX TR/NTW

"Ibid.

NIU-Forum Agreements On ISDN 7-61
when is y.As F extended to the functional-level

and is the connection categories'^

F Dedicated

4.B 1 1 physical link

4.B 1 t transmission systems

Permanent

4.B 3 p purely circuit switched

4.B 3 c circuit switched/ISDN signalling

4.B 3 k circuit switched/packet switched signalUng

On-Demand

4.B 5 p purely circuit switched

4.B 5 c circuit switched/ISDN signalling

4.B 5 k circuit switched/packet switched signalhng

when is 4.A s f P extended to the protocol-level'*

then Dedicated Connections (s=l=physical link)

4.B 1 1 1 link establishment

4.B 1 1 2 synchronization

4.B 1 1 3 thruput delay

4.B 1 1 4 signalling u-ansparency

4.B 1 1 5 failure performance

and

then is Dedicated Connections (s=t=transmission system)

4.B 1 t 1 link establishment

4.B 1 t 2 synchronization

4.B 1 t 3 thruput delay

4.B 1 t 4 signalling transparency

4.B 1 t 5 failure performance

and so forth for

Permanent and On-Demand

4.B 3 p 4.B 5 p

4.B 3 c 4.B 5 c 4.B 3 k 4.B 5 k

"Ibid.

''Ibid.

7.62 NIU-Forum Agreements on ISDN
NOTE: If H channels instead of B channels, then the 4.Hxxx schema is needed.

when is it is y.A 5.S the scenario-level for the CCITT 1.500 series

and when it signifies

5.1 Layer 1 interworking (1.511)

5.3 Parameter Exchange (1.515)

5.5 ISDN-ISDN interworking

5.7 ISDN-Private Nets interworking

when is

5.S F extended to the functional-level

and signifies interworking functional requirements

5.5

then is

5.5 c common channel signalling

5.5 X X.75

and when is

5.S f P extended to the protocol-level

then is

5.5 c k signalling at K reference point

5.5 c n signalHng at N reference point

7.4.1.12 Attachment 5 — ISDN RL Structure

Table 7-15. Circuit-mode bearer services, from 1.335

# xfr xfr xfr Estab.

mode rate capab. of conn.

1.1 ckt 64 unres} demand

1.2 ckt 64 unres} (3) reserved

1.3 ckt 64 unres} permanent

5.1 ckt 2x64 unres demand

5.2 ckt 2x64 unres reserved

5.3 ckt 2x64 unres permanent

(3) - during an interim period some networks may only offer restricted digital information transfer capabiUty

(i.e., an all-zero octet is not allowed)

NIU-Forum Agreements On ISDN 7-63
Table 7-16. Unrestricted digital connection types, from 1.335

un

vfr xir xir xir struc oSiaD.

laic CapaU. r\r r*r\TiT* Ui COllil.

A.l ckt 64 unres 8kHz switched

A 0 J\.A CKl Of unres oKrlZ senii-pennaneni

r\.J A ^ CKl vr-T Ulll Co oKxlz. pCliilollClH

A.IO ckt 2x64 unres 8kHz} switched

A.ll ckt 2x64 unres 8kHz} (2) semi-permanent

A.12 ckt 2x64 unres 8kHz} permanent

(2) - RDTD "Restricted differential time delay"

1.510 Definition Relied Upon For A pAP

from: 1.510 section 4.2 Definitions Related to the General ISDN Interworking Configuration

"Interworking

Within the scope of the 1.500 series of recommendations, the term interworking is used to express

interactions between networks, between end systems, or between parts thereof, with the aim of

providing a functional entity capable of supporting an end-to-end communication. The interactions

required to provide a functional entity rely on functions and on the means to select these functions.

These functions which include the conversion of physical and electrical states and the mapping of

protocols, are referred to as interworking functions (IWFs). An IWF may be implemented in the

ISDN, in the other network(s), at the user's premises, through a third-party service provider, or in some combination of these."

ISO/IEC ISP Taxonomy"

The following extracts^" are a small portion of the referenced identifier structure

The ISDN subnetwork identifier structure for ISPs is

4 Integrated Services Digital Network

4 1 Circuit Switched bearer service at S or T

4 1 1 B Channel

4 1 1 1 Semi-permanent access 4 1 1 2 Demand Access

The LAN subnetwork identifier structure for ISPs is

5 Local Area Networks

5 1 CSMA/CD

5 2 Token Bus

5 3 Token Ring

5 4 FDDI

'^extract from DTR/10000-1

2°adapted from ECMA ISPBX TR/NTW

7-64 NIU-Forum Agreements on ISDN
7.5 Messaging and Answering

7.5.1 Voice Messaging Systems

This application profile provides the descriptions necessary to meet the requirements of three NIU-Forum

user applications: "Transparent Networking of Voice Messaging Systems" (860016.0) (Ref. [44]); "Interface

to Voice Messaging Systems" (860018.0) (Ref. [45]); and "Interface to Centralized Voice Messaging

System" (810034.0) (Ref. [46]).

7.5.1.1 User Description

Voice Messaging Systems (VMS) are becoming a fundamental component of corporate telecommunications

networks. ISDN services and products must be capable of interfacing with these units while providing as good or better service than is available today. North American ISDN User's Forum "users" have submitted

ISDN applications requiring an ISDN application that provides the capability for integrating VMS with

ISDN service.

VMS allows automatic telephone coverage without the need for individual station equipment (i.e., answering

machines) or full-time monitoring by other personnel (i.e., secretaries). VMS can also provide the

functionality for voice mail where callers may leave voice messages for others without directly calling the

others. A third function for VMS is call prompting which provides callers with additional information

before selecting various options processed by the VMS. Call Prompting goes beyond the scope of this document.

Calls to VMS subscribers' telephones are redirected by the ISDN switch (Telco central offices or PBXs)

to the VMS with sufficient information for the VMS to efficiently handle the call. Calls can be redirected

several ways - the VMS subscriber can "call forward all calls" to the VMS (CPU - Call Forward

Unconditional); calls with no answer can be call forwarded (CFNR - Call Forward No Reply); and calls to a busy telephone can be call forwarded (CFB - Call Forward Busy). In the case of voice mail, the VMS

subscriber directly calls the VMS to leave messages rather than being call forwarded by the ISDN switch.

Calling parties select options provided by call prompting (i.e., redirecting to another telephone by the ISDN

switch, redirected to another VMS subscriber's mailbox by the VMS).

The VMS must be able to receive and store the message in the appropriate VMS subscriber's mailbox and

in turn alert the VMS subscriber that a message is waiting by activating some type of message waiting

indicator (MWI) (i.e., lamp, display, interrupted dial tone). Future functions may allow the VMS to include

the calling I.D. or name, an urgent indication, etc., in the message waiting notification. The VMS should

be capable of serving both ISDN and non-ISDN subscribers.

Figure 7-28 shows an overview of the user physical environment for voice messaging and answering

applications. It includes one or more ISDN switches networked together, one or more VMSs networked

together, non-VMS calling parties (analog, digital and ISDN) and VMS subscribers (analog, digital and

ISDN). The BRI and PRI ISDN interfaces should support this VMS Application Profile.

This application profile provides the descriptions necessary to meet the requirements of three NIU-Forum

user appIicaUons: "Transparent Networking of Voice Messaging Systems" (860016.0); "Interface to Voice

Messaging Systems" (860018.0); and "Interface to Centralized Voice Messaging System" (810034.0). The

profile also refers to "Secure Voice Mail" (050015.0) (Ref. [47]), "Secure E-Mail" (050014.0) (Ref. [48])

and "Secure Facsimile Transmission through ISDN" (050016.0) (Ref. [49]) although the security aspects

are not included in this profile.

NIU-Forum Agreements On ISDN 7-65
7-66 NIU-Forum Agreements on ISDN
7.5.1.2 ISDN Application Breakdown

The above user description is divided into three distinct cases based on different interactions between the

ISDN switch and the VMS user. The three cases, Call Answering, Call Answering with Call Transfer to an Attendant, and Direct Access to Voice Mail are depicted in figure 7-29. The following describes the

different interactions required between the ISDN switch, the VMS, the calling party and the called party.

7.5.1.2.1 Call Answering

The VMS function allows automatic telephone coverage without the need for individual station equipment

(i.e., answering machines) or for full-time monitoring by other personnel. Calls to the VMS subscriber's

telephone are redirected by the ISDN switch to the VMS with sufficient information for the VMS to handle

the calls. The calls may be redirected several ways: call forward all calls to the VMS; call forward calls encountering a busy status; call forward no response calls. Calls may also be call transferred to a VMS

subscriber mailbox by a third party such as a secretary or call attendant who received the initial call.

7.5.1.2.2 Call Answering With Call Transfer To An Attendant Or Pager Notification

This is similar to the above description when the initial call is call forwarded to the VMS. The VMS has

the additional feature allowing the calling party the ability to transfer out of the VMS back to an

attendant/secretary's telephone. The VMS may also allow the calling party the ability to page the desired

person. These capabilities are used for urgent or emergency calls when a message is not sufficient or

tim.ely. The caUing party may also transfer out of the VMS to make other calls.

7.5.1.2.3 Direct Access To Voice Mail

A VMS subscriber may call the VMS directly to leave messages for one or more VMS subscribers or other

VMS subscribers if networked together with the initial subscriber's VMS. The voice mail functionalities are analogous to E-mail and include the ability to edit, broadcast, save, delete and reu-ieve messages, etc.

7.5.1.3 Service Logic

Voice Messaging and Answering Applications involve combinations of three different processes: VMS

Subscriber Access, VMS Subscriber Notification and VMS Subscriber Message Retrieval. Section 7.5.1.4,

Messaging and Answering Application Processes, describes each of these processes in more detail. In a

single VMS system, the calling party accesses the VMS subscriber's mailbox and leaves a message. The

subscriber is notified that a message is waiting and then retrieves the message. The VMS subscriber's

notification is then canceled. This flow is shown in figure 7-30. The flow is basically the same in a

multiple VMS environment, except that after the calling party leaves a message, the first VMS sends the

message to the VMS subscriber's mailbox on tlie second VMS through message networking. The multiple

VMS messaging and answering applications flow is shown in figure 7-31.

7.5.1.4 Messaging And Answering Application Process

The following describes the three basic Messaging and Answering application processes in more detail: Subscriber Access, Subscriber Notification, and Subscriber Message Retrieval.

7.5.1.4.1 Subscriber Access

Subscriber access is the first stage in Messaging and Answering application process.

NIU-Forum Agreements On ISDN 7-67
7-68 NIU-Forum Agreements on ISDN
a

0

<

a

o

<I«Q

a

e

<

a

o

<

«a

(U

CO8

a

o

•Z3 _oD. <

c

•O

00a«

V3

C/3

s

00

NIU-Forum Agreements On ISDN

7-
7.5.1.4.2 Application Process Description

Subscriber access includes the steps to connect the calling party to the VMS so that a message may be

recorded and deposited in the called party's VMS subscriber mailbox. It allows the calling party to transfer

out of the VMS when desired. This occurs when the calling party desires to speak to an attendant or

secretary. When this happens, the calling party has left the Messaging and Answering applications process.

Sometimes a secretary or attendant may transfer a calling party to the VMS to leave a recorded message

for the called party. In this case, the process treats the call exactly as if the calling party called directly.

The Message Networking subprocess is optional and used only when multiple VMSs need to communicate

with each other using the ISDN network. This situation occurs in campus environments with multiple

VMSs and one ISDN switch or in inter-location environments with multiple VMSs and multiple ISDN

switches. The networking communication occurs when one VMS needs to deliver messages to another

VMS. The objective is that multiple VMSs should appear as one large VMS to the VMS subscribers.

7.5.1.4.2.1 Subscriber Access Process Alternative Architectures

A calling party may be forwarded or transferred to the VMS using one of several different service elements

including Call Forwarding Busy (CFB), Call Forwarding Variable (CFV), or Call Forwarding No Answer

(CVN). The particular service element used to establish connectivity is not critical to the Subscriber Access

stage. What is critical is that the calling party is connected to the VMS with an opportunity to leave a voice

message in the VMS subscriber's mailbox.

Figures 7-32, 7-35, 7-38, 7-41, and 7-43 show the specific physical environment for each of the three cases described in section 7.5.1.2. The various steps in each case are simplified to show typical interactions

between the calhng party and the VMS. In the real world this interaction might be more complicated. For

example, a VMS subscriber might be the calling party wishing to leave another subscriber a message and

retrieving a message on the single call.

In 7-32, 7-35, 7-38, and 7-41, Subscriber Access is defined so that all the VMS subscribers are connected

to a single ISDN switch or PBX. In the real world, however. Messaging and Answering applications will

also occur in multiple ISDN switched networks.

The Message Networking physical environment necessary to have one VMS communicate with a second

VMS is shown in figure 7-43. This environment will require multiple VMSs (possible from different

manufacturers) to forward voice mail over ISDN networks in a standard and uniform way.

7.5.1.4.2.2 Information Flow Diagrams

Information Flow Diagrams show the specific service elements necessary to complete the Messaging and

Answering application process. For example, the Information Flow Diagram for Call Answering - No

Answer is shown in figure 7-33. The Diagram for Call Forwarding - Busy or Variable is shown in figure

7-34. The remaining Diagrams for Subscriber Access are shown in figures 7-36, 7-37, 7-39, 7-40, 7-42 and

7-44.

7.5.1.4.2.3 Protocol Requirements and Application Service Element Description

The supplementary services, messages and protocol elements described below are only those required by

this profile. Other messages and protocol elements are not discussed if they are not used by the application

being described, even though they may be required for other reasons, such as routing of the call. See figures

7-32, 7-35, 7-38, 7-41, and 7-43. Please note that the required ANSI and NIUF documents will be suppUed

as they become available. NIU.xxx implies that the Messaging and Answering Profile team is requesting

the Supplementary Services Working Group to create that particular document.

7-70 NIU-Forum Agreements on ISDN
NIU-Forum Agreements On ISDN 7-71
7-72 NIU-Forum Agreements on ISDN

7-74 NIU-Forum Agreements on ISDN
NIU-Forum Agreements On ISDN 7-75
7-76 NIU-Forum Agreements on ISDN
NIU-Forum Agreements On ISDN 7-77
7-78 NIU-Forum Agreements on ISDN
NIU-Forum Agreements On ISDN 7-79
7-80 NIU-Forum Agreements on ISDN
NIU-Forum Agreements On ISDN 7-81
7-82 NIU-Forum Agreements on ISDN
NIU-Forum Agreements On ISDN 7-83
Call Setup

The call setup process is described in NIU.301 (Appendix A) and NIU.302 (Appendix B). This process is used to establish the initial call.

Call Forwarding With Associated Data

The Call Forwarding supplementary service is defined in Tl.xxx and NIU.xxx. This service supplies the

VMS with the subscriber's DN which will be used to deposit the message in the proper mailbox.

Call Setup (direct)

The call setup process is described in NIU.301 and NIU.302. This process is used to setup a call directly

to the VMS.

Call Delivery With Associated Data

The call (i.e., voice message) is delivered to the VMS using NIU.301 or NrU.302. These protocols supply

the VMS with the subscriber's DN which will be used to deposit the message in the proper mailbox.

Connectivity to Called Subscriber's Mailbox

Current protocols exist to supply connectivity between the switch and the VMS; however, when connecting

the VMS and the Switch via ISDN, the NIU.301 and NIU.302 documents are required.

Call Transfer With Associated Data

The Call Transfer supplementary service is detined in Tl.xxx and NIU.xxx. These services supply the VMS

with the subscriber's DN which will be used to deposit the message in the proper mailbox.

Call Termination

NIU.301 and NIU.302 describe the necessary terminating procedures required to release the connection

between the VMS and the Switch.

Call Termination Outside VMS/Switch

NrU.301 and NIU.302 describe the necessary terminating procedures required to release the connection

between the calling party and the Switch.

VMS Interoperability

The VMS Interoperability requirements are defined in Tl.xxx and NIU.xxx. VMS Interoperability is critical

in defining how VMSs communicate with one another.

7.5.1.4.2.4 Conformance Tests

The conformance tests to support this profile have not been written. This data will be supplied at a later

date.

7-84 NIU-Forum Agreements on ISDN
7.5.1.4.3 Subscriber Notification

The VMS Subscriber Notification is tlie second stage in the Message and Answering application process.

7.5.1.4.3.1 Application Process Description

The VMS has the capability to control the message waiting indicator (MWI) provided to the VMS

subscriber via the ISDN switch. The MWI informs the VMS subscriber the status of recorded messages

in the subscriber's mailbox. For an ISDN subscriber, the MWI may be a lamp, display or audible indication

(e.g., interrupted dial-tone). For non-ISDN subscribers, the MWI should be in the form of an audible

indication or visual indication supplied by the switch.

The MWI should be able to notify VMS subscribers when they have messages waiting and when there are no messages waiting. The terms activated and deactivated indicate which notification is being provided.

7.5.1.4.3.2 Subscriber Notification Process Alternative Architectures

VMS subscriber notification process is invoked whenever the VMS causes the ISDN network to "activate" or "deactivate" the VMS subscriber's message waiting indicator. Typically, the MWI is activated when a message is waiting and deactivated when no messages remain. However, the VMS may activate or

deactivate the MWI at other times, such as during an error recovery process or if redundant MWI activation or deactivation messages are sent.

In typical existing implementations, all of the VMS's subscribers are connected to a single ISDN switch

or PBX. The Messaging and Answering application physical environment for subscriber notification when

the VMS subscribers and the VMS are connected to a single ISDN switch, is shown in figure 7-45.

However, when a number of users in many locations subscribe to a single, centrally located VMS, then

multiple ISDN switches are involved. The VMS first notifies the ISDN switch it is directly connected to

tell the next switch (or the third, etc.) connected to the VMS subscriber to activate the VMS subscriber's

MWI. This environment is shown in figure 7-47. The same steps occur in both environments when the

VMS notifies the ISDN switch(s) to deactivate the subscriber's MWI. These environments are shown in figures 7-49 and 7-51.

7.5.1.4.3.3 Information Flow Diagrams

The Information Flow Diagrams for VMS subscriber notification are shown in figures 7-46, 7-48, 7-50 and

7-52.

7.5.1.4.3.4 Protocol Requirements and Application Service Element Description

The supplementary service. Message Waiting Indicator Control and Notification, will be the primary

requirement specification to implement the following sub-sections. See figures 7-45 through 7-51. Please

note tliat tlie required Tl.xxx and NIU.xxx will be supplied as they become available. NIU.xxx implies that

the Messaging and Answering Profile team is requesting the Supplementary Services Working Group to create the Message Waiting Indicator Control and Notification document.

Message Waiting Indicator Control Activation (VMS to Switch)

The requirements for MWI Control activation between the VMS and the Switch are in Tl.xxx and

NIU.XXX.

NIU-Forum Agreements On ISDN 7-85
7-86 NIU-Forum Agreements on ISDN
r \

CO>

II » 2

ec a

if

a. ^

^* aM u

u

3 S

= 4»

S 3

£" =^ -4> -Ml J. > " ^

2 ^

"" s 3 e ^

1 2 .= S

S3 — a. >

3

u r a ec 2i «

E ^ a 'S, e s 11a- >»

sc u

e e - 41 = it S U

;j 3

0 ^

00 5

o

E

s

CO

.2

2

QCO

c

u

.aO

3

C/3

on

c

>

•a<

c

COo

•3O

Z

C/3

Vu

3

0£

NIU-Forum Agreements On ISDN 7-87
7-88 NIU-Forum Agreements on ISDN
II

4. 2

NIU-Forum Agreements On ISDN 7-89
7-90 NIU-Forum Agreements on ISDN
NIU-Forum Agreements On ISDN

NIU-Forum Agreements On ISDN 7-93
MWI Activation (Switch to Terminal Equipment)

The requirements for MWI activation are in Tl.xxx and NIU.XXX.

MWI Control Deactivation (VMS to Switch)

The requirements for MWI Control deactivation between the VMS and the Switch are in Tl.xxx and

NIU.XXX.

MWI Deactivation (Switch to Terminal Equipment)

The requirements for MWI deactivation are in Tl.xxx and NIU.XXX.

Network Signaling Requirements

The requirements for MWI Network signaling are in Tl.xxx and NIU.XXX. These requirements are necessary for controlling the MWI for a centralized VMS. The TCAP messages are sent within the network

to control the MWI.

7.5.1.4.3.5 Conformance Tests

The conformance tests to support this profile have not been written. This data will be supplied at a later

date.

7.5.1.4.4 Subscriber Retrieval

The VMS Subscriber Retrieval process is the third stage in the Message and Answering apphcation process.

7.5.1.4.4.1 Application Process Description

When the VMS subscribers message waiting indicators show waiting messages the VMS subscribers access

the VMS directly to retrieve and process their voice messages. Once the retrieval stage is completed, the

VMS must notify the ISDN switch to deactivate the MWI.

7.5.1.4.4.2 Called Subscriber Retrieval Alternative Architectures

A VMS subscriber may be connected to the VMS by several different service elements, such as Direct Call

Set-up, Call Forwarding, Call Transfer, etc. The particular service element used to establish connectivity

is not critical to the VMS subscriber retrieval stage. It is important that the VMS subscribers be connected

to the VMS with an opportunity to retrieve the messages from their mailboxes.

The Message and Answering physical environments for when the VMS subscribers and VMS are connected

to the same ISDN switch is shown in figure 7-53.

7.5.1.4.4.3 Information Flow Diagrams

The Information Flow from VMS subscriber access into a VMS is shown in figure 7-54.

7-94 NIU-Forum Agreements on ISDN
NIU-Forum Agreements On ISDN 7-95
7-96 NIU-Forum Agreements on ISDN
7.5.1.4.4.4 Protocol Requirements and Application Service Element Description

The protocol requirements and application service elements necessary for subscriber retrieval are a subset

of those in section 7.5.1.4.2.3.

Call Setup (Direct)

See section 7.5.1.4.2.3.

Call Delivery With Associated Data

See section 7.5.1.4.2.3.

Connectivity to Called Subscriber's Mailbox

See section 7.5.1.4.2.3.

Call Termination

See section 7.5.1.4.2.3.

7.5.1.4.4.5 Conformance Tests

The conformance tests to support this profile have not been written. This data will be supplied at a later

date.

7.5.1.4.5 Summary of MA processes

See Table 7-17.

NIU-Forum Agreements On ISDN 7-97
in3

5

on > 5 ^ ^

— c/3

*

's s = S .O E

c <^ ^ H

g 73 S ^

so

c

u

o ^ « 5

c/D > e

co

o

c

a

o

z

c

>

•ao

<I Q

co

•a

<s _>

o

<

o -a

00 co alliri •a c c

>

.2? cti

UI3JI <

5 < ^ ^ 5

7 :^ « ^

o

<

'B

JO3

0/J <

o

o 5•

«

^ c«

00 Q ^

(/I

-a -a

.2 ^

n Ui X C 9^ > w 3 of1 ^ § S

c I H S

5

3 T3 Q

o

o

5 i I

<u a Q .>; g o

i=! 5 3 -a ^ = J? O "S

3

on

^ Q

2

co

•a

COa

Q

a

u

u

-a -a

o

o

<

X

a =^ R 5 -§ £

° "a

-au

onWon

onW

o

onWon<

60C

a ^<

-au

60C

•c

1/3 c< -au

(/J

<

Q

2 <uo

>

98 NIU-Forum Agreements on ISDN
7.6 Future Bandwidth Negotiation

Editor's Note: This section is reserved for future agreements on Bandwidth Negotiation.

NIU-Forum Agreements On ISDN 7-99
7.7 Network Management/ISDN Administration

Editor's Note: This section is reserved for future agreements on Network Management/ISDN

Administration.

7.7.1 ISDN Station Event Recording (ISER)

7.7.1.1 Basic Description

ISDN (and non-ISDN) users require detailed records of station events in a universal format independent

of the switching element.

The expected benefits of this application are:

• Standard format for ISDN station event data

• Standard protocol for data ttansfer

• User-selectable interface

• Flexibility with regard to the data transferred

• Improved ability to process the data

This application (Ref. [50]) involves standardizing the information content and format of information

provided to the user as well as providing a standard interface from which the user obtains the data. This interface is defined as "A" in figure 7-55.

The user has the ability to retrieve the data in a uniform manner. The retrieval method preserves the

integrity and completeness of the data.

This application involves primarily the accounting management functional area of OSI network

management.

The intention of this application is to be able to provide data for an event from its originating station to

its terminating station including all intermediate switching nodes as required by the ISER user.

7.7.1.2 Functional Requirements

The ISDN Station Event Recording Module (ISERM), is a managed object for formatting, recording,

and retrieving user data from the ISDN environment. The ISERM includes the following attributes:

• Standard Interface Protocol

• ISER Configuration Profile

• Standard ISER Data Delivery Format

- Minimum Data Set for Event Recorded Information

7-100 NIU-Forum Agreements on ISDN
NIU-Forum Agreements On ISDN
7.7.1.2.1 Standard Interface Protocol

A standard interface is provided to allow the user device (OSI agent) to establish a connection to the

ISDN environment for ISER activities. Any such interface has the capability to establish a 2-way

communications link (full duplex) between the user device and the ISDN environment using managed

objects.

This connection uses a standard protocol which faciUtates the orderly and efficient transfer of ISER data

from the ISDN environment to the user's device(s). This protocol provides the following minknum

capabilities:

• The ability to request the ISERM to perform the transfer of ISER data from the ISDN

environment to user's devices.

• The ability to access an ISER Standard Configuration profile for the purpose of reviewing

and changing its current information.

• The ability to establish and maintain a secure user environment for the purpose of restricting

control and access to the ISERM.

In order to support this application, the protocol suites shown in figures 7-56 and 7-57 are to be

considered as suggested implementation alternatives.

ISER implementation should not preclude future TP (Distributed Transaction Processing) protocol

support for this application. See figures 7-58 and 7-59 for suggested implementation alternatives once TP has been made to accepted standard.

7.7.1.2.2 ISER Configuration Profile

A configuration profile will exist in the ISDN environment for each user for the purpose of controlling

and downloading ISER data to the user's external device(s). This configuration profile is the minimum

subset of the management data base for the managed object, ISERM, and its processes required to

interact with the external device(s).

7-102 NIU-Forum Agreements on ISDN
ISO 8571

Application FTAM

ACSE

Presentation

ISO 8822-25

Kernel

Session ISO 8326, 8327

Kernel

Transport ISO 8602, 8072, 8073

Network X.25 PLP

Data Link LAPB

Physical V.35/RS232-C/RS-449

Figure 7-56. FTAM NON-ISDN Protocol Usage for Universal ISER Application.

ISO 8571

Application FTAM

ACSE

Presentation

ISO 8822-25

Kernel

Session ISO 8326, 8327

Kernel

Transport ISO 8602, 8072, 8073

Network

T1.607, T1.608, T1.610/

NIU 301, NIU 302, NIU 320

Data Link T1.602/NIU 210

Physical T1.601, T1.605/NIU 101, NIU 105

Figure 7-57. FTAM ISDN Protocol Usage for Universal ISER Application.

NIU-Forum Agreements On ISDN 7-103
Application

Presentation

Session

Transport

Network

Data Link

Physical

ISO 8571

TP CCR

ACSE TPSE

ISO 8822-25

Kernel

ISO 8326, 8327

Kernel

ISO 8602. 8072, 8073

X.25 PLP

LAPB

V.35/RS232-C/RS-449

Figure 7-58. TP Non-ISDN Protocol Usage for Universal ISER Application.

Application

Presentation

Session

Transport

Network

Data Link

Physical

ISO 8571

TP TPSE

ACSE CCR

ISO 8822-25

Kernel

ISO 8326, 8327

Kernel

ISO 8602, 8072, 8073

T1.607, T1.608, T1.610/

NIU 301, NIU 302, NIU 320

T1.602/NIU 210

T1.601, T1.605/NIU 101, NIU 105

Figure 7-59. TP ISDN Protocol Usage for Universal ISER Application.

7-104 NIU-Forum Agreements on ISDN
At a minimum, this profile allows:

7.7.1.2.2.1 Event record selection based on:

• Event classes

- Station-to-station

- Message network access

- Private facility access

• Event types

- All attempts

- All completions

- Answered only

• Event category

- Originating

- Terminating

7.7.1.2.2.2 Access control based on:

• Set of actions

- Interface protocol

- Interface speed

• Set of constraints

- Authorized users

7.7.1.2.2.3 User identification based on:

• Unique identification assigned to each ISER user (User Identifier in ISER record)

7.7.1.2.3 Standard ISER Data Delivery Format

A standard deHvery format is established that allows the user to receive ISER data in a form that is consistent in format and content. An implementation agreement should be established for the specific

contents of each data segment and the grouping of those segments into standard ISER records.

The following is the required minimum set of event data that should be included, as applicable, for an

event.

- Numbers of simultaneous users

- Restticted actions

Item Description

Network Element Identifier Switch Identification

User Identifier User Identification

Group Identifier Customer Identifier

Record Type Identifies the Event Record Content and Format,

e.g., Originating, Terminating, etc.

NIU-Forum Agreements On ISDN 7-105
Item Description

Service Identification

Event Type

Event Category

Event Class

Originating Number

Route Information

Originating Type

Originating Trunk

Group/Member

Call Complete Code

Facility Restriction Level

Terminating Number

SPED

Terminating Type

Terminating Trunk

Group/Member

Event Start Time

(Time of Day)

Call Duration

Digits Dialed

Digits Outpulsed

Authorization Code

Account Code

Volume of Packet Data

Both In/Out

Network User Identification

(NUI)

Billing Number

Type of Service Provided:

Circuit-Switched Voice (CSV),

Circuit-Switched Data (CSD),

Packet-Switched Data (PSD)

Telephone Number plus Routing Digits (DNIC, etc.)

ARS (Automatic Route Selection) Pattern Group

Station, Attendant, Trunk (Virtual and Physical),

Offnet Line, Offtiet Trunk, Foreign Exchange, other

Onnet/Offtiet, Shared Directory Number

Private Trunk Group and Member Number

Answered, Unanswered, Busy, Abandoned,

Attendant Extended

Privilege Class Level

Telephone Number (DNIC, etc.)

Station Profile Identification

Station, Attendant, Trunk, (Virtual and Physical),

Offnet Line, Offnet Trunk, Foreign Exchange, other

Onnet/Offtiet, Shared Directory Number

Private Trunk Group and Member Number

Julian Date, Hours, Minutes, Seconds, and Tenths

Answer Time if Answered, End of Dial Time if Unanswered

Usage Time in Seconds and Tenths

Digits actually Dialed by User

Digits actually Transmitted over the Network

Used to Define Privilege Level

Used to assign Charges to a particular Account

Number of octets Transferred

Identify Users for Billing Purposes

To cause Charging and Acceptance for Packet Calls,

if Subscribed

7-106 NIU-Forum Agreements on ISDN
Item Description

Service Identification

Event Type

Event Category

Event Class

Originating Number

Route Information

Originating Type

Originating Trunk

Group/Member

Call Complete Code

Facility Restriction Level

Terminating Number

SPID

Terminating Type

Terminating Trunk

Group/Member

Event Start Time

(Time of Day)

Call Duration

Digits Dialed

Digits Outpulsed

Authorization Code

Account Code

Volume of Packet Data

Both In/Out

Network User Identification

(NUI)

Billing Number

Type of Service Provided:

Circuit-Switched Voice (CSV),

Circuit-Switched Data (CSD),

Packet-Switched Data (PSD)

Telephone Number plus Routing Digits (DNIC, etc.)

ARS (Automatic Route Selection) Pattern Group

Station, Attendant, Trunk (Virtual and Physical),

Offnet Line, Offnet Trunk, Foreign Exchange, other

Onnet/Offnet, Shared Directory Number

Private Trunk Group and Member Number

Answered, Unanswered, Busy, Abandoned,

Attendant Extended

Privilege Class Level

Telephone Number (DNIC, etc.)

Station Profile Identification

Station, Attendant, Trunk, (Virtual and Physical),

Offnet Line, Offnet Trunk, Foreign Exchange, other

Onnet/Offnet, Shared Directory Number

Private Trunk Group and Member Number

Julian Date, Hours, Minutes, Seconds, and Tenths

Answer Time if Answered, End of Dial Time if Unanswered

Usage Time in Seconds and Tenths

Digits actually Dialed by User

Digits actually Transmitted over the Network

Used to Define Privilege Level

Used to assign Charges to a particular Account

Number of octets Transferred

Identify Users for Billing Purposes

To cause Charging and Acceptance for Packet Calls,

if Subscribed

NIU-Forum Agreements On ISDN

8 References

8.1 ANS documents

[I] ANS Tl.l 1 1-1988, Telecommunications —Signalling System Number 7 (SS7) —Message Transfer

Part (MTP).

[2] ANS Tl.l 12-1988, Telecommunications — Signalling System Number 7 (SS7) — Signalling

Connection Control Part (SCCP).

[3] ANS Tl.l 13-1988, Telecommunications — Signalling System Number 7 (SS7) — ISDN User Part

(ISUP).

[4] ANS Tl.l 14-1988, Telecommunications — Signalling System Number 7 (SS7) — Transactions

Capability Application Part (TCAP).

[5] ANS Tl. 115-1989, Telecommunications — Signalling System Number 7 (SS7) — Monitoring and

Measurements.

[6] ANS Tl. 116-1989, Telecommunications — Signalling System Number 7 (SS7) — Operations,

Maintenance, Administration and Provisioning (OMAP).

[7] ANS Tl.216-1991, ISDN Management — Basic Rate Physical Layer.

[8] ANS Tl .2 17- 1991, ISDN Management — Primary Rate Physical Layer.

[9] ANS Tl.218-1991, ISDN Management — Data Link and Network Layers.

[10] ANS Tl.403-1989, Telecommunications — Carrier to Customer Installation — DSI Metallic

Interface.

[I I] ANS Tl .408-1990, Telecommunications — Integrated Services Digital Network (ISDN) — Primary

Rate — Customer Installation Metallic Interfaces — Layer I Specification.

[12] ANS Tl.601-1988, Telecommunications — Integrated Services Digital Network (ISDN) — Basic

Access Interface for Use on Metallic Loops for Application on the Network Side of the NT-Layer

I Specification.

[13] ANS Tl.602-1989, Telecommunications — Integrated Services Digital Network (ISDN) — DataLink Layer Signalling Specification for Application at the User-Network Interface.

[14] ANS Tl.603-1990, Telecommunications —Integrated Services Digital Network (ISDN) —Minimal

Set of Bearer Services for the Primary Rate Interface.

[15] ANS Tl .604-1990, Telecommunications —Integrated Services Digital Network (ISDN) —Minimal

Set of Bearer Services for the Basic Rate Interface.

[16] ANS Tl.605-1989, Telecommunications — Integrated Services Digital Network (ISDN) — Basic

Access Interface at S and T Reference Points — Layer 1 Specification.

NIU-Forum Agreements On ISDN 8-1
[ 1 7] ANS Tl .607- 1990, Telecommunications —Integrated Services Digital Network (ISDN) —Digital

Subscriber Signalling System Number I (DSSI) — Layer 3 Signalling Specification for CircuitSwitched Bearer Service.

[ 1 8] ANS Tl .608- 1990, Telecommunications —Integrated Services Digital Network (ISDN) —Digital

Subscriber Signalling System Number I (DSSI) — Signalling Specification for X.25 PacketSwitched Bearer Service.

[19] ANS Tl.609-1990, Telecommunications — Integrated Services Digital Network (ISDN) —

Interworking between the ISDN User-Network Interface Protocol and the Signalling System

Number 7 (SS7) ISDN User Part.

[20] ANS Tl.610-1990, Telecommunications —Integrated Services Digital Network (ISDN) —Digital

Subscriber Signalling System Number I (DSSI) — Generic Procedures for the Control of ISDN

Supplementary Services.

[21] ANS Tl.612-1990, Telecommunications —Integrated Services Digital Network (ISDN) —Terminal

Adaptation Using Statistical Multiplexing.

[22] TlSl.2/92-185 (TIS 1.2/90-030), Supplementary Service — Normal Call Transfer Stage 1, 2 and

3.

[23] TlSl/92-629 (TBATl.626-1992), Draft Proposed American National Standard- Switch-Computer

Applications Interface (SCAI).

8.2 CCITT Documents

[24] CCITT Recommendation 1.431-1988, ISDN Primary Rate User-Network Interface — Layer 1

Specification.

[25] CCITT Recommendation Q.921-1988 (also designated CCITT Recommendation 1.441-1988), ISDN

User-Network Data Link Layer Specification.

[26] CCITT Reconmiendation Q.93 1-1988 (also designated CCITT Recommendation 1.45 1-1988), ISDN

Primary Rate User-Network Interface — Layer 3 Specification.

[27] CCITT Recommendation V.120-1988, Support by an ISDN of Data Terminal Equipment with Vseries Type Interfaces with Provision for Statistical Multiplexing.

[28] CCITT Recommendation X.25-1984, Interface between Data Terminal Equipment (DTE) and Data

Circuit-Terminating Equipment (DCE)for Terminals Operating in the Packet Mode and Connected

to Public Data Networks by Dedicated Circuit.

[29] CCITT Recommendation X.31-1988, Support of Packet Mode Terminal Equipment by an ISDN.

[30] CCITT Recommendation 1.231-1988, Circuit-Mode Bearer Service Categories.

[31] CCITT Recommendation 1.232-1988, Packet-Mode Bearer Services Categories.

NIU-Forum Agreements on ISDN
21 8.3 NIU-Forum Documents

[32] NIU Publication 1, North American ISDN Users' Forum (NIU-Forum) Working Agreements for

the Integrated Services Digital Network (ISDN), 01 June 1990.

[33] NIU 90-002 (NIU/IIW/ICOT/90-40), Integrated Services Digital Network (ISDN) Conformance

Testing, Layer 1 Basic Rate S/T Interface, User Side, 1990.

[34] NIU 91-007 (NIU/IIW/ICOT/ACT23/9 1-22.2 V1.2), Integrated Services Digital Network (ISDN)

Conformance Testing, Layer 2 Basic Rate Interface, Link Access Procedure, D-channel (LAPD),

User side, 1991.

[35] NIU-Forum User Application Requirements Data Form 810004, "Data Conferencing (Point to Point)."

[36] NIU-Forum User Application Requirements Data Form 810005, "Database Information to Corporate Security."

[37] NIU-Forum User Application Requirements Data Form 840023, "New Account Customer Inquiry

Handling."

[38] NIU-Forum User Application Requirements Data Form 840024, "Customer Service Call Handling

(Incoming Call Management)."

[39] NIU-Forum User Application Requirements Data Form 840025, "Automatic Callback for

Financial Services."

[40] NIU-Forum User Application Requirements Data Form 830008, "Asynchronous to SNA/SDLC."

[41] NIU-Forum User Application Requirements Data Form 830(X)9, "Synchronous Terminal to Controller."

[42] NIU-Forum User Application Requirements Data Form 960009, "Asynchronous Access to Host

Computer."

[43] NIU-Forum User Application Requirements Data Form 83(X)13, "Building Controls."

[44] NIU-Forum User Apphcation Requirements Data Form 860016, "Transparent Networking of

Voice Messaging Systems."

[45] NIU-Forum User Application Requirements Data Form 860018, "Interface to Voice Messaging

Systems."

[46] NIU-Forum User Application Requirements Data Form 810034, "Interface to Centralized Voice

Messaging System."

^'These documents are available by contacting the NIU-Forum Administrator, NIST, Building 223,

Room B364, Gaithersburg, MD 20899.

NIU-Forum Agreements On ISDN 8-3
[47] NIU-Forum User Application Requirements Data Form 050015, "Secure Voice Mail."

[48] NIU-Forum User Application Requirements Data Form 050014, "Secure E-Mail."

[49] NIU-Forum User Application Requirements Data Form 050016, "Secure Facsimile

Transmission through ISDN."

[50] NIU-Forum User Applicadon Requirements Data Form 960029, "ISDN Station Event

Recording (ISER)."

8.4 Other Documents

[51] NIST Special Publication 500-195, North American ISDN Users' Forum Agreements on

Integrated Services Digital Network, September 1991.

[52] NIST Special Publication 500-183, Stable Implementation Agreements for Open Systems

Interconnection Protocols, Version 5, Edition 1, December 1991.

[53] NIST Special Publication, Application Software Interface Part 1: Overview and Protocols,

September 1991.

[54] ISO 9646, Information Processing Systems, OSI Conformance Testing Methodology and

Framework. Parts 1-5, 1989.

8-4 NIU-Forum Agreements on ISDN
APPENDIX A.

NIU 90-301

Implementation Agreement

of the North American ISDN Users' Forum

Layer 3 Signalling Specification for the

Minimal Set of Circuit-Switched Bearer Services for

the ISDN Basic Rate Interface/Class I.

Baseline Text

American National Standard Tl.607-1990:

Integrated Services Digital Network (ISDN) —

Layer 3 Signalling Specification for

Circuit-Switched Bearer Service for

Digital Subscriber Signalling System Number 1 (DSSl).

Base Standards

CCITT Recommendation Q.931 (1988):

ISDN User-Network Interface Layer 3 —

Specification For Basic Call Control.

ANSI Tl.607-1990

ANSI T1.604*:

Integrated Services Digital Network (ISDN) —

Minimal Set of Bearer Services for

the Basic Rate Interface.

A.l Abstract

This Implementation Agreement specifies procedures for establishing, maintaining, and clearing connections at the

Integrated Services Digital Network (ISDN) user-network interfaces and are mandatory for the support of the minimal

set of circuit-switched bearer services specified by ANSI Tl .604-1990' Integrated Services Digital Network (ISDN) — Minimal Set of Bearer Services for the Basic Rate Interface, (Ref [15]). Procedures for circuit-mode digital,

circuit-mode speech and circuit-mode voiceband data bearer services are as specified in the baseline text ANS

Tl .607-1990, Integrated Services Digital Network (ISDN) —Digital Subscriber Signalling System Number 1 (DSSl) — Layer 3 Signalling Specification for Circuit-Switched Bearer Service, (Ref [17]) as further resolved by this agreement. The packet-mode data service is included in this document as a bearer service. Procedures for the

packet-mode bearer service will be detailed in another document.

'Subject to further discussion.

NIU-Forum Agreements On ISDN A-1
A.2 Introduction

The original implementation agreement (NIU 90-301) was reached by marking up the text of ANS Tl.607-1990,

(Ref. [17]) to reflect the clarifications of text and selection of options. This appendix translates the implementation

agreement markup into a listing of these clarifications and selections, (i.e., this appendix lists the differences (the

"delta") between the implementation agreement marked up ANS Tl.607-1990, and the original text of ANS T1.607-

1990).

A.3 NIU 90-301 Delta List"

The lA has adopted the ANS Tl.607-1990'" (Ref. [17]) standard with the following clarifications of the text, and

selection of options:

ANS Tl.607-1990

SECTION/TABLE NUMBER/NAME

Section 1 General

Section 1.1 Scope and Purpose

Section 2.2

States associated with the global reference

call

Section 3

Message functional definition and content

Item (b), Subitem (2)

Section 3.1

Messages for circuit-mode connection control

Table 1 — Messages for circuit-mode connection

control

Section 3.1

Messages for circuit-mode connection control

Table 1 — Messages for circuit-mode connection

control

IMPLEMENTATION AGREEMENTS - CLARIFICATION OF TEXT AND

SELECTION OF OPTIONS

Delete "1. General" heading.

Replace this section with Attachment A of this document.

Delete this section including subsections.

Delete last sentence from the Note: "Annex D

contains a description of the information element

usage for symmetric NT2-NT2 interfaces."

Change "NOTIFY 3.1.7" to "*NOTIFY".

Add the following footnote below table 1: "* See

section 5.8.4 for treatment of this message."

"Note that this Delta List was developed in "good faith" by NIST as a simple equivalent representation of the

actual agreements. It has been reviewed and approved by the editors of the Signalling Working Group as per

recommendation of the Executive Steering Committee.

"'This documents can be purchased from: American National Standards Institute, 1 1 West 42nd Street, New

York, NY 10036.

^.2 NIU-Forum Agreements on ISDN
Section 3.1.1

ALERTING

Table 2 — ALERTING message content

Section 3.1.1

ALERTING

Table 2 — ALERTING message content

Section 3.1.1

ALERTING

Table 2 — ALERTING message content

Section 3.1.1

ALERTING

Table 2 — ALERTING message content

Section 3.1.1

ALERTING

Table 2 — ALERTING message content

Section 3.1.1

ALERTING

Table 2 — ALERTING message content

Section 3.1.1

ALERTING

Table 2 — ALERTING message content

Section 3.1.1

ALERTING

Table 2 — ALERTING message content

Section 3.1.1

ALERTING

Table 2 — ALERTING message content

Section 3.1.2

CALL PROCEEDING

Table 3 — CALL PROCEEDING message content

Section 3.1.2

CALL PROCEEDING

Table 3 — CALL PROCEEDING message content

Section 3.1.2

CALL PROCEEDING

Table 3 — CALL PROCEEDING message content

Section 3.1.2

CALL PROCEEDING

Table 3 — CALL PROCEEDING message content

Change the "Call Reference/Length" cell from "2-*"

to "2-3".

Change the "Channel Identification/Direction" cell from "both (Note 1)" to "u -> n".

Change the "Channel Identification/Length" cell from

"2-*" to "2-3".

Change the "Progress Indicator/Direction" cell from

"both" to "n -> u".

Change the "Progress Indicator/Length" cell from

"2-4" to "2,4".

Delete "Display" row.

Delete Notes 1, 4, 5.

Delete the last sentence from Note 3.

Change Note "6 Included if the network optionally

provides additional information describing tones." to "6 The network will always provide this IE."

Change the "Channel Identification/Length" cell from

"2-*" to "2-3".

Delete reference to "Note 2" in the "Progress

indicator/Type" cell.

Change the "Progress Indicator/Length" cell from

"2-4" to "2, 4".

Delete "Display" row.

NIU-Forum Agreements On ISDN A-3
Section 3.1.2

CALL PROCEEDING

Table 3 — CALL PROCEEDING message content

Section 3.1.3

CONNECT

Table 4 — CONNECT message content

Section 3.1.3

CONNECT

Table 4 — CONNECT message content

Section 3.1.3

CONNECT

Table 4 — CONNECT message content

Section 3.1.3

CONNECT

Table 4 — CONNECT message content

Section 3.1.3

CONNECT

Table 4 — CONNECT message content

Section 3.1.3

CONNECT

Table 4 — CONNECT message content

Section 3.1.3

CONNECT

Table 4 — CONNECT message content

Section 3.1.3

CONNECT

Table 4 — CONNECT message content

Section 3.1.3

CONNECT

Table 4 — CONNECT message content

Section 3.1.4

CONNECT ACKNOWLEDGE

Table 5 — CONNECT ACKNOWLEDGE message

content

Delete Notes 2, 3, 4.

Change the "Call Reference/Length" cell from "2-*"

to "2-3".

Change the "Channel Identification/Direction" cell from "both (Note 1)" to "u -> n (Note 1)".

Change the "Channel Identification/Length" cell from

"2-*" to "3".

Change the "Progress indicator/Direction" cell from

"both" to "n -> u".

Change the "Progress Indicator/Length" cell from "2-

4" to "2. 4".

Delete the following rows:

• "Display";

• "Connected number";

• "Connected subaddress";

• "Low Layer compatibility".

Change Note 1 from "Included in the network-to-user

direction for support of the procedures in Annex D."

to "The coding of this IE should be always 'Exclusive

B'."

Delete the following from Note 3: "or in connection

with the provision of in-band tones and patterns."

Delete Notes 4, 5, 7, 8. 9.

Change the "Call Reference/Length" cell from "2-*"

to "2-3".

A-4 NIU-Forum Agreements on ISDN
Section 3.1.4 Delete "Display" row. CONNECT ACKNOWLEDGE

Table 5 — CONNECT ACKNOWLEDGE message

content

Section 3.L4 Delete Notes \, 2. CONNECT ACKNOWLEDGE

Table 5 — CONNECT ACKNOWLEDGE message

content

Section 3.L4

CONNECT ACKNOWLEDGE

Table 5 — CONNECT ACKNOWLEDGE message

content

Section 3.L5

DISCONNECT

Table 6 — DISCONNECT message content

Section 3.1.5

DISCONNECT

Table 6 — DISCONNECT message content

Section 3.1.5

DISCONNECT

Table 6 — DISCONNECT message content

Change Note 3 from "Included if the network

optionally provides additional information describing

tones." to "Included if the network is required to turn Alerting off."

Change the "Call Reference/Length" cell from "2-*"

to "2-3".

Change the "Cause/Length" cell from "4-32" to "4-

10".

Delete the following rows:

• "Display";

• "Connected Number";

• "Connected subaddress".

Section 3.1.5

DISCONNECT

Table 6 — DISCONNECT message content

Section 3.1.5

DISCONNECT

Table 6 — DISCONNECT message content

Section 3.1.6

INFORMATION

Table 7 — INFORMATION message content

Section 3.1.6

INFORMATION

Table 7 — INFORMATION message content

Section 3.1.6

INFORMATION

Table 7 — INFORMATION message content

Section 3.1.6

INFORMATION

Table 7 — INFORMATION message content

Delete Notes 1, 2, 4, 5.

Change Note 3 to: "Included if the network must

turn tones on or off, or turn ALERTING off."

Change the "Call Reference/Length" cell from

"2-*" to "2-3".

Delete "Display" row.

Change the "Keypad Facility/Length" cell from

"2-34" to "3-34".

Delete Notes 2, 3.

NIU-Forum Agreements On ISDN A-5
Section 3.1.6

INFORMATION

Table 7 — INFORMATION message content

Section 3.1.6

INFORMATION

Table 7 — INFORMATION message content

Add the following to the end of Note 4 ("The Keypad

facility information element..."): "When INFO is sent u -> n, this IE must be present."

Change Note 5 from "Included if the network

optionally provides additional information describing

tones." to "Included if the network is required to turn tones off."

Section 3.1.7

NOTIFY

Section 3.1.8

PROGRESS

Table 9 — PROGRESS message content

Section 3.1.8

PROGRESS

Table 9 — PROGRESS message content

Section 3.1.8

PROGRESS

Table 9 — PROGRESS message content

Section 3.1.8

PROGRESS

Table 9 — PROGRESS message content

Section 3.1.8

PROGRESS

Table 9 — PROGRESS message content

Section 3.1.8

PROGRESS

Table 9 — PROGRESS message content

Section 3.1.8

PROGRESS

Table 9 — PROGRESS message content

Section 3.1.9

RELEASE

Table 10 — RELEASE message content

Delete this section.

Change "Direction" in table header from "both" to "n -> u".

Change the "Direction" cell in the following rows

from "both" to "n -> u":

• "Protocol discriminator";

• "Call reference";

• "Message type";

• "Cause";

• "Progress Indicator".

Change the "Call reference/Length" cell from "2-*" to "2-3".

Change the "Cause/Length" cell from

"2-32" to "2,4-10".

Delete "Display" row.

Delete Notes 2, 3.

Change Note 4 from "Included if the network

optionally provides additional information describing

tones." to "Included when tones or some

announcement are provided in-band."

Change the "Call reference/Length" cell from "2-*"

to "2-3".

A-6 NIU-Forum Agreements on ISDN
Section 3.1.9

RELEASE

Table 10 — RELEASE message content

Section 3.1.9

RELEASE

Table 10 — RELEASE message content

Section 3.1.9

RELEASE

Table 10 — RELEASE message content

Section 3.1.9

RELEASE

Table 10 — RELEASE message content

Section 3.1.10

RELEASE COMPLETE

Table 1 1 —RELEASE COMPLETE message content

Section 3.1.10

RELEASE COMPLETE

Table 11 —RELEASE COMPLETE message content

Section 3.1.10

RELEASE COMPLETE

Table 1 1 —RELEASE COMPLETE message content

Change the "Cause/Length" cell from "2-32" to "2,4-

10".

Delete the following rows:

• "Display";

• "Connected number";

• "Connected subaddress".

Delete Notes 3, 4, 6, 7.

Change Note 5 from "Included if the network

optionally provides additional information describing

tones." to "Included if the. network must turn tones or Alerting off."

Change the "Call reference/LengUi" cell from "2-*" to "2-3".

Change the "Cause/Lengtii" cell from "2-32" to "2, 4-

10".

Delete the following rows:

• "Display";

• "Connected number"

• "Connected subaddress".

Section 3.1.10 Delete Notes 3, 4, 6, 7. RELEASE COMPLETE

Table 1 1 —RELEASE COMPLETE message content

Section 3.1.10

RELEASE COMPLETE

Table 1 1 —RELEASE COMPLETE message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Change Note 5 from "Included if Uie network

optionally provides additional information describing

tones." to "Included if the network is required to turn tones on or off."

Change Uie "Call Reference/Length" cell from

"2-*" to "2-3".

Delete the following rows:

• "Repeat Indicator";

• "Network-Specific Facilities";

• "Display".

NIU-Forum Agreements On ISDN A-7
Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

A-8

Delete from the "Bearer Capability/Type" cell the

reference to Note 2.

Change the "Bearer Capability/Length" cell from

"4-13" to "4-8".

Change the "Channel Identification/Length" cell from

"2-*" to "2-3".

Change the "Progress Indicator/Direction" cell from

"both" to "n -> u".

Change the "Progress Indicator/Length" cell from

"2-4" to "2,4".

Change the "Calling party number/Length" cell from

"2-*" to "2-19".

Change the "Called party address/Length" cell from

"2-*" to "2-18".

Change the "Transit Network Selection/Length" cell from "2-*" to "2-7".

Change the "Higher Layer Compatibility/Length" cell from "2-4" to "2-5".

Delete Notes 1, 2, 5, 6, 7.

Add to the end of Note 8: "The digits in this IE are 0 to 9, *, and #."

Change Note 9 from "Included if the network

optionally provides additional information describing

tones." to "The network will always provide this IE."

Add to the end of Note 13: "The network should

transport this IE transparently. This IE is optional on

the user side."

NIU-Forum Agreements on ISDN
Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.12

SETUP ACKNOWLEDGE

Table 13 — SETUP ACKNOWLEDGE message

content

Section 3.1.12

SETUP ACKNOWLEDGE

Table 13 — SETUP ACKNOWLEDGE message

content

Section 3.1.12

SETUP ACKNOWLEDGE

Table 13 — SETUP ACKNOWLEDGE message

content

Section 3.1.12

SETUP ACKNOWLEDGE

Table 13 — SETUP ACKNOWLEDGE message

content

Section 3.1.12

SETUP ACKNOWLEDGE

Table 13 — SETUP ACKNOWLEDGE message

content

Section 3.1.12

SETUP ACKNOWLEDGE

Table 13 — SETUP ACKNOWLEDGE message

content

Section 3.1.12

SETUP ACKNOWLEDGE

Table 13 — SETUP ACKNOWLEDGE message

content

Add to the end of Note 15: "The network should

transport this IE transparently. This IE is optional on

the user side. The total length is 2 to 16 octets."

Add to the end of Note 16: "The network should

transport this IE transparently. This IE is optional on

the user side."

Add to the end of Note 17: "The network will treat

this IE on sending and receiving as described in the

User-User supplementary service Implementation

Agreement."

Delete "and 7kHz audio" from Note 20.

Change the "Call Reference/Length" cell from "2-*"

to "2-3".

Change the "Channel Identification/Type" cell from

"M" to "M*".

Add the following footnote before Note 1: "* The

coding of the channel ID should always be 'Exclusive

B'."

Change the "Channel Identification/Length" cell from "3-*" to "3".

Change the "Progress Indicator/Length" cell from "2-

4" to "2,4".

Delete "Display" row.

Change Note 1 to: "The only valid value for progress

indicator is 8 (refer to section 4.5.21 octet 4).

Included in connection with the provision of in-band

information/patterns."

NIU-Forum Agreements On ISDN A-9
Section 3.1.12

SETUP ACKNOWLEDGE

Table 13 — SETUP ACKNOWLEDGE message

content

Delete Notes 2, 3.

Section 3.1.12

SETUP ACKNOWLEDGE

Table 13 — SETUP ACKNOWLEDGE message

content

Cliange Note 4 from "Included if the network

optionally provides additional information describing

tones (e.g., activate dial tone)." to "Included if the

network is required to turn on dial tone."

Section 3.1.13

STATUS

Change the first sentence from "This message is sent by the user or the network in response to a STATUS

ENQUIRY message or at any time during a call to report certain error conditions as listed in 5.8." to "This message is sent by the user in response to a STATUS ENQUIRY message sent by the network, or by either the user or the network to report certain

error conditions as Hsted in 5.8."

Section 3.1.13

STATUS

Table 14 — STATUS message content

Change the "Call Reference/Length" cell "2-*" to "2-

3".

Section 3.1.13

STATUS

Table 14 — STATUS message content

Change the "Cause/Length" cell from "4-32" to "4-

10".

Section 3.1.13

STATUS

Table 14 — STATUS message content

Delete "Display" row.

Section 3.1.13

STATUS

Table 14 — STATUS message content

Delete Notes 1, 2.

Section 3.1.14

STATUS ENQUIRY

Change "This message is sent by the user or the

network at any time to solicit a STATUS message

from the peer layer 3 entity." to "This message is sent by the network during the active state to solicit a STATUS message from the peer layer 3 entity."

Section 3.1.14

STATUS ENQUIRY

Table 15 — STATUS ENQUIRY message content

Change "Direction" in the table header from "both" to "n -> u".

Section 3.1.14

STATUS ENQUIRY

Table 15 — STATUS ENQUIRY message content

Change the "Direction" cell in the following rows

from "both" to "n -> u":

• "Protocol discriminator";

• "Call reference";

• "Message type".

A-10 NIU-Forum Agreements on ISDN
Section 3.1.14

STATUS ENQUIRY

Table 15 — STATUS ENQUIRY message content

Section 3.1.14

STATUS ENQUIRY

Table 15 — STATUS ENQUIRY message content

Section 3.1.14

STATUS ENQUIRY

Table 15 — STATUS ENQUIRY message content

Section 3.2

Messages used with the global call reference

Section 4.2

Protocol Discriminator

Section 4.2

Protocol Discriminator

Figure 2 — Protocol Discriminator

Section 4.2

Protocol Discriminator

Table 19 — Protocol Discriminator

Section 4.3

Call Reference

Section 4.3

Call Reference

Section 4.3

Call Reference

Section 4.3

Call Reference

Section 4.3

Call Reference

Section 4.4

Message Type

Table 20 — Message types

Change "Call Reference/Length" cell from "2-*" to "2-3".

Delete "Display" row.

Delete Notes 1, 2.

Delete this section including subsections.

Add the following paragraph after the second

paragraph. "The only value supported for call control

messages is described below, in Figure 2."

Change "ANSI T1.607" to "Q.931".

Change "ANSI T1.607" to "Q.931" in the row labeled

"0000 1000".

Change the first sentence of the third paragraph from

"... for a basic user-network interface, and a call reference value of two octets for a primary rate

interface." to "and a maximum of 2. The network

will send one octet call reference value (CRV) unless

all 127 available codepoints are occupied."

Delete the fourth paragraph "As a network option ... one or two octets."

Add "The Dummy Call Reference and the Global Call

Reference are not supported for BRl/Class 1 circuit- switched calls." after figure 5.

Delete the last sentence from the eighth paragraph

"The call reference ... (e.g.. Restart procedures)."

Delete Note 2 ("The numerical value ... defined in

3.2.").

Add an asterisk (*) to the beginning of the "NOTIFY"

row.

NIU-Forum Agreements On ISDN A-11
Section 4.4

Message Type

Table 20 — Message Types

Section 4.5.1

Coding Rules

Section 4.5.1

Coding Rules

Figure 7 — Formats of information elements

Section 4.5.1

Coding Rules

Table 21 — Information element identifier coding

Section 4.5.1

Coding Rules

Table 21 — Information element identifier coding

Section 4.5.1

Coding Rules

Table 21 — Information element identifier coding

Section 4.5.1

Coding Rules

Table 21 — Information element identifier coding

Section 4.5.1

Coding Rules

Table 21 — Information element identifier coding

Section 4.5.1

Coding Rules

Table 21 — Information element identifier coding

Section 4.5.1

Coding Rules

Table 21 — Information element identifier coding

Section 4.5.1

Coding Rules

Table 21 — Information element identifier coding

Section 4.5.1

Coding Rules

Table 21 — Information element identifier coding

Add as a footnote "* See section 5.8.4 for treatment

of this message type."

Delete the last 3 sentences of the fourth paragraph

"Two types of ... octet elements."

Delete Figure 7 (b). Single octet information element

format (type 2).

Delete "Repeat Indicator" row.

Delete reference to Note 6 in row "Bearer capability".

Change the "Bearer capability/max length" cell from

"13" to "8".

Change the "Cause/max length" cell from "32" to "10".

Change the "Cause/max. no. of occurrences" cell from

"3" to "2".

Change the "Channel identification/max length" cell from "(Note 4)" to "3".

Delete the following rows:

• "Network-specific facilities";

• "Notification indicator";

• "Display";

• "Connected number";

• "Connected subaddress".

Change Uie "Calling Party Number/max length" cell from "(Note 4)" to "19".

Change die "Called Party Number/max length" cell "(Note 4)" to "18".

A-12 NIU-Forum Agreements on ISDN
Section 4.5.1

Coding Rules

Table 21 — Information element identifier coding

Section 4.5.1

Coding Rules

Table 21 — Information element identifier coding

Delete reference to Note 2 in the "Transit Network

selection" row.

Change the "Transit Network selection/max length"

cell from "(Note 4)" to "7".

Section 4.5.1

Coding Rules

Table 21 — Information element identifier coding

Delete "4" from the "Transit Network Selection/max.

no. of occurrences" cell.

Section 4.5.1

Coding Rules

Table 21 — Information element identifier coding

Delete the following rows:

• "Restart indicator" and

• "Escape for extension".

Section 4.5.1

Coding Rules

Table 21 — Information element identifier coding

Section 4.5.1

Coding Rules

Figure 8 — Information element format using escape

for extension

Delete Notes 3, 4, and 6.

Delete this figure.

Section 4.5.2

Extensions of codesets

Change "T1.608" to "NIU 89-320" in the first bullet

in the fourth paragraph.

Section 4.5.2

Extensions of codesets

Change the ninth paragraph to: "Codeset 7

information elements shall be handled according to the procedures for unrecognized information elements

(see 5.8.7.1) by the first exchange."

Section 4.5.2

Extensions of codesets

Delete the tenth paragraph ("Codeset 6 ... bilateral

agreements.").

Section 4.5.3

Locking shift procedure

New codeset identification coding

Section 4.5.4

Non-locking shift procedures

Section 4.5.4

Non-locking shift procedures

Temporary codeset identification coding

Section 4.5.4

Non-locking shift procedures

Temporary codeset identification coding

Change "T1.608" to "NIU 89-320" in row "codeset

5".

Delete "(a) process the non-locking ... below." from

the second paragraph.

Change "T1.607" to "NIU 90-301" in row "codeset

0".

z

Change "T1.608" to "NIU 89-320" in row "codeset

5".

NIU-Forum Agreements On ISDN A-13
Section 4.5.5

Bearer capability

Section 4.5.5

Bearer capability

Figure 11 — Bearer capability information element

Section 4.5.5

Bearer capability

Figure 11 — Bearer capability information element

Section 4.5.5

Bearer capability

Figure 11 — Bearer capability information element

Section 4.5.5

Bearer capability

Figure 11 — Bearer capability information element

Section 4.5.5

Bearer capability

Figure 11 — Bearer capability information element

Section 4.5.5

Bearer capability

Section 4.5.5

Bearer capability

Information transfer capability (octet 3) coding

Section 4.5.5

Bearer capability

Information transfer rate (octets 4 and 4b) coding

Section 4.5.5

Bearer capability

Information transfer rate (octet 4) coding

Section 4.5.5

Bearer capability

Information transfer rate (octet 4) coding

In the second paragraph change "13 octets" to "8

octets".

Change octet 4, bit 8 from "0/1" to "1".

Delete octets

• 4a*;

• 4b*;

• 5b* Note 2;

• 5b* Note 3;

• 5c*;

• 5d*.

Change octet 5a*, bit 8 from "0/1" to "1".

Delete Notes 1, 2, and 3.

Delete "or V.120" from the end of Note 4.

Add the following after Figure 11: "Octets 6 and 7

are included for information only and shall not be

used for circuit-switched calls. The coding and

application for these octets are included in another

document."

Delete row "10001 7 kHz audio".

Change the title to "Information transfer rale (octet

4)".

Delete the following rows:

• "10011 384 kbit/s";

• "10100 1472 kbit/s (see Note 2)";

• "10101 1536 kbit/s".

Change Note 1 to: "The bearer capability is

bidirectional symmetric at the information transfer

rate specified in octet 4."

A-14 NIU-Forum Agreements on ISDN
Section 4.5.5

Bearer capability

Information transfer rale (octet 4) coding

Section 4.5.5

Bearer capability

Section 4.5.5

Bearer capability

User information layer 1 protocol (octet 5) coding

Section 4.5.5

Bearer capability

User information layer 1 protocol (octet 5) coding

Section 4.5.5

Bearer capability

User information layer 1 protocol (octet 5) coding

Section 4.5.5

Bearer capability

User information layer 1 protocol (octet 5) coding

Section 4.5.5

Bearer capability

Synchronous/asynchronous (octet 5a) coding

Section 4.5.5

Bearer capability

Synchronous/asynchronous (octet 5a) coding

Section 4.5.5

Bearer capability

Negotiation (octet 5a) coding

Section 4.5.5

Bearer capability

User rate (octet 5a) coding

Section 4.5.5

Bearer capability

Section 4.5.5

Bearer capability

Section 4.5.6

Call state Global interface state value (octet 3) coding

Delete Note 2.

Delete the codings of octets 4a (structure,

configuration, establishment) and 4b (symmetry).

Delete "and optionally octets 5b, 5c, and 5d as defined below." from row "00001".

Delete "and G.725 7 kHz audio" from row "00101".

Delete rows "00111" and "01000".

Delete Note 2.

Delete row "1 asynchronous".

Delete the second and third sentences from the Note.

Delete row "1 In-band negotiation possible".

Delete all code points except "01111 56 kbit/s

CCITT Recommendation V.6."

Delete all text relating to octet 5b (i.e., sections

labeled "Octet 5b for CCITT Recommendation V.lOO

or X.30 rate adaption" and "Octet 5b for CCITT

Reconmiendation V.120 rate adaption").

Delete all tables and text referring to octets 5c

(number of data bits excluding parity bit, parity

information) and 5d (duplex mode, modem type).

Delete this coding.

NIU-Forum Agreements On ISDN A- 15
Section 4.5.7

Called party number

Section 4.5.7

Called party number

Type of number (octet 3) coding

Section 4.5.7

Called party number

Section 4.5.7

Called party number

Numbering plan identification (octet 3) coding

Section 4.5.7

Called party number

Section 4.5.9

Calling party number

Section 4.5.9

Calling party number

Type of number (octet 3) coding

Section 4.5.9

Calling party number

Type of number (octet 3) coding

Section 4.5.9

Calling party number

Numbering plan identification (octet 3) coding

Section 4.5.9

Calling party number

Change the second paragraph to: "The maximum

length of this information element is 18 octets."

Delete the following rows:

• "Oil network specific number (see Note 4)" and

• "111 reserved for extension".

Delete Note 4.

Delete the following rows: "0011 Data numbering plan (CCFFT

Recommendation X.121)";

"0100 Telex numbering plan (CCFFT

Recommendation F.69)";

• "1111 Reserved for extension".

Add Attachment B of this document after the

following:

"Number digits (octets 4, etc.)

This field is coded with ASCII characters,

according to the formats specified in the appropriate

numbering and dialing plan."

Change the second paragraph from: "The maximum

length of this information element is network

dependent." to "The maximum length of this information element is 19 octets."

Delete the following rows:

• "Oil network specific number (see Note 4)" and

• "111 reserved for extension".

Delete Note 4.

Delete the following rows: "0100 Telex numbering plan (CCFFT

Recommendation F.69)" and

• "1111 Reserved for extension".

Add Attachment C of this document after the

following:

"Number digits (octets 4, etc.)

This field is coded with ASCII characters,

according to the formats specified in the appropriate

numbering or dialing plan."

A-16 NIU-Forum Agreements on ISDN
Section 4.5.10

Calling party subaddress

Section 4.5.11

Cause

Add a new paragraph at the end of the section: "In

the network to user direction (n —> u), the coding

and delivery of this IE depends on the definition of

the Calling Line ID service."

Change the second sentence of the first paragraph

from "The maximum length of this information

element is 32 octets." to "The maximum length of this information element is 10 octets."

Section 4.5.11

Cause

Figure 17 — Cause information element

Section 4.5.11

Cause

Figure 17 — Cause information element

Section 4.5.11

Cause

Figure 17 — Cause information element

Section 4.5.11

Cause

Reconmiendation (octet 3a) coding

Section 4.5.11

Cause

Section 4.5.11

Cause

Cause table

Change octet 3, bit 8 from "0/1" to "1".

Delete octet 3a*.

Delete the Note.

Delete this coding and its associated Notes 1 and 2.

Add the following sentence to the end of the

paragraph under "Diagnostics (octet 5)": "If more

than one IE is identified in a diagnostic, they should

be ordered as lE's normally appear in a message."

Change the "diagnostics" cell of the first three code

points to "Not used".

Section 4.5.11

Cause

Cause table

Change the "Normal call clearing/diagnostics" cell from "(see Note 12)" to "Not used".

Section 4.5.11

Cause

Cause table

Add to the "User busy/diagnostics" cell: "(see Note

10)"

Section 4.5.11

Cause

Cause table

Change the "call rejected/diagnostics" cell from "(see

Note 12, user supplied diagnostic) (see Note 4)" to "Not used".

Section 4.5.11

Cause

Cause table

Delete row "Number changed".

NIU-Forum Agreements On ISDN A-17
Section 4.5.11

Cause

Cause table

Add "(see Note 10)" to the "Network out of

order/diagnostics" cell.

Section 4.5.11

Cause

Cause table

Add "(see Note 10)" to the "Requested circuit or channel not available/diagnostics" cell.

Section 4.5.11

Cause

Cause table

Delete row "Quality of service unavailable".

Section 4.5.11

Cause

Cause table

Change the "Requested facility not subscribed/

diagnostics" cell from "Facility identification (see

Note D" to "Not used".

Section 4.5.11

Cause

Cause table

Change the "Bearer capability not authorized/

diagnostics" cell from "(see Note 3)" to "Not used".

Section 4.5.11

Cause

Cause table

Delete row "Bearer capability not presently available".

Section 4.5.11

Cause

Cause table

Delete row "Service or option not available,

unspecified".

Section 4.5.11

Cause

Cause table

Change the "Bearer capability not implemented/

diagnostics" cell from "(see Note 3)" to "Not used".

Section 4.5.11

Cause

Cause table

Delete row "Channel type not implemented".

Section 4.5.11

Cause

Cause table

Change the "requested facility no implemented/

diagnostics" cell from "Facility identification (see

Note 1)" to "Not used".

Section 4.5.11

Cause

Cause table

Delete rows "Only restricted digital information

bearer capability is available" and "Service or option

not implemented, unspecified".

SecUon 4.5.11

Cause

Cause table

Delete row "Identified channel does not exist".

Section 4.5.11

Cause

Cause table

Change the "incompatible destination/diagnostics" cell from "Incompatible parameter (see Note 2)" to "Not

used".

A-18 NIU-Forum Agreements on ISDN
Section 4.5.11

Cause

Cause table

Section 4.5.11

Cause

Cause table

Section 4.5.11

Cause

Cause table

Section 4.5.11

Cause

Figure 18 —Coding of the diagnostic field for causes

57, 58 and 65

Section 4.5.12

Channel identification

Figure 19 — Channel identification information

element

Section 4.5.12

Channel identification

Figure 19 — Channel identification information

element

Section 4.5.12

Channel identification

Interface identifier present (octet 3) coding

Section 4.5.12

Channel identification

Interface identifier present (octet 3) coding

Section 4.5.12

Channel identification

Interface type (octet 3) coding

Section 4.5.12

Channel identification

Interface type (octet 3) coding

Section 4.5.12

Channel identification

Information channel selection (octet 3) coding

Section 4.5.12

Channel identification

Delete row "Invalid message, unspecified".

Change the "Recovery on timer expiry/diagnostics"

cell from "Timer number (see Note 9)" to "Not used".

Delete Notes 2, 3, 4, 5, 7, 9, 11, 12.

Delete Figure 18 and text for octets 5, 5a, and 5b.

Delete the octets 3.1, 3.2, and 3.3.

Delete Notes 1, 2, 3, 4.

Delete row "1 Interface explicitly ... with octet 3.1."

Delete the Note and the reference to it in row "0

Interface implicitly identified".

Delete row "1 other interface: ... (see Note)".

Delete the Note.

Add the following after Note 3: "4 The combination

of 'Any Channel' (bits 1,2), and 'Exclusive' (bit 4) is

invalid."

Delete the text, codings, and figures relating to octets

3.1, 3.2, and 3.3.

NIU-Forum Agreements On ISDN A-19
Section 4.5.13

Connected Number

Delete this section.

Section 4.5.14

Connected subaddress

Section 4.5.15

Display

Section 4.5.16

High layer compatibility

Section 4.5.18

Low layer compatibility

Section 4.5.18

Low layer compatibility

Negotiation indicator (octet 3a) coding

Section 4.5.18

Low layer compatibility

Negotiation indicator (octet 3a) coding

SecUon 4.5.18

Low Layer compatibility

User information layer 3 protocol (octet 7) coding

Section 4.5.19

Network-specific facilities

Section 4.5.20

Notification Indicator

Section 4.5.21

Progress indicator

Progress description (octet 4) coding

Section 4.5.21

Progress indicator

Progress description (octet 4) coding

Section 4.5.22

Repeat indicator

Section 4.5.23

Restart indicator

Delete this section.

Delete this section.

Change the second paragraph from "The maximum

length of this information element is four octets." to "The maximum length of this information element is

five octets."

Delete the second paragraph.

Delete row "1 Out-band negotiation possible".

Delete Note 1.

Change "ANSI T1.607" to "NIU 90-301" in row

"00010".

Delete this section.

Delete this section.

Delete row "000 0100 4 call has returned to the

ISDN."

Add the following after Note 2: "3 In the SETUP

message, n -> u, one of two values may be used: 1 or

3."

Delete this section.

Delete this section.

A-20 NIU-Forum Agreements on ISDN
Section 4.5.24

Signal

Figure 32 — Signal information element

Section 4.5.24

Signal

Signal value (octet 3) coding

Section 4.5.25

Transit network selection

Section 4.5.25

Transit network selection

Section 4.5.25

Transit network selection

Type of network identification (octet 3) coding

Section 4.5.25

Transit network selection

Network identification plan (octet 3) coding

Section 4.5.26

User-user

Section 4.5.26

User-user

Protocol discriminator (octet 3) coding

Section 4.6.1

Operator system access

type of access (octet 3) coding

Section 5

Circuit-switched call control procedures

Section 5

Circuit-switched call control procedures

Section 5.1 Call establishment at the originating interface

Add below the figure: "Note In the n -> u direction,

and in the absence of supplementary services, the

public network will offer signalling pattern 0 only."

Delete the following rows:

• "intercept tone on";

• "answer tone on";

• "off hook warning tone on";

• "ALERTING on — pattern 5";

• "ALERTING on — pattern 6";

• "ALERTING on — pattern 7".

Change the second sentence of the fu-st paragraph to: "The transit network selection information element

should not be repeated in a message (See Annex C)."

Change the second paragraph to: "The default

maximum length of tliis information element is 7

octets."

Delete row "Oil international network identification".

Delete row "(X)ll Data network identification code

(CCITT Recommendation X.121)".

Add the following sentence to the end of the Note

(after the second paragraph): "This IE is included

based on user-user supplementary service description

and user application."

Change "ANSI T1.607" to "NIU 90-301" in row

"0000 1000".

Delete row "10 private/principal".

Delete the fourth paragraph ("As a general principle,

...").

Delete the last sentence of second Note ("Display

information ... network to user.").

Change "ANSI T1.602" to "NIU 89-210" in the last sentence of the first paragraph.

NIU-Forum Agreements On ISDN A-21
Section 5.1.3

Overlap sending

Section 5.1.4

Invalid call information

Section 5.1.4

Invalid call information

Add the following at the end of section 5.1.3: "However, as an option, the network can determine

that a potentially complete code has been received

following the receipt of address information, and the

network could use critical interdigit timing (instead of

T302) to determine whether additional digits are following. This timing could be 3-5 seconds. If implemented, when this timer expires, a complete

address is assumed and the procedures in Sec. 5.1.5.2

shaU be followed. In an INFORMATION message is received and the critical interdigit timing is running,

it shall be stopped."

Delete the following line from the last paragraph:

"22 'number changed'."

Add the following two paragraphs to the end of

section 5.1.4: "The network should reject the call request if the

SETUP message contains the keypad information

element, and any of the following information

elements: transit network selection, called party

number, or operator system access. In this case, the

network should send the calling user equipment a RELEASE COMPLETE message containing cause 28,

'invaUd number format (location: public network

serving the local user).'."

"If the network receives a called party number

information element containing more address digits

than expected, as determined by the 'type of number

and numbering plan identification' field, the network

should discard the superfluous digits and route the

call. Similarly, if the transit network selection

information element contains more address digits than

expected, as determined by the 'type of network

identification' and 'network identification plan' fields,

the network should discard the superfluous digits and

route the call. If the network receives a keypad

information element containing more address digits

than required for completion of digit analysis, the

network should discard the superfluous digits

(according to the network dialing plan) and route the

call. If any of these events occur, the local pubUc

network should send the calling user equipment a STATUS message containing National-specific cause

11, 'More digits received than allowed: call is proceeding (location: pubhc network serving the local

user' and the call state information element coded as

call state 1, 'call initiated.' Private networks may

support this procedure, optionally."

A-22 NIU-Forum Agreements on ISDN
Section 5.1.5.1

Call proceeding, en-bloc sending

Delete causes "58 'bearer capability not presently

available';" and "63 'service or option not available,

unspecified';" from the second paragraph.

Section 5.1.5.1

Call proceeding, en-block sending

Section 5.1.5.2

Call proceeding, overlap sending

Section 5.1.5.2

Call proceeding, overlap sending

Section 5.1.5.2

Call proceeding, overlap sending

Add to the second paragraph after "57 ... authorized":

"34 'no circuit or channel available';".

Delete "58 ...available" and "63 ... unspecified" from

the first paragraph.

Add after "57 ... not authorized": "34 'no circuit or channel available';" in the first paragraph.

Add the following at the end of section 5.1.5.2:

"Other Misdialing Treatments

The Network should be capable of recognizing several

types of misdialing. If network-provided tones and

announcements do not apply, the network should

initiate call clearing in response to a misdialing error.

If en-bloc sending has been used, the network should

send a RELEASE COMPLETE message to the calling user equipment. If overlap sending has been used, the

network should send a DISCONNECT message to the

calling user equipment. The initial clearing message

should contain the appropriate cause information, as indicated below, and the signal information 'reorder

tone on.' If tones and announcements apply, see

section 5.3.4.1. — Vacant code: National-specific cause 4,

'vacant code.' — Prefix 0 dialed in error: National-specific cause 8, 'prefix 0 dialed in error.' — Prefix 1 dialed in error: National-specific

cau.se 9 'prefix 1 dialed in error.' — Prefix 1 not dialed: National-specific cause 10, 'prefix 1 not dialed.'"

Section 5.1.6

Notification of interworking at the originating

interface

Section 5.1.6

Notification of interworking at the originating

interface

Change (a) in the first paragraph to: "In an

appropriate call control message when a state change

is required (i.e., CONNECT); or,".

Delete from the second paragraph the progress

description value "4 'call has returned to the ISDN'.

Call is now end-to-end and ISDN."

NIU-Forum Agreements On ISDN A-23
Section 5.1.7

Call confirmation indication

Section 5.2

Call establishment at the destination interface

Section 5.2

Call establishment at the destination interface

Section 5.2.1

Incoming call

Section 5.2.1

Incoming call

Section 5.2.1

Incoming call

Section 5.2.1

Incoming call

Section 5.2.2

Compatibility checking

Section 5.2.3.1

SETUP message delivered by point-to-point data link

Section 5.2.3.2

SETUP message delivered by broadcast data link

Section 5.2.5.1

Response to en-block SETUP

Section 5.2.5.1

Response to en-block SETUP

Section 5.2.5.1

Response to en-block SETUP

Section 5.2.5.3

Called user clearing during incoming call estabUshment

Change the last sentence of the first paragraph to: "When the user receives the ALERTING message, the user shall enter the Call Delivered state."

Change "ANSI standard T1.602" to "NIU 89-210" in the first sentence of the first paragraph.

Delete the third paragraph ("The SETUP message

offered ... of the data link layer.").

Delete "Display," from the second paragraph "(e.g..

Display, Low layer compatibility)."

Add the following to the end of second paragraph.

"In general, a call terminating from a non-ISDN line or from a Public Switched Telephone Network

(PSTN) trunk should be offered to the called user equipment with the 3.1. kHz audio bearer capability."

Change "(e.g., for DDI)" to "(e.g., 7 digits)" in the

second sentence of the third paragraph.

Delete the third sentence from the third paragraph.

Delete the third paragraph.

Delete this section.

Combine the first and second sentences of the first paragraph to: "When the SETUP message is delivered by a broadcast data link, the network sends a SETUP message with the Channel identification

information element indicating a specific channel with no alternative acceptable."

Delete "(see Note)" from the first sentence of the first paragraph.

Delete the Note after the first paragraph.

Delete the third paragraph ("When the SETUP

message was delivered via a point-to-point data link

...").

Delete the first paragraph.

A-24 NIU-Forum Agreements on ISDN
Section 5.2.5.3

Called user clearing during incoming call establishment

Change the second sentence of the second paragraph

to: "If timer T303 expires (i.e., if no valid message

such as CALL PROCEEDING, ALERTING, or CONNECT has been received), the network shall take

action as follows:

a. If all clearing messages received from the

called user equipment contain cause 88,

'incompatible destination,' the call should be

cleared at the calling ISDN interface with cause 18, 'no user responding (location:

public network serving the remote user)' and

signal 'ring-back/audible ringing tone on.'

b. If one or more call clearing messages

with cause 17, 'user busy,' have been

received from the called user equipment, the

call should be cleared at the calling ISDN

interface with cause 17, 'user busy (location:

user).' The signal information should be

coded as 'busy tone on' unless an audible

ringing tone was indicated because timer T

delay (if implemented) previously expired

(see sec. 5.2.1). If audible ringing is being

provided, the signal information should be

coded as 'ring-back/audible ringing tone on.'

c. If no call clearing messages with cause

17 have been received from the called user equipment and at least one call clearing

message with a cause other than 88 has been

received, the call should be cleared at the

calling ISDN interface with cause 21, 'call rejected (location: user),' and signal 'ringback/audible ringing tone on.'."

Section 5.2.5.3 Delete the last sentence from the second paragraph:

Called user clearing during incoming call "When multiple RELEASE COMPLETE ... sent to establishment the originating user (see 5.3)."

Section 5.2.5.3.1

DISCONNECT received prior to expiry of T312

Change the second sentence in the second paragraph

from "If an ALERTING message has been received,

... any other cause sent by a called user." to "If an ALERTING message has been received, the cause

sent to the calling user shall be 21 'call rejected'

(location: user)."

NIU-Forum Agreements On ISDN A-25
Section 5.2.5.3.1

DISCONNECT received prior to expiry of T312

Section 5.2.5.3.2

DISCONNECT received after expiry of timer T312

Section 5.2.5.3.2

DISCONNECT received after to expiry of T312

Section 5.2.5.4

Call failure

Section 5.2.6

Notification of interworking at the terminating

interface

Section 5.2.7

Call accept

Section 5.2.8

Active indication

Change the third sentence in the second paragraph

from "In only CALL PROCEEDING ... sent by a

called user." to "If only CALL PROCEEDING

messages have been received from called users, the cause sent to the caUing user shall be as in 5.2.5.3."

Change the second sentence in the third paragraph

from "If an ALERTING message has been received,

... any other cause sent by a called user." to "If an ALERTING message has been received, the cause

sent to the calling user shall be 21 'call rejected'

(location: user)."

Change the third sentence in the third paragraph from

"If only CALL PROCEEDING ... by a called user" to

"If only CALL PROCEEDING messages have been

received, the cause sent to the calling user shall be as

in 5.2.5.3."

Delete all occurrences of "(b) ..." (paragraphs 1, 3, 4)

from this section.

Delete this section.

Add to the end of the second paragraph: "If the

CONNECT message is the first response to the

SETUP message, it shall contain the channel ID

information element."

Delete the last paragraph of section 5.2.8 ("A user which has ... has been completed").

A-26 NIU-Forum Agreements on ISDN
Section 5.3.2

Exception conditions

Add the following before the Note that appears at the

end of this section. — In the case of a SETUP message sent to the user via the broadcast data link, if a

called user terminal sends a first response to the SETUP message after timer T303 has

expired (the first expiration of T303 is the

SETUP message should not be retransmitted,

and the second expiration of T303 if the

SETUP message should be retransmitted —

note that the SETUP message is retransmitted only when no response is received prior to the first expiry of T303,

e.g., the SETUP message should not be

retransmitted when a call clearing message(s)

is received prior to the first expiry of T303),

but before timer T312 expires, the network

should clear the call to that user by sending a RELEASE message. This message

should contain cause 102, 'recovery on timer

expiry' (location: public network serving the

local user.). — In the case of call offering via the

broadcast data link, if either timer T310 or T301 expires at the called user interface, the

network should initiate call clearing by

sending a RELEASE message to all called user equipment responding to the SETUP

message sent by the network. The

RELEASE message(s) should contain cause

102, 'recovery on timer expiry' (location:

public network serving the local user). — If a call attempt is unsuccessful and a

speech, 3.1 kHz audio call will not be

immediately cleared because inband tones or announcements are being provided, the

network should send the calling user a PROGRESS message containing progress

message containing progress indicator 8,

'inband information or appropriate pattern

now available.'."

Section 5.3.3

Clearing initiated by the user

Delete the last Note in this section.

NIU-Forum Agreements On ISDN A-27
Section 5.3.4.1

Clearing when tones or announcements provided

Section 5.3.4.3

Completion of clearing

Add the following at the end of section 5.3.4.1: "To return an inband tone for an unsuccessful speech,

3.1. kHz audio the network should send a PROGRESS message and start a tone timer (value to be specified by network provider) in anticipation of

the user initiating the clearing process. The

PROGRESS message should contain the cause value

indicated in the detailed procedures of Section 5.3,

along with progress indicator 8, 'inband information

or appropriate pattern now available.' If the tone

timer expires, the network should initiate call clearing

by sending the calling user a DISCONNECT message

containing cause 102, 'recovery on timer expiry.'

The network should then continue clearing the

connection to the calling user equipment according to the procedures for sending a DISCONNECT message.

The procedures described above also apply for returning an inband announcement for an unsuccessful

speech, 3.1 kHz audio call, with the exception that the

tone timer is not used. Inband announcements should

not be timed; however, it is desirable that the network

Delete an inband announcement after one or two

message cycles, depending on the number specified

by the network provider. In removing the inband

announcement, the network should follow the above

procedures for expiration of the tone timer."

Delete the last Note at the end of section 5.3.4.3.

Section 5.5

Restart procedure

Delete this section including all subsecfions.

Section 5.8

Handling of error conditions

Change "T1.607" to "Q.931" in the first sentence of

the first paragraph.

Section 5.8.1

Protocol discrimination error

Section 5.8.3.1

Invalid call reference format

Change "T1.607" to "Q.931" in the first sentence in the first paragraph.

Change the second paragraph to: "If the Call

reference information element octet 1, bits 1 through

4 indicates a length greater than the maximum length

supported by the receiving equipment (see 4.3), or the

Null call reference, or the global call reference is used

to identify a call, then the message shall be ignored."

Section 5.8.3.2

Call reference procedural errors

Delete item "(f) When any message ... shall be

relumed."

A-28 NIU-Forum Agreements on ISDN
Section 5.8.4

Message type or message sequence errors

Section 5.8.4

Message type or message sequence errors

Section 5.8.4

Message type or message sequence errors

Section 5.8.6.1

Mandatory information element missing

Section 5.8.6.1

Mandatory information element missing

Add as a new paragraph "A NOTIFY message may

also be ignored by the recipient." after the first paragraph (i.e., after the list of cause values).

Change the fourth sentence in the second paragraph

to: "Whenever the network receives an unexpected

RELEASE message, the network shall: disconnect and

release the B-channel; clear the network connection

and the call to the remote user with cause as specified

in 5.2.5.3, or cause in the RELEASE message sent by

the user. If no cause is included, cause 3 1 'normal,

unspecified' or other causes as specified in 5.8.6.1; return a RELEASE COMPLETE message to the user; release the call reference; stop all timers; and enter

the Null state."

Change the second sentence of the third paragraph to: "Whenever the network receives an unexpected

RELEASE COMPLETE message, the network shall: disconnect and release the B-channel; clear the

network connection and the call to the remote user with the cause indicated by the user or, if not

included, cause 111 'protocol error, unspecified' or other causes as specified in 5.8.6.1; release the call reference; stop all timers; and enter the Null state."

Change the beginning of the first sentence in the third

paragraph to: "When a DISCONNECT message (first

clearing message) is received with

Add the following as a new paragraph after the third

paragraph: "As an option the network shall follow

the following procedure. The DISCONNECT

message sent to the network should contain cause

information. If the network receives an initial clearing message without a cause information

element, it should accept the message, disconnect the

associated channel, and initiate procedures to clear the

network connection and the call to the remote user.

If the call is active or if the originating user cleared

the call while in the setup phase, the network should

send cause 16, 'normal clearing (location: user)' to the remote user. It should send cause 21, 'call rejected (location: user)' if the terminating user

cleared the call while in the setup phase. The

network should respond to the user initiating call clearing by sending a RELEASE message containing cause 96, 'mandatory information element is missing

(location: pubUc network serving the local user; diagnostic: cause information element identifier).'."

NIU-Forum Agreements On ISDN A-29
Section 5.8.6.2

Mandatory information element content error

Change the third paragraph to: "When a DISCONNECT message is received with invalid

content of the Cause information element, the action

taken shall be the same as if a DISCONNECT

message with the cause missing was received with the

exception that the RELEASE message sent on the

local interface contains cause 100 'invalid information

element contents'."

Section 5.8.7.1

Unrecognized information elements

Section 5.8.8

Data-link reset

Section 5.8.9

Data-link failure

Section 5.8.9

Data-link failure

Section 5.8.9

Data-link failure

Section 5.8.10

Status enquiry procedure

Section 5.8.11

Receiving a STATUS message

Section 5.8.11

Receiving a STATUS message

Section 5.8.11

Receiving a STATUS message

Section 5.8.11

Receiving a STATUS message

Section 5.9

User notification procedure

Add the following to the Note after the first paragraph: "or not implemented by the receiver in a

specific message."

Change "ANSI T1.607" to "NIU 90-301" in the first sentence of the first paragraph.

Change "ANSI T1.607" to "NIU 90-301" in the first sentence of the first paragraph.

Change both occurrences of "ANSI T1.607" in the

first paragraph bullet b) to "NIU 90-301".

Change the first Note after the first paragraph to: "If the transfer mode of the call is circuit-mode, the NIU

90-301 entity may clear the calls."

Delete the first paragraph.

Delete "As an option:" from the second sentence of

the third paragraph ("The determination ...").

Change "a)" in the third paragraph to: "If a STATUS

message indicating any call state except the Null state

is received in the Null state, then the receiving entity

shall send a RELEASE COMPLETE message witb a

cause 101 'message not compatible with call state' or cause 81 'Invalid Call reference value' and remain in

the Null state. Otherwise, no action shall be taken on

receipt of STATUS unless it is in response to STATUS ENQUIRY."

Delete "b) If a ..." and "c) If a STATUS message,

indicating the Null ... into the Null state." after the

third paragraph.

Delete the last three paragraphs and the last Note in

this section.

Delete this section.

A-30 NIU-Forum Agreements on ISDN
Section 6

Packet communication procedures

Change sentence to "See NIU 89-320".

Section 9.1 Change the "T302/Default time out value" cell from

Timers in the network side "10-15 s" to "16-24 s". Table 22 — Timers in the network side

Change the "T302/cause for start" ceU from "SETUP

ACKNOWLEDGE sent. Receipt of INFORMATION

restarts T302." to "SETUP ACKNOWLEDGE sent. Receipt of INFORMATION not containing complete

address information restarts T302."

Section 9.1

Timers in the network side

Table 22 — Timers in the network side

Section 9.1

Timers in the network side

Table 22 — Timers in the network side

Change the "T302/NORMAL STOP" cell to: "With

sending complete indication, or potentially complete

address information received, as an option, the

network can determine that a potentially complete

code has been received following the receipt of

address information, and the network could use

critical interdigit timing (instead of T302) to determine whether additional digits are following.

This timing could be 3-5 seconds. If implemented,

when this timer expires, a complete address is assumed and the procedures in section 5.1.5.2 shall be

followed. In an INFORMATION message is received

and the critical interdigit timing is running, it shall be

stopped."

Section 9.1

Timers in the network side

Table 22 — Timers in the network side

Add the following row entry for Timer "Tpot_comp"

after row "T302":

TIMER

NUMBER

DEFAULT

TIME

OUT

VALUE

STATE

OF

CALL

CAUSES

FOR

START

NORMAL STOP AT THE

HRST

EXPIRY

AT THE

SECOND

EXPIRY

CROSS

REFERENCE

Tpot_comp 3-5 s Overlap

Sending

Potentially

complete

address

information

received

INFORMATION

received

Route

call

Timer

not

restarted

*

* optional — as an option, the network can determine that a potentially complete code has been received following the receipt of

iddress information, and the network could use critical interdigit timing (instead of T302) to determine whether additional digits are bllowing. This timing could be 3-5 seconds. If implemented, when this timer expires, a complete address is assumed and the

•rocedures in Section 5.1.5.2 shall be followed. In an INFORMATION message is received and the critical interdigit timing is unning, it shall be stopped."

NIU-Forum Agreements On ISDN A-31
Section 9.1

Timers in the network side

Table 22 — Timers in the network side

Section 9.1

Timers in the network side

Table 22 — Timers in the network side

Section 9.1

Timers in the network side

Table 22 — Timers in the network side

Section 9.1

Timers in the network side

Table 22 — Timers in the network side

Section 9.1

Timers in the network side

Table 22 — Timers in the network side

Section 9.1

Timers in the network side

Table 22 — Timers in the network side

Section 9.1

Timers in the network side

Table 22 — Timers in the network side

Section 9.1

Timers in the network side

Table 22 — Timers in the network side

Section 9.2

Timers in the user side

Table 23 — Timers in the user side

Section 9.2

Timers in the user side

Table 23 — Timers in the user side

Section 9.2

Timers in the user side

Table 23 — Timers in the user side

Section 9.2

Timers in the user side

Table 23 — Timers in the user side

Section 9.2

Timers in the user side

Table 23 — Timers in the user side

Change the "T303/DEFAULT TIME OUT VALUE"

cell from "4s" to "2.5s".

Change the "T303/NORMAL STOP" ceU to "ALERT,

CONNECT, or CALL PROCEEDING received."

Change the "T303/AT THE RRST EXPIRY" cell to "Retransmit SETUP; re-start T303."

Delete "Note 7" from the "T308/AT SECOND

EXPIRY" ceU.

Change "10s" to "5s" in the "T310/DEFAULT TIME

OUT VALUE" cell.

Delete "Note 6" from the "T310/DEFAULT TIME

OUT VALUE" cell.

Delete the following rows: "T316", "T317", "T321".

Delete the following Notes: 3, 6, 7 at the end of

Table 22.

Change the "T301/CROSS REFERENCE" cell to "Note 3".

Change the "T303/NORMAL STOP" cell to "SETUP

ACKNOWLEDGE, CALL PROCEEDING or RELEASE COMPLETE received".

Delete "(annex D)" from the "T303/AT THE HRST

EXPIRY" cell.

Change the "T303/CROSS REFERENCE" cell to

"optional".

Delete "Note 5" from the "T308/AT THE SECOND

EXPIRY" cell.

A-32 NIU-Forum Agreements on ISDN
Section 9.2

Timers in the user side

Table 23 — Timers in the user side

Delete rows "T310", "T316", "T317", "T321".

Section 9.2

Timers in the user side

Table 23 — Timers in the user side

Delete Notes 2 and 5 that appear at the end of table

7.

Annex A Delete this section. NOTE: This section has not

been addressed.

Annex B, Section B.3.1

Compatibility checking with addressing information

Annex B, Section B.3.2

Network to user compatibility

Change the second sentence under "a)" to: "In the case of a mismatch, the user shall either ignore or

reject the call."

Change the last sentence in this section to: "If a mismatch is detected, then the user shall either ignore or reject the offered call using cause 88 'incompatible

destination'."

Annex B, Section B.3.4

User action figures

Figure B.l — Bearer capabihty compatibility

checking

Figure B.2 — Low layer and high layer compatibility

checking; compatibility assured

Figure B.3 — Low layer and high layer compatibility

checking; compatibility not assured

Annex B, Section B.3.4

User action figures

Figure B.l — Bearer capability compatibility

checking

Figure B.2 — Low layer and high layer compatibility

checking; compatibility assured

Annex B, Section B.3.4

User action figures

Figure B.2 — Low layer and high layer compatibility

checking; compatibility assured

Figure B.3 — Low layer and high layer compatibility

checking; compatibility not assured

Annex B, Section B.3.4

User action figures

Figure B.l — Bearer capability compatibility

checking

Figure B.2 — Low layer and high layer compatibility

checking; compatibility assured

Figure B.3 — Low layer and high layer compatibility

checking; compatibility not assured

Delete the "point-to-point data Unk" columns.

Change the "Incompatible/Broadcast data link" cell from "Reject" to "Ignore or Reject".

Delete "Note 3" from the "Incompatible/broadcast

data Unk" column.

Delete the reference to "Note 1" from the last column.

NIU-Forum Agreements On ISDN A-33
Annex B, Section B.3.4

User action figures

Figure B.3 — Low layer and high layer compatibility

checking; compatibility not assured

Annex B, Section B.3.4

User action figures

Figure B.3 — Low layer and high layer compatibility

checking; compatibility not assured

Annex B, Section B.3.4

User action figures

Figure B.3 —Low layer and high layer compatibility

checking; compatibility not assured

Annex B, Section B.3.4

User action figures

Figure B.3 —Low layer and high layer compatibility

checking; compatibility not assured

Annex C, Section C.l

Introduction

Annex C, Section C.2

Selection not supported

Annex C, Section C.3

Selection supported

Annex C, Section C.3

Selection supported

Annex C, Section C.3

Selection supported

Annex C, Section C.3

Selection supported

Annex C, Section C.3

Selection supported

Annex D

Extension for symmetric call operation

Annex E

Network-specific facility selection

Change "Accept or Reject" to "Accept, Ignore, or

Reject" in the Broadcast Data Link column.

Delete Note 1 below figure B.3.

Change "will reject the call if incompatible" to "may

reject the call if incompatible" in Note 2 below figure

B.3.

Delete Note 3 ("Attempt low layer compatibihty

negotiation (see Annex M).") below Figure B.3.

Delete "optional" from the first paragraph.

Delete this section.

Change the first sentence of the first paragraph to: "The user identifies the selected transit network in the

SETUP message."

Delete the second and third paragraphs.

Delete the fu-st sentence of the fourth paragraph.

Delete the last sentence in the sixth paragraph.

Delete the seventh, eighth, and ninth paragraphs.

Delete this section.

Delete this section.

Annex F Delete this section.

D-channel backup procedure

A-34 NIU-Forum Agreements on ISDN
Annex G, Section G.l

Introduction

Add the following at the end of the first paragraph:

"Section 4.5. 11 identifies the causes supported in NIU

90-301."

Annex G Delete the following sections:

Cause Definitions • Section G.2.16 Cause 22 "number changed"

• Section G.3.2 Cause 38 "network out of order"

• Section G.3.7 Cause 45 "preemption"

• Section G.3.8 Cause 46 "precedence call blocked"

• Section G.3.9 Cause 47 "resource unavailable,

unspecified"

• Section G.4.1 Cause 49 "quality of service

unavailable"

• Section G.4.4 Cause 58 "bearer capability no

presently available"

• Section G.4.5 Cause 63 "service or option not

available, unspecified"

• Section G.5.2 Cause 66 "channel type not

implemented"

• Section G.5.4 Cause 70 "only resu-icted digital

information bearer capability is available"

• Section G.5.5 Cause 79 "service or option not

implemented, unspecified"

• Section G.6.2 Cause 82 "identified channel does

not exist"

• Section G.6.4 Cause 91 "invalid tfansit network

selection"

• Section G.6.5 Cause 95 "invalid message,

unspecified"

Annex H

Examples of Information elements coding

Annex H, Section H.l

Introduction

Change the status of this section from "informative"

to "normative".

Replace the first and second paragraphs with the

following: "These are the only recognized codings of

the following Information Elements for circuit-mode

services: — Bearer capability information element — Channel identification information element".

Annex H

Examples of information elements coding

Annex H, Section H.3.1

Basic Interface, circuit mode, B -channel

Delete the following figures and sections:

• Figure "H.3 Coding for 7 kHz Audio"

• Figure "H.6 Coding for synchronous 1472 kbit/s";

• sections H.3. 2 (Figures H.9, H.IO, H.ll);

• H.3.3 (Figures H.12 through H.17);

• H.4 (Figures H.18 through H.21);

Add Attachment D of this document.

NIU-Forum Agreements On ISDN A-35
Annex I Use of Progress Indicators

Annex I Use of progress indicators

Annex I Use of Progress Indicators

Annex I Use of Progress Indicators

Annex J Examples of Cause Values and location for busy

condition

Annex L

low layer information coding principles

Annex M

Low layer compatibility Negotiation

Annex N

Procedures for establishment of bearer connection

prior to call acceptance

Annex O

Optional procedures for bearer service change

Annex P, Section P.l

Introduction

Annex P, Section P.l

Introduction

Annex P, Section P.l

Introduction

Annex P, Section P.l

Introduction

Annex P, Section P.2

Operator system access requested in keypad facility

information element

Annex P, Section P.2

Operator system access requested in keypad facility

information element

Change the status of this Annex from "Informative"

to "Normative".

Delete the fifth paragraph {"Progress Indicator 4 ...").

Delete "or primary" from the left side (between TE

and ISDN) of Figure I.l.

Delete "Basic or" from the right side (between ISDN

and NT2) of Figure I.l

Change "American National Standard T1.607" to "NIU 90-301" in the first sentence of the first paragraph.

Change the first sentence of the first paragraph to: "This annex is part of NIU 90-301."

Delete this annex.

Delete this annex.

Delete this annex.

Delete "optional" from the first sentence.

Delete "or attendant system" from the end of the first sentence in the first paragraph.

Change the last sentence of the first paragraph to: "These procedures apply to the speech and 3.1 kHz

audio bearer services."

Delete "or attendant system" from the first sentence in

the second paragraph.

Delete "or attendant system" from the first sentence of

the first paragraph.

Delete "or attendant system" from the last sentence of

the first paragraph.

A-36 NIU-Forum Agreements on ISDN
Annex P, Section P.3

Use of the operator system access information

element

Annex P, Section P.3

Use of the operator system access information

element

Annex P, Section P.3

Use of the operator system access information

element

Annex P, Section P.3

Use of the operator system access information

element

Annex Q

Responding address requirements of the OSI network

layer service

Annex R

Application of the Signal Information Element to Tones and Alerting Patterns

Annex R

Application of the Signal Information Element to Tones and Alerting Patterns

Table 21 — Tones

Annex S

Comparison of CCITT Recommendation Q.931 to ANSI Tl.607

Delete "or attendant system" from the first sentence of

the first paragraph.

Delete "c) Private/principal ... SETUP message." from

the second paragraph.

Delete "or attendant system" from the third paragraph.

Delete the sixth paragraph.

Delete this annex.

Change the status of this Annex from "informative" to "normative".

Delete the following rows: 2, 6, 8.

Delete this annex.

NIU-Forum Agreements On ISDN A-37
Attachment A

(of Appendix A)

1. General

1.1 Scope and Purpose

This Implementation Agreement specifies a minimal subset of procedures and codepoints from the American National

Standards Tl.607-1990 (Ref. [17]) for the establishment, maintenance, and clearing of ISDN connections at the user- to-network interface. This signalling standard is used to support the circuit-switched bearer services specified in ANSI standards T1.603*.

Terminals are not required to support all services. Switches will support all of the mandatory protocols and

codepoints in this implementation agreement. This does not preclude the support of additional services and

procedures. However, equipment must be able to interoperate with equipment supporting only this minimal subset.

1.1.1 Definitions

The ANS Tl.607-1990 (Ref. [17]) assumes that procedures apply generically to ISDN access interfaces, i.e., the

document does not distinguish between basic and primary rates access interfaces. In addition, there are no references

to specific applications in that document. The concept of equipment classes is introduced in this document to permit

certain procedures to be associated with a particular application or class of equipment, e.g., station equipment versus PBX. Specifically, two classes of equipment are defined on the basis of two fundamental attributes.

The first attribute relates to the possibility of an exchange of signals occurring beyond the public network's point

of contact with the interface (i.e., between the equipment directly connected to the public network and ISDN

terminals or telephones connected to that equipment). For example, some user equipment may support subtending

Basic Access digital subscriber loops and/or analog telephone loops. For Class I equipment, the network makes no

provision for such an arrangement and assumes the Class I equipment constitutes the endpoint of the communication.

Conversely, in the case of Class II equipment, the procedures at the network take into account that communication

between Class II equipment (with which it communicates directly) and other equipment (with which the network does

not have direct contact) may occur. As an example. Class II equipment may support digital and/or analog subscriber

loops. Use of Class II equipment also involves the possibihty of having interworking occur beyond the equipment

with which the network has direct contact. Therefore, it is reasonable for Class II equipment to provide the network

with an interworking notification, for both outgoing and incoming calls, when either the calling or called party

respectively, is a non-ISDN user. Class II equipment may also send an interworking notification if a private network

exists beyond the Class II equipment and interworking to a non-ISDN facility within that network takes place. When

an interface is associated with Class I equipment, it is assumed the multiple pieces of equipment may exist and

communicate with the network over the D-channel. However, in this case, all equipment is assumed to be ISDNcapable and is considered as the endpoint of the communication. Therefore, interworking notification should not be

accepted from Class I equipment.

The second attribute relates to the manner in which a SETUP message should be presented to the user equipment.

When Class I equipment is applied on a particular interfaces, the network should broadcast the SETUP message

associated with each call that terminates on that interface, since interaction between the network and multiple pieces

of user equipment should be supported. On the other hand, the network should not broadcast SETUP messages

'Subject to further discussion.

A-38 NIU-Forum Agreements on ISDN
associated with terminating calls to an interface on which Class II equipment is being used. Here, a single piece

of user equipment is assumed to be involved in all communication with the network.

To the extent possible, it is desirable to have one set of requirements for ISDN call control apply to all ISDN user

configurations. However, in cases for which integrated procedures are not appropriate, the call control procedures

associated with Equipment Class I will differ from those associated with Equipment Class II. Unless otherwise

noted, the assumption should be that a particular procedure/capability should be provided for both classes of

equipment on both basic and primary rate access. However, use of the equipment class terminology permits

clarification of the circumstances under which a certain capability should be available (i.e., when a particular

equipment class is in use). It also permits a mechanism for indicating that a particular capability applies only to a

subset of four possible configurations which are labeled as follows.

Class I Class II

IB IIB

IP IIP

In other words, a capability that applies to Class I equipment may be provided on basic access interfaces (IB) and/or

primary rate access interfaces (IP). Similarly, a capability that applies to Class II equipment may be provided on

basic access interfaces (IIB) and/or primary rate access interfaces (IIP).

The notation shown in the table above is used within this implementation agreement to indicate when protocol or procedures are only expected to be supported for a particular equipment class and/or are limited to a particular type

of interface, i.e., basic or primary rate interface.

NIU-Forum Agreements On ISDN A-39
Attachment B

(of Appendix A)

The various parts of the called party number information element should be coded as follows: — Type of number and numbering plan (octet 3)

Bits

7 6 5 4 3 2 1 Meaning

0 0 0 0 0 0 0 Unknown

0 0 1 0 0 0 1 International number in ISDN numbering plan (Rec. E.164)

0 1 0 0 0 0 1 National number in ISDN numbering plan (Rec. E.164)

1 0 0 0 0 0 1 Local (directory) number in ISDN numbering plan (Rec. E.164)

110 10 0 1 Abbreviated Number in Private Numbering plan

All other values are reserved

— Digits (octet 4, etc.)

Bits

7 6 5 4 3 2 1 Meaning

0 1 1 0 00 0 0

0 1 1 0 00 1 1

0 1 1 0 0 10 2

0 1 1 0 0 11 3

0 1 1 0 10 0 4

0 1 1 0 10 1 5

0 1 1 0 110 6

0 1 1 0 111 7

0 1 1 1000 8

0 1 1 100 1 9

All other values are reserved

Digits should be represented by IA5 characters whose encoding is shown above.

In the network to user direction (n -> u), this IE will be always signaled in the SETUP message, and public network

interfaces will use only one codepoint: local number in ISDN. For private networks, this EE can contain the

following codepoints: abbreviated type of number, and private numbering plan, and extfa digits such A, B, C, and

D (as per IA5).

A-40 NIU-Forum Agreements on ISDN
Attachment C

(of Appendix A)

The various parts of the calling party number information element should be coded as described below. The

numbering plans are as described in CCITT Recommendations E.164 or X.121. — Type of number and numbering plan (octet 3) follows:

Bits

7 6 5 4 3 2 1 Meaning

0 0 0 0 0 0 0 Unknown

0 0 1 0 0 0 1 International number in ISDN numbering plan (Rec. E.164)

0 0 1 0 0 1 1 International number in data numbering plan (Rec. X.121)

0 1 0 0 0 0 1 National number in ISDN numbering plan (Rec. E.164)

1 0 0 0 0 0 1 Local (directory) number in ISDN numbering plan (Rec. E.164)

110 10 0 1 Abbreviated Number in Private Numbering plan

All other values are reserved — Origin of number and presentation status (octet 3a) follows:

Bits

7 6 5 4 3 2 1 Meaning

0 0 0 0 0 0 0 Presentation allowed of user-provided number,

number not screened

0 0 0 0 0 0 1 Presentation allowed of user-provided number,

number passed network screening

0 0 0 0 0 1 0 Presentation allowed of user-provided number,

number failed network screening

0 0 0 0 0 1 1 Presentation allowed of network-provided number

0 1 0 0 0 0 0 Presentation prohibited of user-provided number,

number not screened

0 1 0 0 0 0 1 Presentation prohibited of user-provided number,

number passed network screening

0 1 0 0 0 1 0 Presentation prohibited of user-provided number,

number failed network screening

0 1 0 0 0 1 1 Presentation prohibited of network-provided number

1 0 0 0 0 1 1 Number not available

All other values are reserved

Notes

1 —^When octet 3a is omitted, the default value of Number Presentation parameter for the signaled DN value

should be used, if it is available. If a value for this parameter is unavailable (i.e., the signaled DN value

either fails screening or is not screened by the SPCS), the presentation parameter value of the default DN

should be used.

2—Octet 3a, bits 7 and 6 are for the Presentation Indicator; bits 2 and 1 are for the Screening Indicator.

NIU-Forum Agreements On ISDN A-41
— Digits (octet 4, etc.)

Digits should be represented by IA5 characters whose encoding is shown below:

Bits

7 6 5 4 3 2 1 Meaning

0 1 1 0000 0

0 1 1 0 00 1 1

0 1 1 0 0 10 2

0 1 1 0 0 11 3

0 1 1 0 10 0 4

0 1 1 0 10 1 5

0 1 1 0 110 6

0 1 1 0 111 7

0 1 1 1000 8

0 1 1 100 1 9

All other values are reserved

Codings At Originating Party Interface

The calling party number information element should only be accepted when in the SETUP message. When

the type of number and numbering plan indicator indicates "local number in the ISDN (E.164) numbering

plan," the calling party number information element should contain a 7-digit local number. When the type

of number and numbering plan indicator indicates "national number in the ISDN (E.164) numbering plan"

the calhng party number information element should contain a 10-digit national number.

In the network to user direction (n -> u), the coding and delivery of this IE depends on the definition of

the Calling Line ID service. For private networks, this IE can contain the following codepoints: abbreviated

type of number, and private numbering plan, and extra digits such as A, B, C, and D (as per IA5).

A-42 NIU-Forum Agreements on ISDN
Attachment D

(of Appendix A)

• add the following figures to section H.3.1

8 7 6 5 4 3 2 1 octet

Channel identification

0 0 0 1 1 0 0 0

Information element identifier

0 0 0 0 0 0 0 1

Length of the channel identification contents

1 0 0 0 1 0 0 1

int int Pref/ D ch. Ch. sel.

id type Excl id.

Figure H.7-1. Channel Bl exclusive.

8 7 6 5 4 3 2 1 octet

Channel identification

0 0 0 1 1 0 0 0

Information element identifier

0 0 0 0 0 0 0 1

Length of the channel identification contents

1 0 0 0 0 0 1 0

int int Pref/ D ch. Ch. sel.

id type Excl id.

Figure H.7-2. Channel B2 preferred.

NIU-Forum Agreements On ISDN A-43
8 7 6 5 4 3 2 1 octet

Channel identification

0 0 0 1 1 0 0 0

Information element identifier

0 0 0 0 0 0 0 1

Length of the channel identification contents

1 0 0 0 1 0 1 0

int int Pref/ D ch. Ch. sel.

id type Excl id.

Figure H.7-3. Channel B2 exclusive.

8 7 6 5 4 3 2 1 octet

Channel identification

0 0 0 1 1 0 0 0

Information element identifier

0 0 0 0 0 0 0 1

Length of the channel identification contents

1 0 0 0 0 0 1 1

int int Pref/ D ch. Ch. sel.

id type Excl id.

Figure H.7-4. Any B-channel.

A-44 NIU-Forum Agreements on ISDN
8 7 6 5 4 3 2 1 octet

Channel identification

0 0 0 1 1 0 0 0

Information element identifier

0 0 0 0 0 0 0 1

Length of the channel identification contents

1 0 0 0 0 0 0 0

int int Pref/ D ch. Ch. sel.

id type Excl id.

Figure H.7-5. No B-channel Indicated.

NIU-Forum Agreements On ISDN A-45

APPENDIX B.

NIU 90-302

Implementation Agreement

of the North American ISDN Users' Forum

Layer 3 Signalling Specification for the

Minimal Set of Circuit-Switched Bearer Services for

the ISDN Class II Primary Rate Interfaces.

Baseline Text

American National Standard T1.607- 1990:

Integrated Services Digital Network (ISDN) —

Layer 3 Signalling Specification for

Circuit-Switched Bearer Service for

Digital Subscriber Signalling System Number I (DSSl).

Base Standards

CCITT Recommendation Q.931 (1988):

ISDN User-Network Interface Layer 3

Specification For Basic Call Control.

ANSI Tl.607- 1990

ANSI Tl.603-1990*:

Integrated Services Digital Network (ISDN) —

Minimal Set of Bearer Services for

the Primary Rate Interface.

B.l Abstract

This Implementation Agreement specifies procedures for establishing, maintaining, and clearing connections at the

Integrated Services Digital Network (ISDN) user-network interfaces identified as Class II PRJ, and are mandatory

for the support of the minimal set of circuit-switched bearer services specified by ANSI Tl.603-1990' Integrated

Services Digital Network (ISDN) — Minimal Set of Bearer Services for the Primary Rate Interface, (Ref [14]).

Procedures for circuit-mode digital, circuit-mode speech and circuit-mode voiceband data bearer services are as

specified in the baseline text ANS Tl.607-1990, Integrated Services Digital Network (ISDN) — Digital Subscriber

Signalling System Number 1 (DSSl) —Layer 3 Signalling Specification for Circuit-Switched Bearer Service, (Ref

[17]), as further resolved by this agreement. The packet-mode data service is included in this document as a bearer

service. Procedures for the packet-mode bearer service will be detailed in another document.

'Subject to further discussion

NIU-Forum Agreements On ISDN B-1
B.2 Introduction

The original implementation agreement (NUJ 90-302) was reached by marking up the text of ANS Tl.607-1990,

(Ref. [17]) to reflect the clarifications of text and selection of options. This appendix translates the implementation

agreement markup into a listing of these clarifications and selections, (i.e., this appendix Usts the differences (the

"delta") between the implementation agreement marked up ANS Tl.607-1990, and the original text of ANS T1.607-

1990).

B.3 NIU 90-302 Delta List"

The lA has adopted the ANS Tl.607-1990'" (Ref [17]) standard with the following clarifications of the text, and

selection of options:

ANS Tl.607-1990

SECTIONyTABLE NUMBER/NAME

Section 1.1 Scope and Purpose

Section 2.1.1.3

Overlap Sending (U2)

Section 2.1.2.3

Overlap Sending (N2)

Section 2.1.2.14

Call Abort (N22)

Section 3.1

Table 1 — Messages for circuit-mode connection

control

Section 3.1

Table 1 — Messages for circuit-mode connection

control

IMPLEMENTATION AGREEMENTS - CLARIFICATION OF TEXT AND

SELECTION OF OPTIONS

Replace this section with Attachment A of this document.

Delete this section.

Delete this section.

Delete this section.

Delete the following message and reference:

"INFORMATION 3.1.6".

Delete the following message and reference: "SETUP

ACKNOWLEDGE 3.1.12".

Section 3.1 Change "NOTIFY 3.1.7" to "NOTIFY*".

Table 1 — Messages for circuit-mode connection

control

"Note that this Delta List was developed in "good faith" by NIST as a simple equivalent representation of the

actual agreements. It has been reviewed and approved by the editors of the Signalling Working Group as per

recommendation of the Executive Steering Committee.

"'These documents can be purchased from: American National Standards Institute, 11 West 42nd Street, New

York, NY 10036.

j

3.2 NIU-Forum Agreements on ISDN

I

i
Section 3.1

Messages for circuit-mode connection control

Section 3.1.1

ALERTING

Table 2 — ALERTING message content

Section 3.1.1

ALERTING

Table 2 — ALERTING message content

Section 3.1.1

ALERTING

Table 2 - ALERTING message content

Section 3.1.1

ALERTING

Table 2 — ALERTING message content

Section 3.1.2

CALL PROCEEDING

Table 3 — CALL PROCEEDING message content

Section 3.1.2

CALL PROCEEDING

Table 3 — CALL PROCEEDING message content

Section 3.1.2

CALL PROCEEDING

Table 3 — CALL PROCEEDING message content

Section 3.1.2

CALL PROCEEDING

Table 3 — CALL PROCEEDING message content

Section 3.1.2

CALL PROCEEDING

Table 3 — CALL PROCEEDING message content

Section 3.1.3

CONNECT

Table 4 — CONNECT message content

Section 3.1.3

CONNECT

Table 4 — CONNECT message content

Add the following footnote below Table 1 "* See

section 5.8.4 for treatment of this message."

Change the "Call reference/Length" cell from "2-*" to "2-3".

Change the "Channel identification/Length" cell from

"2-*" to "2, 5-6".

Delete the following rows:

• "Display";

• "Signal".

Delete Notes 4, 5, 6.

Change the "Call reference/Length" cell from "2-*" to "2-3".

Change the "Channel identification/Type" cell from

"0(Note D" to "M".

Change the "Channel identification/Length" cell from

"2-*" to "2, 5-6".

Delete rows

• "Progress indicator";

• "Display".

Delete Notes 1, 2, 3, 4.

Change the "Call reference/Length" cell from "2-*" to "2-3".

Change the "Channel identification/Length" cell from

"2-*" to "2, 5-6".

NIU-Forum Agreements On ISDN B-3
Section 3.1.3

CONNECT

Table 4 — CONNECT message content

Section 3.1.3

CONNECT

Table 4 — CONNECT message content

Section 3.1.3

CONNECT

Table 4 — CONNECT message content

Section 3.1.4

CONNECT ACKNOWLEDGE

Table 5 — CONNECT ACKNOWLEDGE message

content

Section 3.1.4

CONNECT ACKNOWLEDGE

Table 5 — CONNECT ACKNOWLEDGE message

content

Section 3.1.4

CONNECT ACKNOWLEDGE

Table 5 — CONNECT ACKNOWLEDGE message

content

Section 3.1.5

DISCONNECT

Table 6 — DISCONNECT message content

Section 3.1.5

DISCONNECT

Table 6 — DISCONNECT message content

Section 3.1.5

DISCONNECT

Table 6 — DISCONNECT message content

Delete the following rows:

• "Display";

• "Signal";

• "Connected number";

• "Connected subaddress";

• "Low layer compatibility".

Change Note 3 to: "Included in the event of

interworking."

Delete Notes 4, 5, 6, 7, 8, 9.

Change the "Call reference/Length" cell from "2-*" to "2-3".

Delete the following rows:

• "Display";

• "Signal".

Delete Notes 1, 2, 3.

Change the "Call reference/Length" cell from "2-*" to "2-3".

Change the "Cause/Length" from "4-32" to "4-10".

Delete the following rows:

• "Display";

• "Signal"'

• "Connected Number";

• "Connected subaddress".

Section 3.1.5 Delete Notes 1, 2, 3, 4, and 5. DISCONNECT

Table 6 — DISCONNECT message content

Section 3.1.6 Delete this section.

INFORMATION

B-4 NIU-Forum Agreements on ISDN
Section 3.1.7

NOTIFY

Delete this section.

Section 3.1.8

PROGRESS

Table 9 — PROGRESS message content

Section 3.1.8

PROGRESS

Table 9 — PROGRESS message content

Section 3.1.8

PROGRESS

Table 9 — PROGRESS message content

Section 3.1.8

PROGRESS

Table 9 — PROGRESS message content

Section 3.1.9

RELEASE

Table 10 — RELEASE message content

Section 3.1.9

RELEASE

Table 10 — RELEASE message content

Section 3.1.9

RELEASE

Table 10 — RELEASE message content

Section 3.1.9

RELEASE

Table 10 — RELEASE message content

Section 3.1.10

RELEASE COMPLETE

Table 1 1 —RELEASE COMPLETE message content

Change the "Call reference/Length" cell from "2-*" to "2-3".

Change the "Cause/Length" cell from "2-32" to "2, 4-

10".

Delete the following rows:

• "Display";

• "Signal".

Delete Notes 2, 3, 4.

Change the "Call reference/Length" cell from "2-*" to "2-3".

Change the "Cause/Length" cell from "2-32" to "2, 4-

10".

Delete the following rows:

• "Display";

• "Signal";

• "Connected number";

• "Connected subaddress".

Delete Notes 3, 4, 5, 6, 7.

Change the "Call reference/Length" cell from "2-*" to "2-3".

Section 3.1.10 Change the "Cause/Length" cell from "2-32" to "2, 4-

RELEASE COMPLETE 10".

Table 1 1 —RELEASE COMPLETE message content

NIU-Forum Agreements On ISDN B-5
Section 3.1.10

RELEASE COMPLETE

Table 1 1 —RELEASE COMPLETE message content

Section 3.1.10

RELEASE COMPLETE

Table 1 1 —RELEASE COMPLETE message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Delete the following rows:

• "Display";

• "Signal";

• "Connected number";

• "Connected subaddress".

Delete Notes 3, 4, 5, 6, 7.

Change the "Call reference/Length" cell from "2-*" to "2-3".

Delete the following rows:

• "Repeat indicator";

• "Display";

• "Keypad facihty";

• "Signal".

Change the "Bearer capability/Type" cell from

"M(Note 2)" to "M".

Change the "Bearer capability/Length" cell from "4-

13" to "4-8".

Change the "Channel identification/Type" cell from

"0(Note 3)" to "M".

Change the "Channel identification/Length" cell from

"2-*" to "5-6".

Change the "Network specific faciUties/Length" cell from "2-*" to "2-32".

Change the "Calling party number/Length" cell from

"2-*" to "2-19".

Change the "Called party address/Length" cell from

"2-*" to "2-18".

B-6 NIU-Forum Agreements on ISDN
Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.11

SETUP

Table 12 — SETUP message content

Section 3.1.12

SETUP ACKNOWLEDGE

Section 3.1.13

STATUS

Table 14 — STATUS message content

Change the "Transit network selection/Length" cell from "2-*" to "2-7".

Change the "High layer capability/Length" cell from

"2-4" to "2-5".

Delete Notes 1, 2, 3, 6, 7, 8, 9.

Change Note 4 to: "Included in the event of

interworking."

Change the first sentence of Note 12 to: "The called

party number information element is included by the user ....".

Change the first sentence of Note 20 to: "This

information applies to speech and 3.1 kHz audio

bearer services."

Add the following to the end of Note 13: "The

network should transport this IE transparently. This

IE is optional on the user side."

Add the following to the end of Note 15: "The

network should transport this IE transparently. This

IE is optional on the user side. The total length is 2

to 16 octets."

Add the following to the end of Note 16: "The

network should transport this IE transparently. This

IE is optional on the user side."

Add the following to the end of Note 17: "The

network will treat this IE on sending and receiving as described in the User-User supplementary service

Implementation Agreement."

Delete this section.

Change the "Call reference/Length" cell from "2-*" to "2-3".

NIU-Forum Agreements On ISDN B-7
Section 3.1.13

STATUS

Table 14 — STATUS message content

Section 3.1.13

STATUS

Table 14 — STATUS message content

Section 3.1.13

STATUS

Table 14 — STATUS message content

Section 3.1.14

STATUS ENQUIRY

Section 3.1.14

STATUS ENQUIRY

Table 15 — STATUS ENQUIRY message content

Section 3.1.14

STATUS ENQUIRY

Table 15 — STATUS ENQUIRY message content

Section 3.1.14

STATUS ENQUIRY

Table 15 — STATUS ENQUIRY message content

Section 3.2.1

RESTART

Table 17 — RESTART message content

Section 3.2.1

RESTART

Table 17 — RESTART message content

Section 3.2.1

RESTART

Table 17 — RESTART message content

Section 3.2.1

RESTART

Table 17 — RESTART message content

Section 3.2.2

RESTART ACKNOWLEDGE

Table 18 — RESTART ACKNOWLEDGE message

content

Change the "Cause/Length" cell from "4-32" to "4-

10".

Delete row "Display".

Delete Notes 1, 2.

Change the first sentence to: "This message is sent by the user or the network during the active state to

solicit a STATUS message from the peer layer 3

entity."

Change the "Call reference/Length" cell from "2-*" to "2-3".

Delete row "Display".

Delete Notes 1, 2.

Change the "Call reference/Length" cell from "2-*" to "2-3".

Change the "Channel identification/Length" cell from

"2-*" to "2, 5-6".

Delete row "Display".

Delete Notes 3, 4.

Change the "Call reference/Length" cell from "2-*" to "2-3".

B-8 NIU-Forum Agreements on ISDN
Section 3.2.2

RESTART ACKNOWLEDGE

Table 18 — RESTART ACKNOWLEDGE message

content

Section 3.2.2

RESTART ACKNOWLEDGE

Table 18 — RESTART ACKNOWLEDGE message

content

Section 3.2.2

RESTART ACKNOWLEDGE

Table 18 — RESTART ACKNOWLEDGE message

content

Section 4.2

Protocol discriminator

Section 4.2

Protocol discriminator

Figure 2 — Protocol Discriminator

Section 4.2

Protocol discriminator

Table 19 — Protocol Discriminator

Section 4.3

Call reference

Section 4.3

Call reference

Section 4.3

Call reference

Figure 4 — Dummy call reference

Section 4.3

Call reference

Section 4.3

Call reference

Section 4.4

Message type

Table 20 — Message types

Change the "Channel identification/Length" cell from

"2-*" to "2, 5-6".

Delete row "Display".

Delete Notes 3, 4.

Add the following sentence after the first sentence in

die second paragraph: "The only value supported for

call control messages is described below in Figure 2."

Change "ANSI T1.607" to "Q.931".

Change "ANSI T1.607" to "Q.931" in row "0000

1000".

Change the third paragraph ("At a minimum ...") to: "At a minimum, all networks and users must be able

to support a call reference value of one and two octets

for a primary rate interface."

Delete the first sentence of the fourth paragraph "As

a network ... also be supported."

Change "Figure 4. Dummy call reference" to "Figure

4. Dummy call reference *".

Add the following footnote after Figure 4: "*The

dummy call reference is not supported for primary

rate Class II circuit-switched calls."

Delete Note 1 ("The call reference ... ") at the end of

the section.

Delete the following rows:

• "SETUP ACKNOWLEDGE";

• "INFORMATION".

NIU-Forum Agreements On ISDN B-9
Section 4.4

Message type

Table 20 — Message types

Section 4.5.1

Coding rules

Section 4.5.1

Coding rules

Figure 7 — Formats of information elements

Section 4.5.1

Coding rules

Table 21 — Information element identifier coding

Section 4.5.1

Coding rules

Table 21 — Information element identifier coding

Section 4.5.1

Coding rules

Table 21 — Information element identifier coding

Section 4.5.1

Coding rules

Table 21 — Information element identifier coding

Section 4.5.1

Coding rules

Table 21 — Information element identifier coding

Section 4.5.1

Coding rules

Table 21 — Information element identifier coding

Section 4.5.1

Coding rules

Table 21 — Information element identifier coding

Section 4.5.1

Coding rules

Table 21 — Information element identifier coding

Add the following to the end of row "NOTIFY":

"(see sec. 5.8.4 for treatment of this message type)."

Delete the second, third, and fourth sentences from

the fourth paragraph.

Delete figure (b) Single octet information element

format (type 2).

Delete the following rows:

• "Repeat indicator";

• "Notification indicator";

• "Display";

• "Keypad facility";

• "Signal";

• "Connected number";

• "Connected subaddress";

• "Escape for extension".

Delete reference to "(Note 6)" from "Bearer

capability" row.

Change the "Bearer capability/Max length" cell from

"13" to "8".

Change the "Cause/Max length" cell from "32" to "10".

Change the "Cause/Max no of occurrences" cell from

"3" to "2".

Change the "Channel identification/Max length" cell from "(Note 4)" to "6".

Change the "Network-specific facilities/Max length"

cell from "(Note 4)" to "32".

Change the "Network-specific facilities/Max no. of

occurrences" cell from "4" to "2".

B-10 NIU-Forum Agreements on ISDN
Section 4.5.1

Coding rules

Table 21 — Information element identifier coding

Section 4.5.1

Coding rules

Table 21 — Information element identifier coding

Section 4.5.1

Coding rules

Table 21 — Information element identifier coding

Section 4.5.1

Coding rules

Table 21 — Information element identifier coding

Change the "Calling party number/Max length" cell from "(Note 4)" to "19".

Change the "Called party number/Max length" cell from "(Note 4)" to "18".

Delete reference to "(Note 2)" from "Transit network

selection" row.

Change the "Transit network selection/Max length"

cell from "(Note 4)" to "7".

Section 4.5.1 Delete "4" from the "Transit network selection/Max

Coding rules no, of occurrences" cell. Table 21 — Information element identifier coding

Section 4.5.1

Coding rules

Table 21 — Information element identifier coding

Section 4.5.1

Coding rules

Table 21 — Information element identifier coding

Change the "High layer compatibiHty/Max length" cell from "4" to "5".

Delete Notes 3, 4, 6.

Section 4.5.1 Delete this figure.

Coding rules

Figure 8 — Information element format using escape

for extension

Section 4.5.2 Change "T1.608" to "NIU 89-320" in the first bullet

Extensions of codesets in the fourth paragraph.

NIU-Forum Agreements On ISDN B-11
Section 4.5.2

Extensions of codesets

Replace the tenth paragraph ("Codeset 6 ...") with the

following:

Section 4.5.3

Locking shift procedure

New codeset identification table

Section 4.5.4

Non-locking shift procedures

Section 4.5.4

Non-locking shift procedures

Temporary codeset identification table

Section 4.5.4

Non-locking shift procedures

Temporary codeset identification table

Section 4.5.5

Bearer Capability

Section 4.5.5

Bearer Capability

Figure 11 — Bearer capability information element

"Codeset 6 is reserved for information elements

specific to the local network (either public or private).

These information elements can appear in a call establishment (i.e., SETUP, ALERTING, or CONNECT) or first clearing message. As such, they

do not have significance across a national or

international boundary. For these two cases, codeset

6 information elements shall be handled according to the procedures for unrecognized information elements

(see sec. 5.8.7.1) beyond the local network boundary.

Inside a private local network recognized codeset 6

information elements shall be consumed, manipulated,

or passed transparently according to the rule for that information element. Across the boundary between

local networks (e.g., a public and a private network),

recognized codeset 6 information elements shall be

consumed and manipulated according to the rule for

that information element. Inside a private local

network, unrecognized codeset 6 information elements

may be passed transparently. Across the boundary

between a private local network and a public local

network, unrecognized codeset 6 information elements

shall be either treated as per section 5.8.7.1 or passed

transparently if a bilateral agreement exists."

Change "T1.608" to "NIU 89-320" for codeset 5.

Delete "a) process the nonblocking ... as described

below" from the second paragraph.

Change "T1.607" to "NIU 90-302" for codeset 0.

Change "T1.608" to "NIU 89-320" for codeset 5.

Change "13 octets" to "8 octets" in the second

sentence ("The maximum length ...") of the second

paragraph.

Change octet 4, bit 8 from "0/1" to "1".

B-12 NIU-Forum Agreements on ISDN
Section 4.5.5

Bearer Capability

Figure 11 — Bearer capability information element

Section 4.5.5

Bearer Capability

Figure 11 — Bearer capability information element

Section 4.5.5

Bearer Capability

Figure 11 — Bearer capability information element

Section 4.5.5

Bearer Capability

Figure 11 — Bearer capability information element

Section 4.5.5

Bearer Capability

Information transfer capability (octet 3) coding

Section 4.5.5

Bearer Capability

Information transfer rate (octets 4 and 4b) coding

Section 4.5.5

Bearer Capability

Information transfer rate (octets 4 and 4b) coding

Section 4.5.5

Bearer Capability

Information transfer rate (octets 4 and 4b) coding

Section 4.5.5

Bearer Capability

Information transfer rate (octets 4 and 4b) coding

Section 4.5.5

Bearer Capability

Section 4.5.5

Bearer Capability

User information layer 1 protocol (octet 5) coding

Delete the following octets:

• 4a;

• 4b;

• 5b (Note 2);

• 5b (Note 3);

• 5c;

• 5d.

Change octet 5a, bit 8 from "0/1" to "1".

Delete Notes 1, 2, 3.

Add the following after Note 4: "5 Octets 6 and 7

are included for information only. The coding and

application of these octets are included in another

document."

Delete row "10001 7 kHz audio".

Change the title to "Information transfer rate (octet

4)".

Delete the following rows: "10011 384 kbit/s",

"10100 1472 kbit/s (Note 2)", "10101 1526 kbit/s".

Change Note 1 to: "The bearer capability is

bidirectional symmetric at the information transfer

rate specified in octet 4."

Delete Note 2.

Delete all codings and text referring to octet 4a

(structure, configuration, establishment) and octet 4b

(symmetry).

Delete "and optionally octets 5b, 5c, and 5d as defmed below." from row "00001".

NIU-Forum Agreements On ISDN B-13
Section 4.5.5

Bearer Capability

User information layer 1 protocol (octet 5) coding

Section 4.5.5

Bearer Capability

User information layer 1 protocol (octet 5) coding

Section 4.5.5

Bearer Capability

User information layer 1 protocol (octet 5) coding

Section 4.5.5

Bearer Capability

Synchronous/asynchronous (octet 5a) coding

Section 4.5.5

Bearer Capability

Synchronous/asynchronous (octet 5a) coding

Section 4.5.5

Bearer Capability

Negotiation (octet 5a) coding

Section 4.5.5

Bearer Capability

User rate (octet 5a) coding

Section 4.5.5

Bearer Capability

Section 4.5.5

Bearer Capability

Section 4.5.6

Call state Call state value (octet 3) coding

Section 4.5.6

Call state Call state value (octet 3) coding

Delete "and G,725 7 kHz audio" from row "00101".

Delete rows "00111" and "01000".

Delete Note 2.

Delete row "1 asynchronous".

Delete the second and third sentences from the Note.

Delete row "1 In-band negotiation possible".

Delete all rows except row "01111 56 kbit/s CCITT

Recommendation V.6".

Delete all text relating to octet 5b (i.e., sections

labeled "Octet 5b for CCITT Recommendation V.lOO

or X.30 rate adaption" and "Octet 5b for CCITT

Recommendation V.120 rate adaption").

Delete all codings and text referring to octets 5c

(number of data bits excluding parity bit, parity

information) and 5d (duplex mode, modem type).

Delete row "000010 U2 — overiap sending".

Add the following column to the right of the coding:

Symmetric States*

50 — Null

51 — Call Initiated

53 — Outgoing Call Proceeding

54 — Call Delivered

56 — Call Present

57 — Call Received

58 — Connect Request

59 — Incoming Call Proceeding

B-14 NIU-Forum Agreements on ISDN
Section 4.5.6

Call state Call state value (octet 3) coding

Section 4.5.6

Call state Call state value (octet 3) coding

Section 4.5.7

Called party number

Section 4.5.7

Called party number

Type of number (octet 3) coding

Section 4.5.7

Called party number

Type of number (octet 3) coding

Section 4.5.7

Called party number

Type of number (octet 3) coding

Section 4.5.7

Called party number

Numbering Plan Identification (octet 3) coding

Section 4.5.7

Called party number

Numbering plan identification (octet 3) coding

Section 4.5.7

Called party number

Section 4.5.9

Calling party number

510 — Active

511 — Disconnect Request

512 — Disconnect Indication

S19 — Release Request

Add the following after the coding: "*Note — For

Symmetric states see Annex D."

Delete "N22 — Call abort" from the "010110/

Network State" cell.

Change the second paragraph to: "The maximum

length of this information element is 18 octets."

Delete the following rows:

• "Oil network specific number";

• "ill reserved for extension".

Change the end of Note 2 to: "this information

element cannot be used in combination with Operator

System Access or Transit Network Selection

information elements."

Delete Note 4.

Delete the following rows:

• "0011 data numbering plan";

• "0100 telex numbering plan";

• "1111 reserved for extension".

Change "c)" under the Note to: "this information

element cannot be used in combination with Operator

System Access or Transit Network Selection

information elements."

Add Attachment B of this document after the

following:

"Number digits (octets 4, etc.)

This field is coded with ASCII characters,

according to the formats specified in the appropriate

numbering/dialing plan."

Change the second paragraph from "The maximum

length of this information element is network

dependent." to "The maximum length of this information element is 19 octets."

NIU-Forum Agreements On ISDN B-15
Section 4.5.9

Calling party number

Type of number (octet 3) coding

Section 4.5.9

Calling party number

Type of number (octet 3) coding

Section 4.5.9

Calling party number

Numbering Plan Identification (octet 3) coding

Section 4.5.9

Calling party number

Section 4.5.11

Cause

Section 4.5.11

Cause

Figure 17 — Cause information element

Section 4.5.11

Cause

Figure 17 — Cause information element

Section 4.5.11

Cause

Figure 17 — Cause information element

Section 4.5.11

Cause

Recommendation (octet 3a) coding

Section 4.5.11

Cause

Section 4.5.11

Cause

Cause table

Section 4.5.11

Cause

Cause table

Delete the following rows:

• "Oil network specific number";

• "111 reserved for extension".

Delete Note 4.

Delete the following rows:

• "0100 telex numbering plan";

• "1111 reserved for extension".

Add Attachment C of this document after the

following:

"Number digits (octets 4, etc.)

This field is coded with ASCII characters,

according to the formats specified in the appropriate

numbering/dialing plan."

Change the second sentence of the first paragraph to: "The maximum length of this information element is 10 octets."

Change octet 3, bit 8 from "0/1" to "1".

Delete octet 3a.

Delete the Note under the figure.

Delete this coding and Notes 1 and 2.

Add the following sentence to the end of the

paragraph following "Diagnostics (octet 5)": "If more

than one IE is identified in a diagnostic, they should

be ordered as Es normally appear in a message."

Change the "unallocated (unassigned) number/

diagnostics" cell to "Not used".

Change the "no route to specified transit network/

diagnostics" cell to "Not used".

B-16 NIU-Forum Agreements on ISDN
Section 4.5.11

Cause

Cause table

Section 4.5.11

Cause

Cause table

Section 4.5.11

Cause

Cause table

Section 4.5.11

Cause

Cause table

Section 4.5.11

Cause

Cause table

Section 4.5.11

Cause

Cause table

Section 4.5.11

Cause

Cause table

Section 4.5.11

Cause

Cause table

Section 4.5.11

Cause

Cause table

Section 4.5.11

Cause

Cause table

Change the "no route to destination/diagnostics" ceil

to "Not used".

Change "normal call clearing/diagnostics" cell to "Not

used".

Change the "user busy/diagnostics" cell to "(see Note

10)".

Change the "call rejected/diagnostics" cell to "Not

used".

Delete the "number changed/diagnostics" cell.

Delete the following rows:

• "non-selected user clearing";

• "network out of order";

• "resource unavailable, unspecified";

• "quality of service unavailable";

• "only restricted digital information bearer capability

is available";

• "service or option not implemented, unspecified";

• "invalid transit network selection";

• "invalid message, unspecified".

Change the "No circuit/channel available/diagnostics"

cell to "(see Note 10)".

Delete reference to "(see Note 6)" in the "access

information discarded/diagnostics" cell.

Add "(see Note 10)" to the "requested circuit or channel not available/diagnostics" cell.

Delete the corresponding cell in the "diagnostics"

column for the following rows:

• "requested facility not subscribed";

• "bearer capability not authorized";

• "bearer capability not presently available";

• "channel type not implemented";

• "requested facility not implemented".

NIU-Foruiti Agreements On ISDN B-17
Section 4.5.11

Cause

Cause table

Section 4.5.11

Cause

Cause table

Section 4.5.11

Cause

Cause table

Section 4.5.11

Cause

Cause table

Section 4.5.11

Cause

Cause table

Section 4.5.11

Cause

Cause table

Section 4.5.11

Cause

Cause table

Section 4.5.11

Cause

Cause table

Section 4.5.11

Cause

Figure 18 —Coding of the diagnostic field for causes

57, 58 and 65.

Section 4.5.11

Cause

Section 4.5.12

Channel identification

Section 4.5.12

Channel identification

Change the "bearer capability not implemented/

diagnostics" cell to "Not used".

Change the "identified channel does not exist/

diagnostics" cell to "Not used".

Delete the "incompatible destination/diagnostics" cell.

Delete the reference to "(see Note 6)" in the

"mandatory information element is missing/

diagnostics" cell.

Change the "informadon element non-existent or not

implemented/diagnostics" cell to "Information

element idendfier(s) (see Note 8)".

Change die "invalid information element contents/

diagnostics" cell to "Information element

identifier(s)".

Change the "recovery on timer expiry/diagnostics"

cell to "Not used".

Delete die following Notes: 2, 3, 4, 5, 6, 7, 9, 11, 12.

Delete this figure and Notes 1 and 2 appearing below

it.

Delete all text referring to octets 5 (attribute number),

5a (rejected attribute), and 5b (available attribute).

Change die last sentence in die first paragraph to: "The default maximum length for this information

element is 6 octets."

Delete the second paragraph.

B-18 NIU-Forum Agreements on ISDN
Section 4.5.12

Channel identification

Figure 19 — Channel identification information

element

Section 4.5.12

Channel identification

Figure 19 — Channel identification information

element

Change octet 3.1, bit 8 from "0/1" to "1".

Delete the reference to "Note 2" of octet 3.2.

Section 4.5.12

Channel identification

Figure 19 — Channel identification information

element

Delete the references to "(Note 2)" and "Note 4" in

octet 3.3.

Section 4.5.12 Delete the last sentence of Note 1. Channel identification

Figure 19 — Channel identification information

element

Section 4.5.12 Delete Notes 2 and 4. Channel identification

Figure 19 — Channel identification information

element

Section 4.5.12

Channel identification

Figure 19 — Channel identification information

element

Add the following to the end of Note 3: completeness, a pointer to slot map is shown,

not supported for this lA."

Section 4.5.12

Channel identification

Interface identifier present (octet 3) coding

Section 4.5.12

Channel identification

Interface type (octet 3) coding

Section 4.5.12

Channel identification

Information channel selection (octet 3) coding

Section 4.5.12

Channel identification

Information channel selection (octet 3) coding

Section 4.5.12

Channel identification

Information channel selection (octet 3) coding

Change row the last row ("1") to: "1 Interface

explicitly identified in octet 3.1."

Delete the following row: "0 basic interface".

Delete the column "basic interface".

Delete the last two rows ("10" and "11").

Delete Note 3.

NIU-Forum Agreements On ISDN B-19
Section 4.5.12

Channel identification

Interface identifier (octet 3.1) coding

Section 4.5.12

Channel identification

Coding standard (octet 3.2) coding

Section 4.5.12

Channel identification

Number/map (octet 3.2) coding

Section 4.5.12

Channel identification

Channel type/map element type (octet 3.2) coding

Section 4.5.12

Channel identification

Channel type/map element type (octet 3.2) coding

Section 4.5.12

Channel identification

Section 4.5.12

Channel identification

Section 4.5.13

Connected number

Section 4.5.14

Connected subaddress

Section 4.5.15

Display

Section 4.5.16

High layer compatibility

Section 4.5.17

Keypad facility

Section 4.5.18

Low layer compatibility

Section 4.5.18

Low layer compatibility

Negotiation indicator (octet 3a) coding

Delete the second sentence ("At subscription time

...").

Delete row " 1 0 National Standard ..."

Delete the last row.

Delete the last three rows.

Delete the Note.

Delete all text and Figure 20 referring to "Slot map

(octet 3.3)".

Add the following at the end of the section: "Note —

In the network to user direction (n -> u), the

terminating PRI will allow channel negotiation. The

network will support offering calls with preferred Bchannel and the user responds specifying the channel

to be used for the call."

Delete this section.

Delete this section.

Delete this section.

Change the second paragraph to: "The maximum

length of this information element is five octets."

Delete this section.

Delete the second paragraph.

Delete the last row.

B-20 NIU-Forum Agreements on ISDN
Section 4.5.18

Low layer compatibility

Negotiation indicator (octet 3a) coding

Section 4.5.18

Low layer compatibility

User information layer 3 protocol (octet 7) coding

Section 4.5.19

Network-specific facilities

Section 4.5.19

Network-specific facilities

Section 4.5.19

Network-specific facilities

Section 4.5.20

Notification indicator

Delete Note 1.

Change "ANSI T1.607" to "NIU 90-302" in the first row.

Change the second sentence of the first paragraph to: "No more than two Network-specific facilities information elements may be included in a single

message."

Change the second paragraph to: "The maximum

length of this information element is 32 octets."

Add Attachment D of this document to the end of this

section.

Delete this section.

Secfion 4.5.21

Progress indicator

Progress description (octet 4) coding

Section 4.5.21

Progress indicator

Delete row "000 0100

ISDN."

4 call has returned to the

Add the following Note after Notes 1 and 2 following

the "Progress description (octet 4)" coding: "3 In

the SETUP message, in the user to network direction

(u -> n) on PRI, one of two values may be used in

the progress description tield: 'call is not end-to-end

ISDN' (1), or 'calling equipment is non-ISDN' (3). In the SETUP message, in the network to user

direction (n -> u) on PRI, one of two values may be

used in the progress description field: 'call is not

end-to-end ISDN' (1), or 'calling equipment is non- ISDN' (3)."

Section 4.5.22

Repeat Indicator

Section 4.5.24

Signal

Section 4.5.25

Transit network selection

Delete this section.

Delete this section.

Change the first paragraph to: "The purpose of the

Transit network selection information element is to

identify one requested transit network (See Annex

C)."

NIU-Forum Agreements On ISDN B-21
Section 4.5.25

Transit network selection

Section 4.5.25

Transit network selection

Type of network identification (octet 3) coding

Section 4.5.25

Transit network selection

Network identification plan (octet 3) coding

Section 4.5.26

User-user

Section 4.5.26

User-user

Protocol discriminator (octet 3) coding

Section 5

Circuit-switched call control procedures

Section 5

Circuit-switched call control procedures

Section 5.1

Call establishment at the originating interface

Section 5.1.1

Call request

Section 5.1.1

Call request

Section 5.1.1

Call request

Section 5.1.1

Call request

Change the second paragraph to: "The default

maximum length of this information element is 7

octets."

Delete the last row ("Oil ...").

Delete the last row ("0011 ...").

Add the following to the end of the first paragraph:

"This IE is to be included based on the User-to-user

supplementary service description and user

application."

Change "ANSI T1.607" to "NIU 90-302" in the last row of the coding.

Change the third paragraph ("All messages ...") to: "All messages in this standard contain the functional

type of information elements. Functional information

elements are characterized as requiring a degree of

intelligent processing by the Customer Premise

Equipment (CPE) in either their generation or

analysis."

Delete the fifth paragraph ("As a general ..."), the

second Note of the section, and the seventh

paragraphs ("In addition ...").

Change "ANSI T1.602" to "NIU 89-210" in the last sentence.

Change the last sentence of the first paragraph to: "The Bearer capability information element is mandatory in the SETUP message."

Change the third paragraph to: "Furthermore, the

SETUP message shall also contain all of the call information (i.e., address and facility requests)

necessary for call establishment."

Delete the following from the fourth paragraph: "b)

the Keypad information ... other call information,"

and the Note ("All networks are ...").

Delete the last paragraph ("For overlap ...").

B-22 NIU-Forum Agreements on ISDN
Section 5.1.2

B -channel selection — originating

Delete the following from the first paragraph: "c) any

channel ... alternative c) is assumed."

Section 5.1.2

B-channel selection

Section 5.1.2

B-channel selection

originating

ongmating

Section 5.1.2

B-channel selection — originating

Section 5.1.2

B -channel selection originating

Delete the last sentence from the third paragraph:

case c), the ... with the D-channel."

"In

Change the end of the first sentence in the fourth

paragraph from "(i.e., a SETUP ACKNOWLEDGE or CALL PROCEEDING message)." to "(i.e., a CALL

PROCEEDING message)."

Change the fifth paragraph to: "The user need not

attach until receiving a: a) CALL PROCEEDING, b)

ALERTING message with the progress indicator 8

'in-band information or appropriate pattern is now

available' or c) a PROGRESS message with the

progress indicator 1 'call is not end-to-end ISDN;

further call progress information may be available in- band'. Prior to this time, the network cannot assume

that the user has attached ... (if it has not already

done so)."

Change the first sentence of the last paragraph to:

"In case a), if the specified channel is not available,

and in case b) if not channel is available, a RELEASE COMPLETE message with a cause value

of 44 'requested circuit/channel not available' or 34

'no circuit/channel available', respectively, is sent by

the network as described in 5.3."

Section 5.1.3

Overlap sending

Delete this section.

Section 5.1.4

Invalid call information

Change the first sentence in the first paragraph to:

"If, following the receipt of the SETUP message, the

network determines ... cause such as the following:".

Section 5.1.4

Invalid call information

Add the following to the end of the first paragraph

after "28 ...": "82 'identified channel does not exist'."

Section 5.1.5.1

Call proceeding, en-bloc sending

Add the following to the second paragraph after "58

...": "34 'no circuit/channel available'."

Section 5.1.5.2

Call proceeding, overlap sending

Section 5.1.6

Nofification of interworking at the originating

interface

Delete this section.

Change "a) ..." in the first paragraph to: "a) in an

appropriate call control message when a state change

is required (CONNECT); or,".

NIU-Forum Agreements On ISDN B-23
Section 5.1.6

Notification of interworking at the originating

interface

Section 5.1.6

Notification of interworking at the originating

interface

Section 5.1.6

Notification of interworking at the originating

interface

Section 5.1.6

Notification of interworking at the originating

interface

Section 5.1.7

Call confirmation indication

Section 5.2

Call establishment at the destination interface

Section 5.2.1

Incoming call

Section 5.2.1

Incoming call

Section 5.2.1

Incoming call

Section 5.2.1

Incoming call

Section 5.2.1

Incoming call

Section 5.2.1

Incoming call

Add to the end of "1 ..." in the second paragraph

"(i.e., in a PROGRESS message); or,".

Change "2 ..." in the second paragraph to: "2

'destination address is non-ISDN' (i.e., in a CONNECT message);".

Delete "4 ... end-to-end ISDN" from the second

paragraph.

Delete "or more" from the second part of the first sentence in the fourth paragraph.

Change the last sentence in the first paragraph to: "When the user receives the ALERTING message, the user shall enter the Call Delivered state."

Delete the last sentence of the third paragraph ("No

use ...").

Delete the last two sentences of the first paragraph.

Change the last part of the second paragraph from

"(e.g., Display, Low layer compatibihty)." to "(e.g..

Low layer compatibility.)".

Add the following to the end of the second paragraph:

"In general, a call terminating from a non-ISDN line or from a Public Switched Telephone Network

(PSTN) trunk should be offered to the called user equipment with the 3.1 kHz audio bearer capability."

Delete the first and second sentences of the third

paragraph. Delete "However, if ... the interface" from

tiie third sentence. The third paragraph will now

read: "A point-to-point data link shall be used to carry the SETUP message. After sending the SETUP

message, the network starts timer T303."

Delete the fifth paragraph and the Note following this paragraph.

Change the second part of the last sentence in the

seventh paragraph from "timers T303 and T312 are

restarted." to "timer 303 is restarted."

B-24 NIU-Forum Agreements on ISDN
Section 5.2.2

Compatibility checking

Section 5.2.3.1

SETUP message delivered by point-to-point data link

Section 5.2.3.1

SETUP message delivered by point-to-point data link

Section 5.2.3.1

SETUP message delivered by point-to-point data link

Section 5.2.3.1

SETUP message delivered by point-to-point data link

Section 5.2.3.2

SETUP message delivered by broadcast data link

Section 5.2.5.1

Response to en-bloc SETUP

Section 5.2.5.1

Response to en-bloc SETUP

Section 5.2.5.2

Receipt of CALL PROCEEDING and ALERTING

Section 5.2.5.2

Receipt of CALL PROCEEDING and ALERTING

Section 5.2.5.2

Receipt of CALL PROCEEDING and ALERTING

Delete the second paragraph ("When the SETUP

message ...").

Delete the following from the first paragraph under

"a) "3) any channel is acceptable."

Delete the paragraph under "b) ...." that reads "In case

3), ...."

Change the first sentence in the third paragraph under

"b)" to: "If in case 1) the B-channel indicated in the

first response message is not the channel offered by

the network, or in case 2) the B-channel indicated in the first response message is unacceptable to the

network, it will clear the call by sending a RELEASE

message with cause 6 'channel unacceptable' (see

5.3.2 d)."

Change the first part of "e) ..." to: "e) In case 1) if

the indicated B-channel is not available, or in case 2)

if no B-channel is available

Delete this section.

Change the first sentence of the Note to: "A Progress

indicator information element may be included in a CONNECT message (e.g., when an analogue terminal

is connected to an NT2 functional grouping)."

Delete the second paragraph ("When the SETUP

message was delivered via a broadcast ...").

Delete the first paragraph ("When the SETUP

message is delivered on a broadcast ...").

Change the second paragraph to: "Upon receipt of

the first CALL PROCEEDING message from a user, the network shall: stop timer T303; start time T310;

and enter the incoming Call Proceeding state."

Delete the fourth paragraph ("When the SETUP

message was delivered via a broadcast ...").

NIU-Forum Agreements On ISDN B-25
Section 5.2.5.2

Receipt of CALL PROCEEDING and ALERTING

Section 5.2.5.2

Receipt of CALL PROCEEDING and ALERTING

Section 5.2.5.3

Called user clearing during Incoming call establishment

Section 5.2.5.3

Called user clearing during Incoming call establishment

Section 5.2.5.3.1

DISCONNECT received prior to expiry of T312

Section 5.2.5.3.2

DISCONNECT received after expiry of Umer T312

Section 5.2.5.4

Call failure

Section 5.2.5.4

Call failure

Section 5.2.5.4

Call failure

Section 5.2.5.4

Call failure

Section 5.2.5.4

Call failure

Section 5.2.5.4

Call failure

Section 5.2.5.4

Call failure

Change the fifth paragraph to: "Upon receipt of the

ALERTING message from a user, the netvk'ork shall: stop Umers T303 or T310 (if running) and TDEL (if

running); start optional timer T301 (unless another

internal alerting supervision timer function exists; w.g.

incorporated in call control); enter the Call Received

state; and send a corresponding ALERTING message

to the calling user."

Delete the sixth paragraph ("When a SETUP message

has been delivered on a broadcast link ...").

Change the first part of the first paragraph to: "If the

RELEASE COMPLETE or DISCONNECT message

is received

Delete the second and third paragraphs.

Delete this section.

Delete this section.

Delete the following from the first paragraph: "a) If the SETUP message ... Call Abort state;"

Change "b)" in the first paragraph to: "b) The

network shall also initiate clearing procedures toward

the called user in accordance with 5.3.4, using cause 102 'recovery on timer expiry'."

Delete the second paragraph ("If the network receives

...").

Delete the following from the third paragraph: "a) If

the SETUP ... shall be sent."

Change "b)" in the third paragraph to: "b) The called user shall be cleared in accordance with 5.3.4, using cause 102 'recovery on timer expiry'."

Change the beginning of the first sentence in the

fourth paragraph to: "If the network supports timer

T301 and has received a ALERTING message

"

Delete from the fourth paragraph: "a) If the SETUP

message was ... shall be sent."

B-26 NIU-Forum Agreements on ISDN
Section 5.2.5.4

Call failure

Section 5.2.6

Notification of interworking at the terminating

interface

Section 5.2.6

Notification of interworking at the termination

interface

Section 5.2.7

Call accept

Section 5.2.8

Active indication

Section 5.2.9

Non-selected user clearing

Section 5.3.2

Exception conditions

Section 5.3.2

Exception conditions

Section 5.3.2

Exception conditions

Section 5.4

In-band tones and announcements

Change "b)" in the fourth paragraph to: "b) The

called user shall be cleared in accordance with 5.3.4,

using cause 102 'recovery on timer expiry'."

Change the first item in the list in the second

paragraph from: " — in an appropriate ..." to:

" — in an appropriate call conU"ol message when a state change is required (CONNECT); or,".

Delete the third item from the list in the third

paragraph: "4 Call has

Add the following to the end of the last paragraph:

"If the CONNECT message is the first response to the

SETUP message, it shall contain the channel

identification information element."

Delete the fourth paragraph ("A user that has received

the SETUP via the broadcast data link ...").

Delete this section.

Change in the first paragraph "a)" to: "a) In response

to a SETUP message, the user or network can reject a call (e.g., because of the unavailability of a suitable

B-channel) by: responding with a RELEASE

COMPLETE message provided no other response has

previously been sent releasing; the call reference and

entering the Null state."

Delete from the first paragraph: "b) In the case ... user clearing".

Delete from the first paragraph e)l) and e)2) and the

Note at the end of the section.

Change the title of this section to "In-band audible

ringing tone and announcements".

NIU-Forum Agreements On ISDN B-27
Section 5.4

In-band tones and announcements

Change the tlrst paragraph to: "It is assumed that the

originating Class II device will provide a busy tone

and a reorder tone to the calling user for speech and

3.1 kHz calls. The network will not provide in-band

busy or reorder tone. When in-band audible ringing

tone/announcements not associated with a call state change are to be provided by the network before

reaching the Active state, a PROGRESS message is returned simultaneously with the application of the in- band audible ringing tone/announcement. The

PROGRESS message contains the progress indicator

8 'in-band information or appropriate pattern is now

available'."

Section 5.4 Change the second paragraph to: "When an audible

in-band tones and announcements ringing tone has to be provided together with a ... is sent simultaneously with the application of the inband

audible ringing tone."

Section 5.4 Delete Note 1. in-band tones and announcements

Section 5.4

in-band tones and announcements

Change Note 2 to: "When the PROGRESS message

is used, the user may initiate call clearing as a result of the applied in-band audible ringing tone/

announcement, according to procedures specified in

5.3.3."

Section 5.5

Restart procedure

Delete from the second paragraph "b) the interface is a ... exists; or,".

Section 5.5.2

Receipt of RESTART

Change in Note 2 the reference to "ANSI T1.602" to "NIU 89-210".

Section 5.5.2

Receipt of RESTART

Change in Note 2 "b)" to: "b) that correspond to the

specified channel or interface."

Section 5.7

Call collisions

Delete the Note at the end of the section.

Section 5.8.2

Message too short

Section 5.8.4

Message type or message sequence errors

Section 5.8.7.2

Non-mandatory information element content error

Change this paragraph to: "When a message is received that is too short (less than 4 octets) to contain a complete message type information element,

that message shall be ignored."

Add the following after the first paragraph: "The

NOTIFY message may be ignored by the recipient."

Delete the last sentence of the second paragraph

("However, in some ...").

B-28 NIU-Forum Agreements on ISDN
Section 5.8.8

Data link reset

Section 5.8.9

Data link failure

Section 5.8.9

Data link failure

Section 5.9

User notification procedure

Section 9.1

Timers in the network side

Table 22 — Timers in the network side

Section 9.1

Timers in the network side

Table 22 — Tuners in the network side

Section 9.1

Timers in the network side

Table 22 — Timers in the network side

Section 9.1

Timers in the network side

Table 22 — Timers in the network side

Section 9.1

Timers in the network side

Table 22 — Timers in the network side

Section 9.2

Timers in the user side

Table 23 — Timers in the user side

Section 9.2

Timers in the user side

Table 23 — Timers in the user side

Section 9.2

Timers in the user side

Table 23 — Timers in the user side

Section 9.2

Timers in the user side

Table 23 — Timers in the user side (Part 2)

Annex A — SDL diagrams

Delete from the first paragraph: "a) For calls in the

Overlap ... procedures of 5.3".

Delete from the first paragraph the first sentence of

"a) ..." ("The calls in the ... internally.").

Delete the second sentence of the Note following the

first paragraph ("Note — If tbe transfer mode ....").

Delete this section.

Delete row "T302".

Delete the second sentence in the "T310/NORMAL

STOP" cell ("If DISCONNECT ...").

Delete rows "T312" and "T321".

Delete Notes 4 and 5.

Add the following to the end of Note 6: "(see Annex

D)".

Delete the following rows:

• "T301";

• "T304".

Delete "SETUP ACKNOWLEDGE" from the "T303/

NORMAL STOP" cell.

Delete the reference to "Note 4" in the "T310AriMER

NUMBER" cell.

Delete Notes 3 and 4.

Delete this section. NOTE: This section has not

been addressed.

NIU-Forum Agreements On ISDN B-29
Section B.3.1

Compatibility checking with addressing information

Section B.3.4

User action figures

Figure B.l — Bearer capability compatibility

checking

Figure B.2 —Low layer and high layer compatibiUty

checking; compatibiUty assured

Section B.3.4

User action figures

Figure B.l — Bearer capability compatibility

checking

Figure B.2 — Low layer and high layer compatibility

checking; compatibiUty assured

Section B.3.4

User action figures

Figure B.3 — Low layer and high layer compatibility

checking; compatibiUty not assured

Section B.3.4

User action figures

Annex C, Section C.l

Introduction

Annex C, Section C.2

Selection Not Supported

Annex C, Section C.3

Selection Supported

Annex C, Section C.3

Selection Supported

Annex C, Section C.3

Selection Supported

Annex C, Section C.3

Selection Supported

Annex D

Extensions for Symmetric Call Operation

Delete Note 2 ("If an incoming call, ... or

subaddress.").

Delete the reference to "(Note 1)" from the cell in the

first row of the second column.

Delete the "broadcast data link" column.

Delete the reference for "(Note 1)" in the cells in the

first row of the second and third columns.

Delete Notes 1 and 3 (ed. note: Note 3 is still referenced in the figures).

Delete "optional" from the first paragraph.

Delete this section.

Change the first paragraph to: "The user identifies

the selected transit network in the SETUP message.

One Transit network selection informauon element is used to convey a single network idenufication."

Delete the second ("The user may ..."), third ("As the

call ..."), and fourth ("No more than ...") paragraphs.

Delete the last sentence of the sixth paragraph ("The

diagnosuc ...").

Delete the seventh ("A network may ...") and eighth

("If the transit ...") paragraphs.

Delete Annex D and replace with Attachment E of

this document.

B-30 NIU-Forum Agreements on ISDN
Annex E, Section E.3

Routing Not Supported

Add the following paragraph before at the end of this

section: "When the requested facility can not be

provided an indication shall be returned in the first clearing message with cause 29 'facility rejected'."

Annex E, Section E.4

Routing Supported

Annex E, Section E.4

Routing Supported

Annex F

D-channel Backup Procedure

Change the first sentence in the fourth paragraph to: "No more than two Network-specific facilities information elements may be used in a SETUP

message."

Delete the last sentence of the fifth paragraph ("The

diagnostic ...").

Delete this Annex.

Annex G, Section G.l

Introduction

Add the following to the end of the first paragraph:

"Section 4.5. 11 identifies the causes supported in NIU

90-302."

Annex G, Section G.3.8

Cause 46 "precedence call blocked"

Change "precedence circuits" to "preemptable

circuits".

Annex H, Section H.l

Introduction

Change the first paragraph to: "These are the only

recognized codings of the following information

elements."

Annex H, Section H.l

Introduction

Annex H

Examples of Information Elements Coding

Delete the last two bullet items from the second

paragraph.

Delete the following figures and sections:

• Figure "H.3 Coding for 7kHz Audio";

• Figure "H.6 Coding for synchronous 1472 kbit/s";

• Section H.3 Channel identification information

element;

• Section H.4 Called and Calling party subaddress

information element.

Annex I Use of Progress indicators

Annex I Use of Progress indicators

Annex I Use of Piogress indicators

Annex M

Low Layer Compatibility Negotiation

Delete the fifth paragraph ("Progress indicator 4 ...").

Delete "or basic" from the left side of Figure 1.1 (between the TE and ISDN).

Delete "or basic" from the right side of Figure I.l (between ISDN and NT2).

Delete this Annex.

NIU-Forum Agreements On ISDN B-31
Annex N

Procedures for Establishment of Bearer Connection

Prior to Call Acceptance

Annex O

Optional Procedures for Bearer Service Change

Annex P, Section P.l

Introduction

Annex P, Section P.l

Introduction

Annex P, Section P.l

Introduction

Annex P, Section P.2

Operator system access requested in Keypad facility

information

Section P.4

invalid request

Annex Q

Responding address requirements of the OSI network

layer service

Delete this Annex and replace with Attachment F of

this document.

Delete this Annex.

Delete "optional" from the first sentence in the first paragraph.

Change the last sentence of the first paragraph to: "These procedures apply to the speech, and 3.1 kHz

and audio bearer services."

Change the second paragraph to: "The user may

indicate a request for access to an operator or attendant system using the Operator system access information element."

Delete this section.

Delete this section.

Delete this Annex.

B-32 NIU-Forum Agreements on ISDN
Attachment A

(of Appendix B)

1. General

1.1 Scope and Purpose

This Implementation Agreement specifies a minimal subset of procedures and codepoints from the American National

Standards Tl .607- 1990 (Ref. [17]) for the establishment, maintenance, and clearing of ISDN connections at the user- to-network interface. This signalling standard is used to support the circuit-switched bearer services specified in ANS

Tl.604- 1990*.

Terminals are not required to support all services. Switches will support all of the mandatory protocols and

codepoints in this implementation agreement. This does not preclude the support of additional services and

procedures. However, equipment must be able to interoperate with equipment supporting only this minimal subset.

1.1.1 Definitions

The ANS Tl.607-1990 (Ref. [17]) assumes that procedures apply generically to ISDN access interfaces, i.e., the

document does not distinguish between basic and primary rates access interfaces. In addition, there are no references

to specific applications in that document. The concept of equipment classes is introduced in this document to permit

certain procedures to be associated with a particular application or class of equipment, e.g., station equipment versus PBX. Specifically, two classes of equipment are defined on the basis of two fundamental attributes.

The first attribute relates to the possibility of an exchange of signals occurring beyond the public network's point

of contact with the interface (i.e., between the equipment directly connected to the public network and ISDN

terminals or telephones connected to that equipment). For example, some user equipment may support subtending

Basic Access digital subscriber loops and/or analog telephone loops. For Class 1 equipment, the network makes no

provision for such an arrangement and assumes the Class I equipment constitutes the endpoint of the communication.

Conversely, in the case of Class II equipment, the procedures at the network take into account that conmiunication

between Class II equipment (with which it conmiunicates directly) and other equipment (with which the network does

not have direct contact) may occur. As an example, Class II equipment may support digital and/or analog subscriber

loops. Use of Class II equipment also involves the possibility of having interworking occur beyond the equipment

with which the network has direct contact. Therefore, it is reasonable for Class II equipment to provide the network

with an interworking notification, for both outgoing and incoming calls, when either the calling or called party

respectively, is a non-ISDN user. Class II equipment may also send an interworking notification if a private network

exists beyond the Class II equipment and interworking to a non-ISDN facility within that network takes place. When

an interface is associated with Class I equipment, it is assumed the multiple pieces of equipment may exist and

communicate with the network over the D-channel. However, in this case, all equipment is assumed to be ISDNcapable and is considered as the endpoint of the communication. Therefore, interworking notification should not be

accepted from Class I equipment.

The second attribute relates to the manner in which a SETUP message should be presented to the user equipment.

When Class I equipment is applied on a particular interfaces, the network should broadcast the SETUP message

associated with each call that terminates on that interface, since interaction between the network and multiple pieces

of user equipment should be supported. On the other hand, the network should not broadcast SETUP messages

associated with terminating calls to an interface on which Class II equipment is being used. Here, a single piece

of user equipment is assumed to be involved in all conununication with the network.

'Subject to further discussion.

NIU-Forum Agreements On ISDN B-33
To the extent possible, it is desirable to have one set of requirements for ISDN call control apply to all ISDN user configurations. However, in cases for which integrated procedures are not appropriate, the call control procedures

associated with Equipment Class I will differ from those associated with Equipment Class II. Unless otherwise

noted, the assumption should be that a particular procedure/capability should be provided for both classes of

equipment on both basic and primary rate access. However, use of the equipment class terminology permits

clarification of the circumstances under which a certain capability should be available (i.e., when a particular

equipment class is in use). It also permits a mechanism for indicating that a particular capability applies only to a

subset of four possible configurations which are labeled as follows.

Class I Class II

IB IIB

IP IIP

In other words, a capability that applies to Class I equipment may be provided on basic access interfaces (IB) and/or

primary rate access interfaces (IP). Similarly, a capability that applies to Class II equipment may be provided on

basic access interfaces (IIB) and/or primary rate access interfaces (IIP).

The notation shown in the table above is used within this implementation agreement to indicate when protocol or procedures are only expected to be supported for a particular equipment class and/or are limited to a particular type

of interface, i.e., basic or primary rate interface.

B-34 NIU-Forum Agreements on ISDN
Attachment B

(of Appendix B)

The various parts of the called party number information element should be coded as follows: — Type of number and numbering plan (octet 3)

Bits

7 6 5 4 3 2 1 Meaning

0 0 0 0 0 0 0 Unknown

0 0 1 0 0 0 1 International number in ISDN numbering plan (Rec. E.164)

0 1 0 0 0 0 1 National number in ISDN numbering plan (Rec. E.164)

1 0 0 0 0 0 1 Local (directory) number in ISDN numbering plan (Rec. E.164)

All other values are reserved

— Digits (octet 4, etc.)

Bits

7 6 5 4 3 2 1 Meaning

0 1 1 000 0 0

0 1 1 0 0 0 1 1

0 1 1 0 0 1 0 2

0 1 1 0 0 1 1 3

0 1 1 0 1 0 0 4

0 1 1 0 1 0 1 5

0 1 1 0 1 1 0 6

0 1 1 0 1 1 1 7

0 1 1 1 00 0 8

0 1 1 1 00 1 9

All other values are reserved

Digits should be represented by IA5 characters whose encoding is shown above.

In the network to user direction (n -> u), this IE will be always signaled in the SETUP message, and public network

interfaces will use only one codepoint: local number in ISDN. For private networks, this IE can contain the

following codepoints: abbreviated type of number, and private numbering plan, and extra digits such A, B, C, and

D (as per IA5).

NIU-Forum Agreements On ISDN B-35
Attachment C

(of Appendix B)

The various parts of the calling party number information element should be coded as described below. — Type of number and numbering plan (octet 3) follows:

Bits

7 6 5 4 3 2 1 Meaning

0 0 0 0 0 0 0 Unknown

0 0 1 0 0 0 1 International number in ISDN numbering plan (Rec. E.164)

0 0 1 0 0 1 1 International number in data numbering plan (Rec. X.121)

0 1 0 0 0 0 1 National number in ISDN numbering plan (Rec. E.164)

1 0 0 0 0 0 1 Local (directory) number in ISDN numbering plan (Rec. E.164)

110 10 0 1 Abbreviated Number in Private Numbering plan

All other values are reserved

Origin of number and presentation status (octet 3a) follows:

Bits

7 6 5 4 3 2 1 Meaning

0 0 0 0 0 0 0 Presentation allowed of user-provided number,

number not screened

0 0 0 0 0 0 1 Presentation allowed of user-provided number,

number passed network screening

0 0 0 0 0 1 0 Presentation allowed of user-provided number,

number failed network screening

0 0 0 0 0 1 1 Presentation allowed of network-provided number

0 1 0 0 0 0 0 Presentation prohibited of user-provided number,

number not screened

0 1 0 0 0 0 1 Presentation prohibited of user-provided number,

number passed network screening

0 1 0 0 0 1 0 Presentation prohibited of user-provided number,

number failed network screening

0 1 0 0 0 1 1 Presentation prohibited of network-provided number

1 0 0 0 0 1 1 Number not available

All other values are reserved

Note 1 — When octet 3a is omitted, the default value of the Number Presentation parameter for the signaled DN

value should be used, if it is available. If a value for this parameter is unavailable (i.e., the signaled DN value either

fails screening or is not screened by the SPCS), the presentation parameter value of the default DN should be used.

Note 2 — Octet 3a, bits 7 & 6, are for the Presentation indicator; bits 2 & 1 are for the screening indicator.

B-36 NIU-Forum Agreements on ISDN
— Digits (octet 4, etc.)

Digits should be represented by IA5 characters whose encoding is shown below:

Bits

7 6 5 4 3 2 1 Meaning

0 1 1 0000 0

0 1 1 0 0 0 1 1

0 1 1 0 0 10 2

0 1 1 00 11 3

0 1 1 0 10 0 4

0 1 1 0 10 1 5

0 1 1 0 110 6

0 1 1 0 111 7

0 1 1 100 0 8

0 1 1 100 1 9

All other values reserved

Codings At Originating Party Interface

The calling party number information element should only be accepted when in the SETUP message. When the type

of number and numbering plan indicator indicates "local number in the ISDN (E.164) numbering plan," the calling

party number information element should contain a 7-digit local number. When the type of number and numbering

plan indicator indicates "national number in the ISDN (E.164) numbering plan" the calling party number information

element should contain a 10-digit national number.

In the network to user direction (n -> u). the coding and delivery of this IE depends on the definition of the Calling

Line ID service. For private networks, this IE can contain the following codepoints: abbreviated type of number,

and private numbering plan, and extra digits such as A, B, C, and D. (as per IE5)

NIU-Forum Agreements On ISDN B-37
Attachment D

(of Appendix B)

Network — Specific facilities Information Element Examples

One recommended use for the Network Specific Facilities information element is to indicate which type of network

facilities are being invoked at the specified network. In this arrangement, many different facility types are allowed

to share a single Primary Rate Interface. Examples of the different DS-1 facility types allowed are:

Private Lines

Inwats Circuits

Outwats Circuits

Foreign Exchange (FX)

Tie Trunks

B-38 NIU-Forum Agreements on ISDN
Attachment E

(of Appendix B)

(editor's note: the sections contained in the parentheses are unchanged from the original Annex D)

Annex D — Extensions for symmetric (peer-to-peer) call operation

This annex is part of NIU 90-302.

Symmetric call operation, or peer-to-peer call operation, shall be applied to the switches within a private network

where all switches, such as PBXs and central office switches serving business group users are considered as peers.

For example, PBX-to-PBX, PBX-to-Centrex, Centrex-to-Centrex.

D. 1 Additional message handling

(In symmetric applications, the SETUP message will contain a Channel Identification information element indicating a particular B -channel to be used for the call. A point-to-point data hnk shall be used to carry the SETUP message.)

The following procedures shall be followed for symmetrical operation. The call control states followed should be

the symmetric states defined in section D.6.

D.1.1 Call Request

The initiator of the call shall follow the network side procedures described in section 5.2.1.

D.1.2 B-channel Selection — symmetric interface

(Only B-channels controlled by the same D-channel will be the subject of the selection procedure. The selection

procedure is as follows:

a) The SETUP message will indicate one of the following:

1) channel is indicated, no acceptable alternative, or

2) channel is indicated, any alternative is acceptable.

b) In cases 1) and 2), if the indicated channel is acceptable and available, the recipient of the SETUP

message reserves it for the call. In case 2), if the recipient of the SETUP message cannot grant

the indicated channel, it reserves any other available B-channel associated with the D-channel.)

c) The recipient of the SETUP message indicates the selected B-channel in a CALL PROCEEDING,

message fransferred across the interface and enters the Incoming Call Proceeding state. If an ALERTING or a CONNECT message is received in response to a SETUP message, the call should

continue to be processed, if the channel indicated is acceptable to the initiator of the call, in accordance with sections D. 1.5.1 and D.1.8, respectively. Although these are acceptable responses, a CALL PROCEEDING message is the recommended response to a SETUP message.

d)

e) In case 1) if the indicated B-channel is not available, or in case 2) if no B-channel is available, a RELEASE COMPLETE message with a cause value of No. 44 "requested circuit/channel not

NIU-Forum Agreements On ISDN B-39
available" or No. 34 "no circuit/channel available" respectively is returned to the initiator of the

call. The sender of this message remains in the Null state.

f) If the channel indicated in the CALL PROCEEDING, message is unacceptable to the initiator of

the call, it clears the call in accordance with section 5.3. If an ALERTING or a CONNECT

message is received in response to a SETUP message and the channel indicated is unacceptable

to the initiator of the call, it clears the call in accordance with section 5.3. Although these are acceptable responses, a CALL PROCEEDING message is the reconmiended response to a SETUP

message.

D.1.3 Invalid Call Information

The recipient of a SETUP message shall follow the network side procedures described in section 5.1.4.

D.1.4 Compatibility Checking

The recipient of a SETUP message shall follow the user side procedures described in section 5.2.2.

D.1.5 Call Confirmation

Upon receipt of a SETUP message, the equipment enters the Call Present state. Valid responses to the SETUP

message are a CALL PROCEEDING, or a RELEASE COMPLETE message. If an ALERTING or a CONNECT

message is received in response to a SETUP message, the call should continue to be processed, if the channel

indicated is acceptable to the initiator of the call, in accordance with sections D. 1.5.1. and D.1.8, respectively.

Although these are acceptable responses, a CALL PROCEEDING message is the recommended response to a SETUP

message.

If the indicated channel is acceptable to the initiator of the call, the initiator shall attach to the indicated B-channel

according to the procedures in Annex N.

D.L5.1 Receipt of CALL PROCEEDING and ALERTING

The Initiator of a call shall follow the network side procedures in section 5.2.5.2.

D.1.5. 2 Clearing during incoming call establishment

The initiator of a call shall follow the network side procedures in section 5.2.5.3.

D.1.5.3 Call Failure

The initiator of a call shall follow the network side procedures in section 5.2.5.4.

D.1.6 Clearing by the called user employing user-provided tones/announcements

When tones or announcements are provided in conjunction with call clearing, the party providing the in-band

treatment shall send a PROGRESS message.

D.1.7 Call Accept

The recipient of the call shall follow the user side procedures in section 5.2.7.

B-40 NIU-Forum Agreements on ISDN
D.1.8 Active indication

Upon receipt of a CONNECT message, the initiator of the call shall respond with a CONNECT ACKNOWLEDGE

message and enter the Active State (see sec. 5.2.8 network side procedures).

D.I.9 Call Clearing

D. 1.9.1 Normal Call Clearing

Then sender of the DISCONNECT message shall follow the user side procedures in section 5.3.3. The recipient of

the DISCONNECT message shall follow the network side procedures in section 5.3.3.

D.2 Timers for call establishment

The timers described in section 9 table 7 shall be implemented along with the corresponding procedures for action's

taken upon expiration of these timers. The default of T310 should be extended to 20 seconds. In addition, timer

T309 shall be mandatory.

D.3 Call collisions

In synunetric arrangements, call colUsions can occur when both sides simultaneously transfer a SETUP message

indicating the same channel. In the absence of administrative procedures for assignment of channels to each side

of the interface, the following procedure is employed.

First, one side of the interface will be designated the "controlling function" and the other side of the interface will

be designated the "responding function." This can be accomplished by administering the Layer 2 Command/

Response bit. The controlling function is assigned "command" and has control of all the channels on the interface.

The responding function is assigned "response." Second, for the three possible scenarios where the same channel

is indicated by combinations of preferred and exclusive from the responding function and controlhng function, the

following procedure is used:

a) "controlling function" preferred, "responding function" preferred:

The "controlling function" preferred channel is awarded and an alternate channel is indicated in the first response to the "responding function" SETUP message.

b) "controlling function" exclusive, "responding function" exclusive:

The "controlling function" exclusive channel is awarded and the "responding function" SETUP

message is cleared with a RELEASE COMPLETE message with cause No. 34 "no circuit/channel

available".

c) "controlling function" preferred, "responding function" exclusive; or "controlling function"

exclusive, "responding function" preferred:

The side of the interface with an exclusive indicator in a SETUP message is awarded the channel

and an alternate channel is indicated in the first response to the side using a preferred indicator in the SETUP message.

Channel identification is allowed in both directions for ALERTING and CONNECT.

NIU-Forum Agreements On ISDN B-41
DA Restart Procedures

See section 5.5.

D.5 Handling of Error Codes

See section 5.8.

D.6 Call control states for symmetric call operation

The state below are used in association with call references other than the global call reference, and apply to symmetric interfaces. The Outgoing side is the side of the symmetric interface that transmits the SETUP message,

while the incoming side is the recipient of the SETUP message.

D.6.1 Null State (SO)

No call exists.

D.6.2 Call Initiated (SI)

This state exists for an outgoing call when the Outgoing Side has sent a request for call establishment to the

Incoming Side but has not yet received a response.

D.6. 3 Outgoing Call Proceeding (S3)

This state exists for an outgoing call when the Outgoing Side has received acknowledgment that the Incoming Side

has received all call information necessary to effect call establishment.

D.6.4 Call Delivered (S4)

This state exists for an outgoing call when the Outgoing Side has received from the Incoming Side an indication that

the called user is being alerted.

D.6.5 Call Present (S6)

This state exists for an incoming call when the Incoming Side has not yet responded to the request from the

Outgoing Side for call establishment.

D.6.6 Call Received (S7)

This state exists for an incoming call when the Incoming Side has indicated to the Outgoing Side that the called user

is being alerted.

D.6. 7 Connect Request (S8)

This state exists for an incoming call when the Incoming Side has indicated to the Outgoing Side that the called user has answered the call.

D.6.8 Incoming Call Proceeding (S9)

NIU-Forum Agreements on ISDN

i

I

i
This state exists for an incoming call when the Incoming Site has sent to the Outgoing Side acknowledgment that

it has received all call information necessary to effect call establishment.

D.6.9 Active (SIO)

This state exists for an incoming call when the Incoming Side has received from the Outgoing Side an acknowledgment of the indication that the called user has answered the call. This state exists for an outgoing call when the Outgoing Side has received from the Incoming Side an indication that the called user has answered the

call.

D.6.10 Disconnect Request (SI 1)

This state exists when a Side has sent to the other Side a request to disconnect the user information connection and

is waiting for a response.

D.6.11 Disconnect Indication (SI2)

This state exists when a Side has received from the other Side a request to disconnect the user information

connection and has not yet responded.

D.6.12 Release Request (S19)

This state exists when a Side has sent to the other Side a request to release the call and has not yet received a

response.

NIU-Forum Agreements On ISDN B-43
Attachment F

(of Appendix B)

Annex N — Procedures for Establishment of Bearer Connection Prior to Call Acceptance

This annex is part of NIU 90-302.

N.l General

For some applications, it is desirable to allow the completion of the transmission path associated with a bearer service

prior to receiving call acceptance. In particular, the completion of the backward direction for non-peer

communication or both directions for peer-to-peer communication (see Annex D for peer-to-peer call operation) of

the transmission path prior to receipt of a CONNECT message from the called user may be desirable to:

1) allow the called user to provide internally-generated tones and announcements that are sent in-band

to the calling user prior to answer by the called user; or,

2) avoid speech clipping on connections involving an NT2 where delays may occur in relaying the answer indication within the called user equipment.

The procedures described in this annex are applicable to the speech and 3.1 kHz audio bearer services, for non-peer

communication of both directions for peer-to-peer communication (see Annex D for peer-to-peer call operation).

N.2 Procedures

Completion of the transmission path prior to receipt of a call acceptance indication shall be provided in three ways:

1) For peer-to-peer communications on receipt of a CALL PROCEEDING message or an ALERTING

message indicating completion of successful channel negotiation.

2) For non-peer communication on receipt of an ALERTING message; and

3) For non-peer communications on receipt of a PROGRESS message.

When criteria (1) is used to determine that a U"ansmission path should be established, the sender of the SETUP

message shall connect, both directions of the transmission path upon receipt of either a CALL PROCEEDING

message or an ALERTING message containing an acceptable B -channel indication.

When criteria (2) is used to establish the transmission path, the network shall connect, the backward direction of the

transmission path upon receipt of an ALERTING message assuming channel negotiation procedures have been

successful.

When criteria (3) is used to establish the U"ansmission path, the network shall connect, the backward direction of the

transmission path upon receipt of a PROGRESS message containing progress indicator 1 "call is not end-to-end

ISDN; further call progress information may be available in-band," assuming that the user has already returned a CALL PROCEEDING message and channel negotiation procedures have been successful.

If an ALERTING message follows a PROGRESS message containing progress indicator 1, it should be treated as an unexpected message.

B-44 NIU-Foruiii Agreements on ISDN
The network may choose to further restrict when message(s) will result in establishment of the transmission path.

These restrictions may be imposed on a per interface basis to provide an administrative means for limiting potential

misuse of the early connection capabilities.

NIU-Forum Agreements On ISDN B-45
4
Acronyms

3PTY Three Party Service

ACD Automatic Call Distributor

ACTl Abstract Conformance Test Group for Layer 1 ACT23 Abstract Conformance Test Group for Layers 2 and 3

AE ASI Entity

ALLF Additional Lower Layer Functions

ANS American National Standard

ANSI American National Standards Institute

AOC Advice of Charge

AOW Asian Oceanic Workshop

AP Application Profile

ARS Automatic Route Selection

ACSE Association Control Service Element

ASI Application Software Interface

BLLF Basic Lower Layer Functions

HOC Bell Operating Company

BRA Basic Rate Access

BRI Basic Rate Interface

CCBS Completion of calls to busy subscribers

CCITT International Telephone and Telegraph Consultative Committee

CCR Concurrency, Conmiitment, and Recovery

CD Call Deflection

CFB Call Forward Busy

CFNR Call Forward No Reply

CFU Call Forwarding Unconditional

CLID Calling Line Identification

CLIP Calling Line Identification Presentation

CLIR Calling Line Identification Restriction

CO Central Office

COLP Connected Line Identification Presentation

COLR Connected Line Identification Restriction

CONF Conference calling

COS Corporation for Open Systems

CPE Customer Premises Equipment

CPN Calling Party Number

CRED Credit Card Calling

CSD Circuit-Switched Data

CSV Circuit-Switched Voice

CT Conformance Test

CT Call Transfer

CUG Closed User Group

CVN Call Forwarding No Answer

CW Call Waiting

DCE Data Circuit-Terminating Equipment 7

DN Directory Number

DSSl Digital Subscriber Signalling System Number 1 DTE Data Terminal Equipment

DTP Distributed Transaction Processing

EAMF Equal Access Multi-Frequency

NIU-Forum Agreements On ISDN
ECMA European Computer Manufacturers Association

EDI Electronic Data Interchange

ESCA Exchange Carriers Standards Association

ETSI European Telecommunications Standards Institute EWOS European Workshop for Open Systems

FIPS Federal Information Processing Standard

FTAM File Transfer and Management

FTP File Transfer Protocol

HLDC High-Level Data Link Control

HLF High Level Function

HOLD Call Hold

lA Implementation Agreements

ICOT ISDN Conformance Test

ICS Implementation Conformance Statement

irw ISDN Implementors Workshop

INTAP Interoperability Technical Association Processing

ISDN Integrated Services Digital Network

ISER(M) ISDN Station Event Recording (Module)

ISP International Standardized Profile

ISPICS International Standardized Profiles Implementation Conformance Statement

lUW ISDN Users Workshop

IWF Interworking Functions

LAN Local Area Network

LAPD Link Access Procedure, D-Channel

LLSIG Lower Layer Special Interest Group

MA Messaging and Answering

MCI Malicious Call Identification

MSN Multiple Subscriber Number

MWI Message Waiting Indicator

NA Network Adapter

NFS Network File System

NIST National Institute of Standards and Technology

NIUF North American ISDN Users Forum

NMWG Network Management Expert Working Group

NT Network Termination

NUI Network User Identification

OIW OSI Implementors Workshop

OSI Open Systems Interconnection

pAP proposed Application Profile

PBX Private Branch Exchange

PNP Private Numbering Plan

PRA Primary Rate Access

PRI Primary Rate Interface

PSD Packet-Switched Data

PSN Private Switched Network

REV Reverse Charging

RL Requirments List

RPN Redirecting Paity Number

SAP Service Acces Point

SCAI Switch-Computer Applications Interface

SNA Systems Network Architecture

C-2 NIU-Forum Agreements on ISDN
SPID Station Profile Identification

SPO Standards Promotion Organization

SS Supplementary Service

SS7 Signalling System Number 7

SUB Sub-addressing

SWG Signalling Working Group

TA Terminal Adapter

TE Terminal Equipment

TEI Terminal Endpoint Identifier

TEN Transferred From Number

TP Transaction Processing (Distributed)

TPN Transferred Party Number

TPSE Transaction FYocessing Service Element

TTCN Tree and Tabular Combined Notation

TTN Transferred To Number

UUS User-to-User Signalling

VMS Voice Messaging Systems

VPN Virtual Private Network

WAN Wide Area Network

WG Working Group

/

NIU-Forum Agreements On ISDN

ir us GOVERNMENT PRINTING OFFICE' 1993 -3 hi -9 32/83013

ANNOUNCEMENT OF NEW PUBLICATIONS ON

INTEGRATED SERVICES DIGITAL NETWORK

Superintendent of Documents

Government Printing Office

Washington, DC 20402

Dear Sir:

Please add my name to the announcement list of new publications to be issued in

the series: National Institute of Standards and Technology Special Publication 823-.

Name

Company ^

Address

City State Zip Code

(Notification key N-503)

NISTTechnical Publications

Periodical

Journal of Research of the National Institute of Standards and Technology- Reports NIST

research and development in those disciplines of the physical and engineering sciences in which the Institute is active. These include physics, chennistry, engineering, mathematics, and

computer sciences. Papers cover a broad range of subjects, with major emphasis on

measurement methodology and the basic technology underlying standardization. Also included

from time to time are sun/ey articles on topics closely related to the Institute's technical and

scientific programs. Issued six times a year.

Nonperiodicals

Monographs— Major contributions to the technical literature on various subjects related to the

Institute's scientific and technical activities.

Handbooks- Recommended codes of engineering and industrial practice (including safety

codes) developed in cooperation with interested industries, professional organizations, and

regulatory bodies.

Special Publications -Include proceedings of conferences sponsored by NIST, NIST annual

reports, and other special publications appropriate to this grouping such as wall charts, pocket

cards, and bibliographies.

Applied Mathematics Series - Mathematical tables, manuals, and studies of special interest to

physicists, engineers, chemists, biologists, mathematicians, computer programmers, and others

engaged in scientific and technical work.

National Standard Reference Data Series -Provides quantitative data on the physical and

chemical properties of materials, compiled from the world's literature and critically evaluated.

Developed under a worldwide program coordinated by NIST under the authority of the National

Standard Data Act (Public Law 90-396). NOTE: The Journal of Physical and Chemical

Reference Data (JPCRD) is published bi-monthly for NIST by the American Chemical Society

(ACS) and the American Institute of Physics (AlP). Subscriptions, reprints, and supplements are

available from ACS, 1155 Sixteenth St., NW., Washington, DC 20056.

Building Science Series— Disseminates technical information developed at the Institute on

building materials, components, systems, and whole structures. The series presents research

results, test methods, and performance criteria related to the structural and environmental

functions and the durability and safety characteristics of building elements and systems.

Technical Notes— Studies or reports which are complete in themselves but restrictive in their

treatment of a subject. Analogous to monographs but not so comprehensive in scope or

definitive in treatment of the subject area. Often serve as a vehicle for final reports of work

performed at NIST under the sponsorship of other government agencies.

Voluntary Product Standards -Developed under procedures published by the Department of

Commerce in Part 10, Title 15, of the Code of Federal Regulations. The standards establish

nationally recognized requirements for products, and provide all concerned interests with a

basis for common understanding of the characteristics of the products. NIST administers this

program in support of the efforts of private-sector standardizing organizations.

Consumer Information Series -Practical information, based on NIST research and experience,

covering areas of interest to the consumer. Easily understandable language and illustrations

provide useful background knowledge for shopping in today's technological marketplace.

Order the above NIST publications from: Superintendent of Documents, Government Printing

Office, Washington, DC 20402.

Order the following NIST publications -FIPS and NISTIRs—from the National Technical

Information Service, Springfield, VA 22161.

Federal Information Processing Standards Publications (FIPS PUB) - Publications in this series

collectively constitute the Federal Information Processing Standards Register. The Register serves as the official source of information in the Federal Government regarding standards

issued by NIST pursuant to the Federal Property and Administrative Sen/ices Act of 1949 as amended. Public Law 89-306 (79 Stat. 1127), and as implemented by Executive Order 11717

(38 FR 12315, dated May 11, 1973) and Part 6 of Title 15 CFR (Code of Federal Regulations).

NIST Interagency Reports (NISTIR)-A special series of interim or final reports on work

performed by NIST for outside sponsors (both government and non-government). In general,

initial distribution is handled by the sponsor; public distribution is by the National Technical

Information Service, Springfield, VA 22161, in paper copy or microfiche form.
I"oB

J3u

uH

•o V c w

is M

si

® s OSo

o

CI

e u e|

"ti to

Q g

. .9

3

4)

-«—

O

U 5

O D,