Home > Articles > Cisco Network Technology > General Networking > Integrated Services Digital Network Primer

Integrated Services Digital Network Primer

  • Sample Chapter is provided courtesy of Cisco Press.
  • Date: Oct 18, 2002.

Chapter Description

This chapter covers Integrated Services Digital Network (ISDN) basics, ISDN physical attributes, ISDN specifications, BRI, and PRI.

ISDN Specifications

ISDN has been standardized in a host of different specifications from groups such as the International Telecommunication Union (ITU), Telcordia (formerly Bellcore), and the American National Standards Institute (ANSI). These groups, along with the ISDN forum, are responsible for modeling the ISDN industry. Standards that are in the I group consist of standards set forth for ISDN, both narrow and broadband. The Q group of standards has to do with switching and signaling. The Q standards also include topics such as SS7 and Intelligent Networks (INs). Several standards are associated with ISDN, but the most common standards are as follows:

  • I.430—BRI Physical Layer

  • I.431—PRI Physical Layer

  • Q.921—ISDN Data Link Layer Specification

  • Q.931—Call-Control and Signaling Specification

The physical layer specifications for ISDN are I.430 and I.431. They identify the electrical, mechanical, and functional specifications of the circuits. I.430 specifies the basis for a BRI frame as 48 bits. The BRI frame is cycled at 4000 times per second, which gives a total bandwidth of 192,000 bps (48 * 4000). Although 192 kbps is available on the BRI circuit, the subscriber typically only uses a maximum of 128 kbps. 144 kbps is possible if the D channel is also used for data, but D channel use depends on the provider.

I.431 describes the use of either a T1 or E1 circuit for the electrical basis of a PRI circuit. There are specifications for a Japanese PRI (INS-1500), but it is not included in the ITU specification.

ITU Q.921

The ISDN protocol stack consists of three layers: physical, data link, and network. The data link layer function and format is described in ITU Q.921. Q.921 is also referred to as Link Access Procedure on the D channel (LAPD). This part of the protocol stack is largely based on the high-level data link control (HDLC) protocol.

The purpose of Q.921 is to provide for a reliable transport for Layer 3 signaling messages (Q.931), provide identification of frames, and provide flow control mechanisms for data transmission and reception. If you're thinking that these functions look familiar by now, they should. The Layer 2 functionality that you find in ISDN, SS7, Frame Relay, and other technologies are basically the same thing. This is due to the description of what the function of a Layer 2 service should be in functional models such as the Open System Interconnection (OSI) model.

NOTE

Not all technologies implement layer 2 functions in the same way.

Because Q.921 deals with Layer 2 functions, it is important to remember that transmission of frames is involved between ISDN nodes. Q.921 communication takes place only between two immediate points and is not end-to-end. Before you move on, you should understand the Q.921 frame structures and how they are used. Figure 8-6 shows Frame Types A and B for ISDN Q.921.

Figure 8-6Figure 8-6 Q.921 Frame Structure

There are two frame formats that are commonly associated with Q.921, and they are denoted as Type A and Type B. The main difference between the two frame types is the fact the Type B has an information field that is of variable length.

The Flag fields that are on either end of the Q.921 frame identify the beginning and the end of the frame. The flag sequence for both flag types is 01111110, and the closing flag of one frame can count as the opening flag of the next frame. Otherwise, there are back-to-back flag octets in every frame after the first flag octet in the signal stream.

The address octets are set up as a high-order octet and a low-order octet. The high-order octet contains information such as the extended address (EA) bit, command/response (C/R) bit, and the service access point identifier (SAPI). The second octet contains an EA bit and a 7-bit field that is referred to as the terminal endpoint identifier (TEI). Figure 8-7 shows the placement of each of these fields.

Figure 8-7Figure 8-7 Q.921 Address Octets

The EA bits identify where the address octets end. Whichever of the two octets are identified by a 1 serves as the last address octet. In normal Q.921 operation you use both address octets, and the bits are set to (read right to left) 0 and 1 respectively.

The C/R bit identifies whether a frame is intended to be either a command or a response. The bit value is determined by the direction of the message and the message type. If the user side of the ISDN connection is sending the message, it uses a 0 value for a command and a 1 value for a response. The network side sends commands with a bit value of 1 and a response with a bit value of 0.

Service access points (SAPs) are the points that Q.921 uses to provide service to Q.931. The access points are denoted with an identifier called a SAPI. In other words, the SAPI is a value that identifies different types of traffic. Table 8-1 lists the different SAPI values and their defined data representations.

Table 8-1 Q.921 SAPI Values and Data Types

SAPI

Data Type

0

Call Control

1 to 15

Reserved

16

X.25

17 to 31

Reserved

63

Layer 2 Management


The last field in the address low octet is the TEI. The TEI identifies the terminal equipment on the data link connection. The values range from 0 to 127, and they are split into two different sub-categories: static and dynamic TEI assignment:

  • TEI values 0 to 63 are for static assignment, and TEI 0 is most commonly associated with ISDN PRI circuits.

  • TEI values 64 to 126 are for dynamic TEI assignment and are commonly found on ISDN BRI circuits.

  • TEI 127 is reserved as the broadcast TEI. For instance, when an ISDN device on a BRI circuit comes online and requests a TEI from the network, it uses TEI 127 as the vehicle for the request.

The next several octets in the frame are called control octets, and they can be 16 or 24 bits total (depending on whether or not there is an info octet). The control octets, in conjunction with the C/R bit, identify which type of frame is being sent. Three types of frame groups are used, numbered information (I), unnumbered information (U), and supervisory (S). The main difference between I and U frame types is that U frame types do not guarantee delivery, and they do not require acknowledgments. Table 8-2 lists some of the more common frame types and their functions.

Table 8-2 Q.921 Control Octet Frame Types

Frame Type

Definition

Information (I)

I frames identify a sequential order of frames with acknowledgments. Please see the next section for a detailed look at operation. These are standard transmission and reception frames that transport messages such as Q.931 Setup messages.

Unnumbered (U)

U frames are used upon request from Q.931 to facilitate connection management that does not require the receipt of acknowledgments. Particularly, you see these frame types for operations such as TEI assignment requests.

Supervisory (S)

S frames display different layer control states such as RR, RNR, and REJ.

Set Asynchronous Balanced Mode Extended (SABME)

SABME is the first message sent during a Layer 2 connection sequence. Its basic purpose is to reset the link and prepare it for a new connection. SABMEs must be acknowledged by a UA.

Unnumbered Acknowledgment (UA)

UAs are sent in response to a SABME message to acknowledge receipt of the connection request. UAs are also sent to acknowledge the receipt of a DISC message.

Receive Ready (RR)

RR indicates that the ISDN device can begin to receive frames. This is only active after the integrity of the link has been checked. RR messages can also be used in conjunction with N(S) and N(R) to acknowledge previous received frames.

Receive Not Ready (RNR)

RNR specifies that the ISDN device is not ready to receive frames and that transmission should not take place. This can be caused by a link failure, improper network-user settings, or congestion on the circuit.

Reject (REJ)

REJ is sent to request the retransmission of a frame that was corrupted or otherwise not accepted.

Disconnect (DISC)

After multiple frames have been established, the DISC message type can be sent to disconnect the link.

Disconnected Mode (DM)

DM is sent when multiple frame establishment is not possible.

Frame Reject (FRMR)

FRMR reports errors on frames that cannot be recovered by retransmission.

Exchange Identification (XID)

XID is an optional message that allows for the exchange of device information during the synchronization process. Please refer to Figure 8-6 (Frame Type B INFO field) for location within the frame.


Figure 8-8 shows the three main frame categories and their associated bit locations.

Figure 8-8Figure 8-8 Q.921 Control Octets

NOTE

Something to note about Figure 8-8 is the state of the first two bits. The following applies to the Q.921 control octets:

  • If the first bit is equal to 0, it is an I frame.

  • If the first bit is equal to 1 and the second bit is equal to 0, it is an S frame.

  • If the first bit is equal to 1 and the second bit is equal to 1, it is a U frame.

During the data link negotiation process within Q.921, the purpose is to get the link to a Multiple Frame Established (MFE) state. After the link is in MFE, the devices are ready to transmit upper-layer data between them. The negotiation process contains several steps that you need to comprehend to effectively understand and troubleshoot Q.921 operation.

Q.921 Alignment

During the first message transfer in the Q.921 alignment process, a UI frame with a TEI request is sent from the user device to the network using the T202 timer. Remember that the broadcast TEI for this function is 127. Figure 8-9 shows the TEI assignment process between the subscriber equipment and the ISDN switch. Upon receipt of the UI frame, the network responds with the user device's TEI assignment. The operation of the UI frame is the same as defined for U frames in Table 8-2. After the TEI assignment has taken place, the assigned TEI is used. Prior to the assignment of the TEI, the device is in a TEI=Unassigned state, unless a PRI circuit is being used.

Figure 8-9Figure 8-9 Q.921 TEI Request and Confirmation

NOTE

Dynamic TEI assignment is only used for point-to-multipoint configurations, as seen with ISDN BRI circuits. Therefore, point-to-point applications, such as T1 or E1 PRI, use a static TEI with the value of 0.

Furthermore, Reference Number (RI) fields differentiate between simultaneous requests from multiple devices so that the ISDN switch can keep track of the different user requests. An Action Indicator (AI) requests that a dynamically assigned TEI be given from Layer 3.

After the TEI has been assigned to a device, there is an audit feature in place that allows for the verification of a TEI called a TEI check. This check allows the network equipment to verify that a specific device has a TEI assigned or to determine if a device has been given a duplicate TEI in error. This check is performed based on the T201 timer.

T201 is started and the check request sent. If multiple responses return with the same TEI, the check is verified by starting the process over. If there are multiple responses a second time, duplicate TEI assignments are known. The network side can request that a TEI be reassigned at this point by sending a TEI identity remove statement to the remote station in question. This same timer finds out which TEIs are no longer being used. If a check request is sent and no response comes back after two consecutive periods, the TEI is released back into the pool as available. The network or user side can start TEI verification.

SABME is sent from the user side to the network side. Remember, the SABME resets the link for a clean connection and it must be acknowledged with a UA frame type. Figure 8-10 shows the start of the Q.921 link. The combination of SAPI and TEI are similar to how a data-link connection identifier (DLCI) works in Frame Relay. They address the Layer 2 portions of the ISDN circuit.

Figure 8-10Figure 8-10 Q.921 SABME and UA Acknowledgment

After this point, the data link is said to aligned. Now the two sides are ready to exchange messages and can begin the heartbeat sequence. The heartbeat sequence, or keep-alive, is a series of Receiver Ready poll (RRp) and Receiver Ready final (RRf) messages. These messages basically verify that the link integrity is still acceptable.

During transmission of frames, the N(S) and N(R) frame types indicate which frame number is being sent, and which should be sent next, as shown in Figure 8-11. In other words, if a frame is received with a N(S)=5 and a N(R)=6 this tells you that the number of the frame you are receiving is 5 and the remote receiver expects 6 to be sent to it next.

Figure 8-11Figure 8-11 Q.921 Frame Sequence

The incrementing of the frames is handled by V(S) and V(R). V(S) is a value that is held by the transmitting station's device. As each frame is sent, the current number is transferred to the N(S) field and the number is incremented. The receiving device uses the N(R) to identify which frame number should be received next. The values are paired as N(S)/V(R) for purposes of checking integrity. At the receiving device, it compares V(R) to N(S) to verify that the correct frame has been sent. After that, a CRC is done to verify that the frame itself is good. When both functions pass, the V(R) is incremented by 1.

Q.921 Timers

Although it does not contain an exhaustive list of ISDN timers, this section discusses the more common timers that you need to understand to troubleshoot ISDN circuits at Layer 2. The timers included are T200 to T203 and N200 to N202 and their default values are shown in Table 8-3.

Table 8-3 Q.921 Timers and Their Default Values

Timer Label

Value

T200—Transmission Timer

1 second

T201—TEI Identity Check (Network)

1 second

T202—TEI Assignment (User)

2 seconds

T203—Frame Exchange

10 seconds

N200—Retransmission Attempts

3

N201—Maximum Number of Octets

260

N202—Maximum Transmissions of a TEI Identity Request

3


The T200 timer is the indicator for when a frame can be transmitted. This timer must equal more than the time it takes to send a frame and receive its acknowledgment.

The T201 is used during the TEI identity check sequence. See the "Q.921 Alignment" section, earlier in this chapter for a description of T201 operation during the identity check sequence.

T202 works in conjunction with the T201 timer, but from the user side of the network instead of the network side.

T203 is the maximum time that equipment can wait between the exchange of Q.921 frames. Although the default is only 10 seconds, most equipment, including Cisco equipment, can modify this timer as needed. In cases of long distances and delay, this timer should be modified for continued operation.

N200 is the value that identifies the maximum number of transmission attempts. N200 operates by sending X retransmissions of any given frame. If that frame is still not acknowledged after the expiration of the last attempt timer, that frame is dropped.

N201 identifies how many octets are in an information field. The default value of 260 is a static setting that causes an error if frames do not meet these criteria.

N202 equals how many times a TEI identity request is sent. After that point, TEI=unassigned is set.

NOTE

Another timer that you see present on ISDN configurations with Cisco equipment is the ISDN guard timer. This is not specified in Q.921, but it allows for the proper amount of time to authenticate an inbound call on ISDN. If this timer is not used, your ISDN call can time out.

Cisco IOS allows you to troubleshoot Q.921 activity with the debug isdn q921 command. The most important thing to look for in the output is to make sure that you are sending and receiving traffic. If you are sending but not receiving, you have other problems to look at first. Check to make sure that your physical layer is up. If you are configured in a back-to-back configuration with Cisco equipment, be sure that one side is set to network mode. Example 8-1 shows sample output from the debug isdn q921 command for an ISDN PRI circuit on a Cisco AS5300.

Example 8-1 Sample debug isdn q921 Command Output

AS5300#debug isdn q921
4d22h: ISDN Se0:23: RX <- RRp sapi = 0 tei = 0 nr = 0
4d22h: ISDN Se0:23: TX -> RRf sapi = 0 tei = 0 nr = 0
AS5300#
4d22h: ISDN Se0:23: RX <- RRp sapi = 0 tei = 0 nr = 0
4d22h: ISDN Se0:23: TX -> RRf sapi = 0 tei = 0 nr = 0
AS5300#
4d22h: ISDN Se0:23: RX <- RRp sapi = 0 tei = 0 nr = 0
4d22h: ISDN Se0:23: TX -> RRf sapi = 0 tei = 0 nr = 0

When debugging Q.921, it's important to be aware that Q.921 can also be verified in IOS by using the show isdn status command. The show isdn status command allows verification of the physical layer, Q.921 and Q.931.

ITU Q.931

ISDN's Q.931 is the Layer 3 specification that is responsible for call control and management. These functions include call set up, tear down, and request for services from Layer 2. The purpose of this section is not to go over all of the possible state primitives, but to give you a good understanding of how Q.931 manages ISDN call control.

Q.931 uses a message-based system to control the ingress and egress call functions of an ISDN circuit. Using the D channel as a vehicle for this transport, ISDN Q.931 signaling is referred to as a common channel signaling (CCS) service. As a review, CCS transmits signaling from end-to-end in an out-of-band, non-intrusive way to the bearer traffic. In contrast, channel associated signaling (CAS) is commonly found on T1 circuits and is interwoven into the bearer signal stream.

Some argue that ISDN is not CCS because the signaling and bearer traffic take the same path, but remember that, although it is on the same path, it uses a different logical channel. For that reason, ISDN is physically in-band but logically out-of-band.

To transport the number of messages that are associated with Q.931, it is necessary to have a standardized message format. The beauty of Q.931 is that your equipment doesn't have to process everything that is in the message format. Any information that your equipment doesn't understand is merely ignored. The message format splits values into four subsections:

  • Protocol discriminator

  • Call reference length indication

  • Message type

  • Information element

Figure 8-12 shows the basic Q.931 message format with the order of the octets, beginning from top to bottom.

Figure 8-12Figure 8-12 Q.931 Message Format

The first field in the Q.931 message is the protocol discriminator. The protocol discriminator identifies user/network call-control message types from other message types that might be found on the network. The protocol discriminator is coded as 00010000 for user/network call-control messages, with the least significant bit (LSB) read first (right to left).

The next octet is the call reference length indication octet. This octet specifies how many octets the call reference value can encompass, and it is considered a portion of the actual call reference. The local end of the ISDN connection uses the call reference to maintain a record of all call requests that are processed. To support BRI access, the call reference must be at least two octets in length and at least three octets in length for PRI access. Figure 8-13 shows the octets involved with keeping track of ISDN call instances.

Figure 8-13Figure 8-13 Q.931 Call Reference Octets

There is a flag in the call reference field that delineates between the originating and terminating side of a connection. If it is set to a 0, the message is being sent from the origination point, and if it is set to a 1, the message is being sent from the terminating side of the connection.

The next portion of the message identifies the actual message type. Refer to Table 8-4 for a listing of the message types and how they are coded in the field. Bits 1 to 5 in the field identify the actual message, and the last 3 bits identify the message class. For example, if the call clearing message class is 010, and the release message type is 01101, they are read together as (bit 1 on right) 01001101.

Table 8-4 Q.931 Message Types and Binary Values (LSB First)

Message Class Name

Message Name

Message Value

Call Establishment Message

Message Class Value: 000

Alerting

00001

 

Call Proceeding

00010

 

Connect

00111

 

Connect Acknowledge

01111

 

Progress

00011

 

Setup

00101

 

Setup Acknowledge

01101

Call Information Message

Message Class Value: 001

Resume

00110

 

Resume Acknowledgment

01110

 

Resume Reject

00010

 

Suspend

00101

 

Suspend Acknowledgment

01101

 

Suspend Reject

00001

 

User Information

00000

Call Clearing Message

Message Class Value: 010

Disconnect

00101

 

Release

01101

 

Release Complete

11010

 

Restart

00110

 

Restart Acknowledgment

01110

Miscellaneous

Message Class Value: 011

Segment

00000

 

Congestion Control

11001

 

Information

11011

 

Notify

01110

 

Status

11101

 

Status Enquiry

10101


ISDN Call Flows

During a basic call flow, the calling party is the origination of the call and the called party is the destination of the call. The calling party sends a Setup message to the called party through the ISDN network. The calling party gets a Setup Acknowledgment and Call Proceeding from the local ISDN switch. The Setup Acknowledge is only used for overlap signaling. If en-bloc signaling is used, Call Proceeding is sent without a Setup Acknowledge. The remote ISDN switch sends a Setup message to the remote ISDN terminal and receives a Call Proceeding and Alerting message in response. The Alerting message travels through the network to the originating ISDN switch, and it sends an Alerting message to the calling party. Also in a backwards direction from the called party, a Connect statement is sent back to the calling party to indicate that the call has been connected and that a voice/data path now exists between them. Refer to Figure 8-14 for an illustration of a basic call setup procedure.

Figure 8-14Figure 8-14 Q.931 Call Setup Procedure

Figure 8-15 shows the call disconnect procedure. A typical call disconnect is rather simple. For instance, say that the calling party hangs up the connection first. In this case, the calling party sends a Disconnect message to the local ISDN switch. The ISDN switch enters a Disconnect Request state and begins clearing the B channels from the call to send them back into the pool of available B channels.

Figure 8-15Figure 8-15 Q.931 Call Disconnect Procedure

The local ISDN switch requests that the call be disconnected at the called party end and send a Release message to the calling party. The Release message is locally significant and does not mean that the called party has disconnected. Upon receiving the Release message, the calling party releases the B channels and sends a Release Complete to the local ISDN switch. The ISDN switch is then able to allocate the specified B channels for other calls.

The remote ISDN switch for the called party sends a Disconnect message to the called party's customer premises equipment (CPE). The remote call clearing happens in tandem with the local call clearing but is independent of it. The CPE disconnects and sends a Release message back to its local ISDN switch, which in turn, responds with a Release Complete. At this point, the call has been cleared on both sides, and the resources are available for use.

Information Elements

The last field that is included in the Q.931 message format is the information or information element (IE) field. This field can consist of many different IEs that describe the features and capabilities of a given call. For instance, a single Setup message contains more than 15 different IEs including called party number, calling party number, bearer capability, transit network selection, and date and time. IEs are categorized as either single octet or multiple octet IEs. Figure 8-16 shows the format of the IE fields in the Q.931 messages.

Figure 8-16Figure 8-16 Information Element Formats

The single octet IEs are used for functions, such as requesting more data, identifying that the call reception is complete, and identifying the congestion level. All the important IEs that you need to know to troubleshoot Q.931 are considered multiple octet IEs.

The multiple octet IEs serve most of the useful functions by exchanging the bearer capabilities of the circuits, sending calling and called numbers to the destination, sending called and calling party sub-addresses, sending the requested channel ID, and sending any cause codes if the connection is unsuccessful. Because there are so many of them, this section focuses on some of the more important IEs from a troubleshooting standpoint.

Bearer Capability

The bearer capability IE identifies which capabilities a call is requesting from the network. This IE must be present in the Setup message or the call fails. This can be one of the largest IEs, ranging from 4 to 12 octets, and it contains information such as the type of service (ToS), rate multiplier (if necessary), user information Layer 1 protocol, and asynchronous control information, if needed (start and stop bits/parity). Figure 8-17 shows the fields that are contained in the bearer capability IE.

Figure 8-17Figure 8-17 Bearer Capabilities IE Format

The bearer capability IE is no small affair because it is responsible for conveying the actual call characteristics to the called device and negotiates between both devices. Within the IE message, the third octet is most important because it specifies the information transfer capability. This identifies the type of traffic that is present on the call. Table 8-5 lists the information transfer capabilities and their coding formats (listed as bit 1 to bit 5 from right to left).

Table 8-5 Information Transfer Capability Values in Binary

Information Transfer Capability

Binary Value

Speech

00000

Unrestricted Digital Information

00010

Restricted Digital Information

10010

3.1 kHz Audio

00001

Unrestricted Digital Information with Tones

10001

Video

00011


In Cisco IOS, the bearer capability is listed as a hexadecimal value, as shown in Example 8-2.

Example 8-2 Q.931 Call Setup Showing the Bearer Capability Value

TX -> SETUP pd = 8 callref = 0x04
 Bearer Capability i = 0x8890
 Channel ID i = 0x83
 Called Party Number i = 0x80, ´9195551212'
RX <- CALL_PROC pd = 8 callref = 0x84
 Channel ID i = 0x89
RX <- CONNECT pd = 8 callref = 0x84
TX -> CONNECT_ACK pd = 8 callref = 0x04....

In this output, you can see that the bearer capability is 0x8890, which is equal to a 64-kbps data call (unrestricted digital information). Refer to Table 8-6 for a listing of the bearer capability codes and their definitions.

Table 8-6 Information Transfer Capability Values for IOS

Bearer Capability

Information Transfer Capability

User Information Layer 1 Protocol

0x8090A2

Speech

G.711 μ-law Speech

0x8090A3

Speech

G.711 A-law

0x9090A2

3.1 kHz Audio

G.711 μ-law Speech

0x9090A3

3.1 kHz Audio

G.711 A-law

0x8890A2

Unrestricted digital information

G.711 μ-law Speech

0x8890A3

Unrestricted digital information

G.711 A-law

0x8890

Unrestricted digital information

64 kbps (64 kbps-data call)


In the next octet, the transfer information rate specifies how many B channels are used on the call. This value is used in tandem with the rate multiplier. However, if only one B channel is to be used on the call, the rate multiplier is not used. The Layer 1 protocol field in octet 5 identifies the voice companding algorithm. This field is useful in troubleshooting, particularly if it is suspected that there is an A-law μ-law mismatch between devices.

Channel ID

The next IE you will see in an output is the channel ID. The channel ID (as with all of the output in a Q.931 debug), is listed in hexadecimal format, as shown in Example 8-3.

Example 8-3 Q.931 Call Setup Showing the Channel ID Value

TX -> SETUP pd = 8 callref = 0x04
 Bearer Capability i = 0x8890
 Channel ID i = 0x83
 Called Party Number i = 0x80, ´9195551212'
RX <- CALL_PROC pd = 8 callref = 0x84
 Channel ID i = 0x89
RX <- CONNECT pd = 8 callref = 0x84
TX -> CONNECT_ACK pd = 8 callref = 0x04....

NOTE

Cisco IOS will default to a descending B channel selection order.

Figure 8-18 shows the actual channel ID IE.

Figure 8-18Figure 8-18 Channel ID IE Format

The purpose of this IE is to identify which channel is for bearer services that the signaling is controlling. It is possible to send multiple channels during the call setup phase to provide a selection in the event that a channel is unavailable at the call destination.

Within the message format there are several sections that allow for the channel selection to occur:

  • Octet 1 = This is the binary representation of the Channel ID IE. LSB first, it reads 00011000.

  • Octet 2 = Indicates the actual length of the channel identification.

  • Octet 3 = The last four octets are generally considered to be associated with octet 3:

    • The information channel selection identifies which B-Channel(s) is supposed to be used with an ISDN BRI circuit.

      • 00 = No channel

      • 10 = B channel #1

      • 01 = B channel #2

      • 11 = Any channel

    • The D channel indicator specifies whether the requested channel is actually the D channel. If it is, this field is flagged as a 1.

    • The P/E field states whether the channel specified is preferred or exclusive. If it is exclusive, no other channels can be used.

    • Spare is not used and is always set to 0.

    • The interface specifies whether the circuit is BRI or PRI. BRI is indicated with a 0 and PRI is indicated with a 1.

    • Interface ID is associated with ISDN non-facility associated signaling (NFAS) circuits.

    • The channel type specifies if the channel is a B channel or an H channel (used with B-ISDN).

    • The number/map bit identifies whether the following octet has a channel number (BRI) or a channel map (PRI).

    • The final octet specifies the B channel associated with the PRI circuit. The value identified equals the timeslot on the circuit.

Called and Calling Party IEs

The calling and called number IEs specify the originating and destination numbers associated with the call. The numbers can be a variety of coding structures but are generally seen as ITU E.164 numbers, which mimic telephone numbers. Figure 8-19 shows the formats associated with the calling and called party IEs.

Figure 8-19Figure 8-19 Calling and Called Party IE Format

The called party IE contains several significant fields. The type of number field describes what kind of number the called party is (LSB first):

  • Unknown = 000
  • International = 100
  • National = 010
  • Network Specific Number = 110
  • Subscriber Number = 001
  • Abbreviated Number = 011
  • Reserved = 111

Only unknown, international, national, and subscriber numbers are supported under the numbering plan field. The numbering plan identification field identifies what type of numbering plan is being used for the ISDN number (LSB first):

  • Unknown = 0000
  • ISDN Numbering Plan E.164 = 1000
  • Data Numbering Plan X.121 = 1100
  • Telex Numbering Plan F.69 = 0010
  • National Numbering Plan = 0001
  • Private Numbering Plan = 1001
  • Reserved = 1111

The most common numbering plan type you will see is the E.164 numbering plan. The number digits field identifies the actual digits dialed.

The calling party IE has many of the same fields but adds the screening indicator and the presentation indicator. Screening allows the ISDN device to decide on whether the user is allowed to connect. In other words, if the called party has a call screening application in place they can deny calls from specific ISDN numbers.

In the case of an unsuccessful call setup in ISDN, there is a cause code given. The cause code specifies why the call was not able to complete. The cause codes, when given in IOS, are specified in hexadecimal along with a brief description.

SS7 and ISDN

Because ISDN is a local loop technology, it needs to interface to other signaling methods to transport calls all the way through the service provider's network. The call is transported through the network as ISDN, converted to SS7, transported through the service provider's network, and then converted back into ISDN, with protocol conversions taking place at the ingress and egress ISDN switch points within the network. Figure 8-20 shows a general protocol-to-protocol call flow as it is seen in the service provider's network. The IEs associated with ISDN and the IEs associated with SS7 do not map 100 percent. Therefore, it is certainly possible for there to be interworking issues, particularly because there are so many variations of SS7.

Figure 8-20Figure 8-20 ISDN to SS7 Call Flow

Cisco Press Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from Cisco Press and its family of brands. I can unsubscribe at any time.

Overview

Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about Cisco Press products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites; develop new products and services; conduct educational research; and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@ciscopress.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security

Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children

This site is not directed to children under the age of 13.

Marketing

Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out

Users can always make an informed choice as to whether they should proceed with certain services offered by Cisco Press. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.ciscopress.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links

This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020