Integrated Services Digital Network Primer

This chapter is from the book

Telecommunications Technologies Reference

Learn More Buy

This chapter is from the book

This chapter is from the book 

Telecommunications Technologies Reference

Learn More Buy

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.

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-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-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

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

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

Figure 8-8 Q.921 Control Octets

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-9 Q.921 TEI Request and Confirmation

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-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-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

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.

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-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-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)

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-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-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-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-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

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

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....

Figure 8-18 shows the actual channel ID IE.

Figure 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-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-20 ISDN to SS7 Call Flow