ATT Definity Addendum 1 For Ds1, Dmi, Isdn Pri Instructions Manual

							INTRODUCTION1-5
ISDN-PRILINE SIDE
TRUNK SIDE
PUBLIC NETWORK
4E11DCP INTERFACE
DIGITAL
VOICE TERMINALS
TOLL OFFICEDIGITAL FXWITH
CO
ISDN-PRIWITH(Phase 1)ISDN-PRI
5ESS
DIGITAL CO
WITHISDN-PRISYSTEM 85
R2 V4
WITH
PRIVATE NETWORK
ISDN-PRI
SYSTEM 85
DCP INTERFACE
R2 V4
WITHDATA MODULES
OTHER
ISDN-PRIVENDOR SWITCH
WITH
ISDN-PRI
Figure 1-1. System 85 R2V4 ISDN Configuration
With NFAS, if two or more PRI pipes are present, an optional D-channel backup feature is available.
One D-channel is administered as the primary D-channel on one DS1 and the secondary D-channel on
another DS1. Only one D-channel per primary-secondary pair can be active at a time. If the primary
D-channel fails, the signaling function is switched automatically to the secondary (sometimes called the
backup) D-channel. Without D-channel backup, D-channel failure results in loss of service for all calls
passing through a PRI pipe.½
½
½
½
½
Generic 2 offers ISDN-BRI, however, some BRI capabilities are not initially available. Figure 1-2,
Generic 2 ISDN Network Configuration, shows a Generic 2 switch in a sample network.½
ADDENDUM 1 (December 1990) to 555-025-101, Issue 4 
						

							1-6INTRODUCITON
ISDN-PRI
LINE SIDE
TRUNK SIDE
PUBLIC NETWORK
NFASDCP INTERFACE
DIGITALVOICE TERMINALS
TOLL OFFICE
DIGITAL FX
WTIH 4ESSCO
WITH
ISDN-PRI
DIGITAL CO
WITHDCP INTERFACE
ISDN-PRIDEFINITYDATA MODULES
GENERIC 2WITH
ISDN-PRI
PRIVATE NETWORKANDBRI INTERFACE
ISDN-PRI
VOICE TERMINALSNFAS
DEFINITY
GENERIC 2
WITHSYSTEM 85 R2V4,
ISDN-PRI
GENERIC 1,2, OR
BRI INTERFACEVENDOR SWITCHDATA MODULESWITH ISDN-PRI
Figure 1-2. Generic 2 ISDN Network Configuration
Generic 1 and Generic 2 provide ISDN-PRI but do not support wideband channels. Additionally, ISDN-
BRI is not currently supported in Generic 1. However, end-to-end digital connections are permitted via
line-side DCP-interface voice terminals and DCP-interface data modules. Figure 1-3, Generic 1 ISDN
Network Configuration, shows a Generic 1 in a sample network.½
½
½
ADDENDUM 1 (December 1990) to 555-025-101, Issue 4 
						

							INTRODUCTION1-21
TABLE 1-2. Data Module Capabilities½
Data
ModuleDMI
ModeUser Data
RateSync/
AsyncBit
InvertProtocol
PackagingHandshakeNotes
7400 Series2to 19.2K
to 19.2Kasync
yesHDLCmode 2
DTDM2both
yesHDLCmode 2
MPDM0
1
264K
56K
to 19.2K
sync
sync
both
yesnoyesno
DDS
HDLCmode 2
mode 2
mode 21
MPDM/M1*
0
1
264K
56K
to 19.2K
sync
sync
both
yesnoyes
none
DDS
HDLCno
no
no2
2
2½
½
½
½
½
½
½
½
½
½
½
½
½
3270 A2
3to 19.2K
64Kboth
syncyes
yesHDLC
LAPD/X.25mode 3/2 adapt
mode 3/2 adapt3
4
3270 T364K
sync
yesLAPD/X.25
mode 34
PC/PBX
Conn. w/ASCII
Term Emul2
to 19.2K
64KasyncyesHDLC
mode 3/2 adapt
or mode 2
mode 3/2 adapt5
3
asyncyesLAPD/X.25
PC/PBX
Conn. w/3270
Emulation364Ksyncyes
LAPD/X.25mode 3
5½
7500 Series
BRI Sets0
1
2
364K
56K
to 19.2K
64K
64Ksync
sync
both
sync
syncno
no
yes
yes
yesnone
DDS
HDLC
LAPD/X.25
LAPD/X.25no
no
mode 3/2 adapt
mode 3/2 adapt
mode 3/2 adapt½
½
½6
7,8
7,8
3/2
PC/ISDN
w/3270
Emulation356K/64K
sync
yes/no
optionLAPD/X.25
mode 3
9
PC/ISDN
w/ASCII
Terminal
Emulation2
3to 19.2K
56K/64Kasync
yes
HDLC
or mode 2
LAPD/X.25mode 3/2 adapt
10½
½
½
½
½
½
½
½
½
syncyes/nooptionmode 3
10
ISDN Advantage3
64K
sync
yesLAPD/X.25
mode 3
MPDM — modular processor data module
NOTES:
1.
2.
3.A mode-2 handshake works only on 64K-bps facilities (such as alternate voice/data or AVD). (Use an MPDM/M1* for mode-1 calls made
over robbed-bit facilities.) Since an ISDN-PRI link between a System 85 R2V4 and a Generic 1 uses these facilities, this handshaking will
work.
You must use the MPDM/M1* when the far end data circuit-terminating equipment (DCE) is not another AT&T data module or robbed-bit
facility (does not do a mode-2 handshake).
Although the MPDM/M1* also suppresses the handshake in mode 2, it is recommended this not be done since rate adaption would not be
possible.
Mode 3/2 adaptive means that a mode-3 handshake is attempted first. An algorithm is then followed to determine the far-ends mode and
either switch to mode 2 or continue in mode 3.½
½
½
½
½
ADDENDUM 1 (December 1990) to 555-025-101, Issue 4 
						

							1-22INTRODUCITON
4.
5.
6.
7.
8.
9.
10.Mode-3 data can only be circuit switched in Generic 1.1 and Generic 2.1. Using mode 3 on a 3270A or 3270T requires a 3270C on the far
end.
Mode 2 on the PC/PBX Connection is supported under the ASCII terminal emulation package. The PC/PBX Connection in mode 2 uses a
mode 3/2 adaptive handshake if the bit rate is set to 64K. If the rate is set to 19.2K or slower, a mode 2 handshake is used. 3270 emulation
on the PC/PBX Connection requires a 3270C data module on the far end. Mode 3 operation is defined as synchronous when in 3270
emulation, otherwise mode 3 operation on the PC/PBX Connection is defined as asynchronous.
Mode 2 on the 7500 series is implemented in the incoming (to the 7500) direction only. Outgoing calls requiring mode 2 speeds use mode 3/2
adaptive BC.
On outgoing mode 3 and mode 3/2 adaptive calls, the 7500 series always inverts bits. On incoming mode 3 and mode 3/2 adaptive calls, the
7500 series checks the restriction bit in the low-layer compatibility IE and either inverts or does not invert depending on the contents of the IE.
This is not done for mode 0 calls.½
½
½
½
½
½
½
The algorithm used for the mode 3/2 handshake is different for DCP and the 7500 data modules. When called, the 7500 data module starts a
mode 3 handshake. If it receives a mode 3 or mode 2 handshake from the calling end within a specified number of seconds, it switches to that
mode. If it does not receive a mode 3 or mode 2 handshake within that time, it switches to mode 2. If it does not receive a mode 2
handshake within 15 more seconds, it drops the call.
Options exist on the PC/ISDN Platform with 3270 Emulation to allow the user to choose either 56K-bps or 64K-bps and to choose to invert or
not invert bits. The PC/ISDN Platform with 3270 Emulation requires a 3270C data module on the far end.½
½
½
½
½
Options exist on the PC/ISDN Platform with ASCII Terminal Emulation to allow the user to choose either 56K-bps or 64K-bps and to choose
to invert or not invert bits. Either mode 3/2 adaptive or mode 2 handshakes are used depending on the baud rate option setting. If the setting
is 19.2K-bps or slower, a mode 2 handshake is used. Mode 3 operation is defined as synchronous when in 3270 emulation, otherwise mode 3
operation on the PC/ISDN Platform is defined as asynchronous.½
½
½
Some applications where DCP and DMI formatted data are not used include the following:
a.When 64K-bps data is transmitted across DS1/DMI/ISDN-PRI facilities (via a dedicated switch
connection or DSC) to an endpoint such as a channel bank channel unit.
b.When a point-to-point data application is done with CDMs to drop and insert DS0 channels.
Here, it is up to the user endpoints to ensure that the 1s-density requirement is met.
The method used to provide ACCUNET® switched digital service (used by D4-channel banks) also
maintains the 1s-density requirement. This method uses only seven of the eight bits for each DS0
channel’s 8-bit word to carry user data. The remaining bit (8) is “wired” to a 1. (MPDM/M1* is
compatible with ACCUNET switched digital service).
IMPORTANT CONCEPTS
Important concepts discussed in this section include:
l
l
l
l
l
lCommon-channel signaling
Alternate voice/data (AVD) trunks
Bearer capability (BC)
ISDN call processing
CBC Service Selection
Networking restrictions and ISDN-PRI limitations
ADDENDUM 1 (December 1990) to 555-025-101, Issue 4 
						

							INTRODUCTION1-23
Common-Channel Signaling
Originally, common-channel signaling (CCS) meant that any of the 24 channels could be used to
transmit signaling for the other 23. To offer CCS, both RBS and 24th-channel signaling would have to
be disabled to make all 24 channels available to transmit signaling.
Current AT&T applications use only the 24th-channel as the signaling channel and, therefore, the term
CCS has been used more and more as a synonym for 24th-channel signaling. Misuse of the term CCS
and its original definition have contributed to some misunderstanding. When comparing System 75 and
System 85 DS1/DMI administration procedures, you will find that:½
a.
b.The current definition of CCS is used when administering System 75 and Generic 1, although it is
24th-channel signaling that is actually being administered.½
The original definition of CCS cannot be administered for System 85 or Generic 2, however, 24th-
channel signaling can be administered. For Generic 2, the equivalent terms, 23B + 1D or 24th-
channel signaling, are used rather than CCS.½
½
Alternate Voice/Data (AVD) Trunks
AVD is an attribute of trunks used with System 85 R2V4 and earlier releases, and System 75 R1V3 and
earlier releases, and all Generic 1 switches. For Generic 2, bearer capability, wich identifies the
capabilities previously identified with AVD plus many more, is used instead.½
½
AVD relates a trunk group’s translations to the type of signaling required to support the trunk group.
From the software perspective (and when applicable), a trunk group is administered for either AVD or
voice. Trunk groups administered for AVD may be used for both voice and digital data applications and
require a DS1 that is administered for 24th-channel signaling.
Bearer Capability (BC)
System 85 R2V4 introduced the administration attribute known as bearer capability (BC). The primary
function of BC is to specify the transport mode and the channel requirements (clear/restricted) needed
for completing a data call. BC is used for determing compatibility when non-ISDN facilities are
connected to ISDN facilities, including originated calls, terminated calls, and tandem connections. BC
must be administered for all trunk groups, every extensions class-of-service (COS), and all Automatic
Route Selection (ARS) routing-pattern preferences.½
½
½
½
System 85 R2V4
For System 85 R2V4, there are the five different BC codes:
0
Voice and voice-grade data — should be administered for DCP voice extensions, analog lines,
analog trunks, and data applications that use modems.
NOTE: Except for 56K-bps, the trunk attribute AVD indicates 24th-channel signaling and
whether a modem pool must be inserted to complete the call.
ADDENDUM 1 (December 1990) to 555-025-101, Issue 4½
½ 
						

							1-24INTRODUCTION
1
2
3
4Mode-1 data — with the 56K-bps option — should be administered for 56K-bps synchronous data
applications. MPDM uses mode-2 handshake unless using MPDM/M1*.
NOTE: The appropriate data module must be installed and optioned for 56K-bps operation.
This arrangement can be used to support the special format required to support ACCUNET
switched digital service or 56K-bps basic service (if using MPDM/M1*).
Mode-2 data — for data modules and EIA data terminations that do not operate as packet-mode data
and are optioned for the following data rates: low, 300, 1200, 2400, 4800, 9600, 19.2K-bps. When
appropriate, end points that route to DS1/DMI/ISDN-PRI preferences should be administered for
mode 2 data. Data modules invert the data and uses mode-2 handshaking.
Mode-3 data — end points should be administered for preferences that are used for packet mode
data. DCP inverts the data and uses mode-3/2 handshaking. This is used for patterns associated
with ISDN-BRI or PC-PBX.
Mode-0 data — end points should be administered for digital endpoints that are used to transmit½
½
½
½
½
½
*
64K-bps data.
Depending on the administered value, an originated call will either require an ISDN channel, have an
administered preference that an ISDN channel be used, or have no requirement for what type of facility
is used to complete the call. For terminated calls and tandem connections, the BC class (BCC) for both
links must be compatible. For example, voice and voice-grade data are equivalent to the no requirement
case since the call characteristics for all other types of facilities are satisfactory. In contrast, B-channels
transmitting 64K-bps digital data require that the connected channel have the same call characteristics
(the same BCC) such as where an ISDN channel is required. This information appears in the traveling
class mark (TCM) IE (layer 3) codeset 7 in System 85 R2V4, and in codeset 6 in Generic 2.
Generic 1
For information about how BC is done for Generic 1, refer to the AT&T DEFINITY 75/85
Communications System Generic 1 and System 75 and System 75 XE Feature Description (555-200-201).
Generic 2
Generic 2 continues the bearer capability concept with bearer capability class of service, (BCCOS).
BCCOS is a set of attributes that is assigned to extensions, AAR and ARS routing pattern preferences,
and trunk groups (BCC is one of these attributes). BCCOS determines such actions as call routing and
modem pooling insertion based on the calling and called parties BCCs and information types (that is,
clear or restricted).
You can assign up to 256 BCCOSs (0-255), where codes 0 through 9 are predefined as:½
½
½
½
½
½
½
½
½
½
½
0
1
2Voice only — used for voice application extensions (such as DCP and ISDN-BRI extensions, analog
lines, and analog trunks)
Mode 2 data — used for EIA data terminations, and DCP or BRI data modules that do not operate
as packet mode data and are optioned for any of the following data rates: low, 300, 1200, 2400,
4800, 9600, or 19.2K-bps
Mode 3/2 adaptive data — used for data applications that can run both modes 3 and 2 (such as BRI,
PC/PBX, and 3270 data modules). Mode 3 is tried first; if it fails, mode 2 is used.½
½
½
ADDENDUM 1 (December 1990) to 555-025-101, Issue 4 
						

							INTRODUCTION1-25
3
4
5
6
7
8
9Unknown digital — used for those calls of any mode (0-3) where the signaling message does not
specify a mode (such as DS1 trunks using common-channel or 24th-channel signaling)
Unkown analog — used for voice or voice-grade data calls where the signaling message does not
specify a type (such as analog trunks and robbed-bit DS1 trunks)
Voice-grade data — used for data applications that use modems
Mode-0 data — used for facilities that transmit 64K-bps data (DCP and BRI extensions, DMI-BOS
trunks, and ISDN-PRI facilities).
Mode-1 data — used for 56K-bps synchronous data applications. The appropriate data module must
be installed and optioned for 56K-bps operation.
NOTE: This arrangement can be used to support the special format required for ACCUNET
switched digital service or 56K-bps basic service. DCP uses a mode-2 handshake unless an
MPDM/M1* data module is used.
Mode-3 data — should be administered for those applications requiring packet mode data.
X.25 — X.25 is administered only for DCIU and other X.25 links.½
½
½
½
½
½
Predefined BCCOSs should not be redefined. Lines, trunks, and AAR/ARS preferences are assigned the
default BC when one is not administered. Generic 2 BCCOS defaults are intended to make a Generic 2
switch operate like a System 85 R2V4 (that is, Generic 2 will insert modem pool members and block
calls.) Table 1-3, Bearer Capability Class of Service, lists the default values for common switch
parameters.½
½
TABLE 1-3. BCCOS
Switch ParameterDefault Value
Analog Lines
All trunks except Host Access
AAR/ARS Preferences
Host Access trunks
DCP data modules (both lines and trunks)
BRI extensions0
0
0
1
1
0
NOTE: Extensions with multiple appearances must have the
same BC administered for each appearance.
BCCOS is implemented by doing the following five steps:½
½
½
Define a BCCOS in procedure 014, word 1
Fields 2-16 of this procedure determine how the extension, preference, or trunk group assigned a
BCCOS will treat calls made to that extension, preference, or trunk group. This treatment is based
on the BC and information type fields of the BCCOS of the calling extension or trunk.
Assign a BCCOS to extensions in procedure 000, word 3
Field 1 assigns a BCCOS to an extension number. This assignment affects the pattern or
preference selected for this extension on outgoing calls (see step 4 below).½
½
½1.
2.½
½
½
ADDENDUM 1 (December 1990) to 555-025-101, Issue 4 
						

							1-26INTRODUCTION½
½
½
3.
4.
5.The 10 BCs are defined in field 16 of procedure 014, word 1. This definition codes the BC IE in
the setup message when the extension (entered in field 1 of procedure 000, word 3) accesses an
ISDN-PRI trunk for an outgoing call (DCP only).
When a Generic 2 is connected to a 4ESS, assign a network-specific facility (NSF) in procedure
279, word 1½
½
Each interexchange carrier (which provides public network ISDN service) must have a unique
identifier number. Furthermore, each carrier may provide multiple ISDN services and ISDN
features that must be individually identified via a Network Specific Facility (NSF) coding value.
A NSF is an ISDN IE (sent in the setup message) that is used to identify the network or feature
associated with the call. When connected to a 4ESS, a Generic 2 must send the appropriate NSF
for MEGACOM, SDN, and ACCUNET switched digital service calls. (MEGACOM 800 service
calls do not require an NSF since it is an incoming-only service and the Generic 2 cannot tandem
it to another switch as a MEGACOM 800 call.)½
½
½
½
½
½
½
½
Assign AAR and ARS routing preferences in procedures 309, word 5, and 321, word 5½
Assign the same NSF index from field 1 of procedure 279, word 1, in field 5 of both of these
procedures.
For procedure 309, word 5, the value entered in field 5 along with the value entered in field 12 of
procedure 309, word 1, (the IXC/ISDN network identifier) determine the NSF IE for calls routed
over this ARS plan, pattern, or preference. An NSF IE is not sent if a value is not entered. If
field 5 has no value but an IXC/ISDN network identifier is specified, the network identification is
specified with the transit network selection IE instead of the network-specific facilities IE.
For procedure 321, word 5, the fields in this procedure define for AAR patterns and preferences
what procedure 309, word 5, define for ARS plans, patterns, and preferences.
Administer trunk groups in procedure 100, words 1-3
For procedure 100, word 1:½
½
½
½
½
½
½
½
½
½
½
Field 6 defines the trunk type of a specific trunk group. For ISDN trunk groups as well
as other types of trunk groups, the entered type defines feature operation for the trunk
group. For example, if a trunk group is assigned the type of 19, incoming calls over this
trunk group are routed to the attendant console. On Direct Inward Dial (DID) trunk-type
groups, the switch expects station-number digits on all incoming trunks; on tie-trunk-type
groups, the switch can handle either station-number digits or network numbers.
For an ISDN trunk group, a dynamic trunk type (120) can be assigned to the group. This
trunk type allows the group to process calls with a different trunk type on a call-by-call
(CBC) basis. For example, one incoming call over the group may expect station number
digits (such as a MEGACOM call), while the next call over the group may expect a
network number (such as a Software Defined Network call, also called a SDN call).
The ISDN Dynamic trunk type allows administration of both an AAR/ARS prefix digit
(procedure 103) and a DID additional digit (procedure 101). (This cannot be done for
any other type of trunk group.)½
½
½
½
½
½
½
½
½
½
½
½
½
½
ADDENDUM 1 (December 1990) to 555-025-101, Issue 4 
						

							INTRODUCTION1-27
For procedure 100, word 2:
Field 1 specifies the trunk group number and field 2 specifies a BCCOS number for this
trunk group. For interworked tandem calls through the switch where the calling trunk is
not ISDN-PRI trunk and the called trunk is, the BCCOS of the non-ISDN-PRI trunk is
used to define a BC for the outgoing setup message over the ISDN-PRI trunk. This COS
also defines other routing parameters.
For procedure 100, word 3:
Field 2 assigns a trunk group as ISDN-PRI that has ISDN-PRI signaling (type 20). This
causes ISDN-PRI message-oriented signaling (MOS) to occur for the trunk group.
Field 8 prevents the sending of various IEs over the trunk group specified in field 1.½
½
½
½
½
½
½
½
½
½
For specific information on routing rules, refer to appendix C: Administrative Procedure Summary.½
For specific information on administering a Generic 2 to a 4ESS, see DEFINITY Communications
System Generic 2.1 to 4ESS Via ISDN PRI Access, 555-037-237.½
½
For specific information on proper implementation of BCCOS, refer to DEFINITY® Communications
System Generic 2 Administration Procedures, 555-104-506.½
ISDN Call Processing
ISDN-PRI is a trunk signaling type. ISDN trunk signaling is applied on a per-trunk-group basis and is
compatible with most existing switch features. ISDN trunk signaling also supports many new
networking features as described next.
Outgoing Calls
For outgoing calls, ISDN trunk groups may be categorized as those that:
1.
2.
3.Require that address digits be collected before trunk seizure (this can be done on non-ISDN
trunks)
Seize the trunk and do not outpulse any digits (this is called digit sending)
Seize the trunk, obtain a start dial signal, and then begin digit outpulsing (this is called cut-
through dialing) to the terminating switch
The ISDN protocol requires that all dialed digits be collected before trunk seizure so cut-through dialing
cannot be provided for ISDN calls. Since few applications use digit sending, AAR or ARS software
must be used to collect and process dialed digits. If the switch is properly administered and the
numbering-plan data blocks are correct, AAR or ARS software processes dialed digits based on data
within the routing pattern and routing preference combinations resulting in the selection of a particular
service or feature. The routing pattern and routing preference combinations determine which outgoing
trunk group is selected and whether ISDN-PRI trunk signaling is used.½
ADDENDUM 1 (December 1990) to 555-025-101, Issue 4 
						

							1-28INTRODUCTION
Each call routed to an ISDN signaling trunk group generates a series of Q.931 messages over the
D-channel. For example, the calling party IE of the ISDN-PRI setup message assembles the dialed
digits as ASCII numbers that correspond to the defined numbering-plan format. Also included within
the setup message are the BC requirements, B-channel identification, and network-specific facilities
(NSF). If the requested facilities are not available, either channel negotiation is begun or, if appropriate,
a cause failure code is returned and the call attempt is dropped. Otherwise, the called switch responds
with a call proceeding or alerting message.½
½
Incoming Calls
Incoming ISDN calls are generally processed similar to outgoing ISDN calls. Initially, the called switch
receives a setup message over the D-channel and processes the contents of the setup message. The call
states of the switch, how the particular trunk groups are administered, and decisions taken as a result of½
processing the setup message will determine exactly how the ISDN call is processed.
Look-Ahead Interflow½
½
Look-Ahead Interflow allows customers with multiple ISDN-PRI locations to achieve optimum call-
handling capability and agent productivity by routing calls among call centers as though they were one
location. Look-Ahead Interflow is normally used with the Automatic Call Distribution (ACD),
AAR/ARS, and Call Vectoring features to conditionally select a distant switch to handle interflowed
calls. Which distant switch the sending switch selects is determined by a series of “route to” steps
within the same vector. Look-Ahead Interflow then lets the sending switch use the D-channel to query
the status of a distant switch before sending the call. If the distant switch can handle the interflow call,
it accepts the call with a D-channel (progress) message and the call is sent over the B-channel. If the
distant switch cannot handle the call, it rejects the call with a different (disconnect) message. The
sending switch then either selects an alternative distant switch from subsequent “route to” steps and
sets up another status query, or invokes the alternative action program within its own local vector.
Calls can be intelligently interflowed among switches based on (that is, progress of the message):
lTime of oldest call in the queue
lNumber of calls in the queue
lNumber of staff or available agents to handle calls
lTime of day
NOTE: Look-Ahead Interflow currently works only in private network configurations.
NOTE: Call Vectoring and AAR/ARS must be present for Look-Ahead Interflow to work properly.
Summary
ISDN calls are processed using conventional, well-established, time-proven call-processing techniques.
The ISDN layer-3 software maintains status records for the ISDN call states, maintains the call-reference
value (CRV) for each B-channel, and starts sending messages. To request services from the
conventional call-processing routines, ISDN layer-3 software informs the switch of items such as
incoming calls and dialed digits.
ADDENDUM 1 (December 1990) to 555-025-101, Issue 4½
½
½
½
½
½
½
½
½
½
½
½
½
½
½
½
½
½
½