PRI
PRI is a larger offering of N-ISDN that accommodates more bandwidth and that offers more flexibility. For PBX uses or where SS7 is not readily available, PRI allows for the transmission of voice and data over a single link. In North America and Japan, PRI is deployed over a T1 facility and comprises 23 B channels and a full 64-kbps D channel. In most other international countries, PRI is deployed over E1 facilities using 30 B channels and a 64-kbps D channel. International PRI is also referred to as ISDN-30.
The easiest way to think about PRI is to remember that it is merely ISDN deployed over T- or E-carrier facilities. As a subscriber, this means that you have to configure the T1 or E1 controller first and then add the ISDN functionality. PRI does not use elements such as SPIDs for connectivity to the switch, and the TEI is always set to 0 (because it is a point-to-point connection).
ISDN PRI requires that ISDN facilities are available at the CO. In recent years it has become difficult to keep up with the demand. PRI is still a local loop technology, as is BRI, but it can be expensive depending on the tariff of the associated carrier circuit.
PRI is popular in enterprise voice applications because it does not require any knowledge of SS7 to provide voice service. In many areas, PRI is preferred to SS7 even though SS7 is less expensive. Typically, enterprise customers deploy PRI circuits from their corporate headquarters to remote locations or over dry copper within the same location to facilitate PBX connectivity between all sites. Dry copper is a portion of the circuit that does not go through the service provider's network but is completely contained within the customer's private network.
A more recent application of PRI connectivity is to have ISDN on the local loop and then use a private Voice over Internet Protocol (VoIP) network as the transport system for the long distance haul between sites. At the destination, the call is dumped out of the IP network, back onto PRI facilities, thus saving the customer long distance charges while maintaining the features of ISDN PRI.
Basic PRI deployment is the same as with E1 or T1 circuit deployment, with the addition of the ISDN cards at the CO and the ISDN support at the user end. For this reason, you need to have a channel service unit (CSU)/DSU to terminate the E1 or T1 circuit and then be able to add ISDN support on top of that. The line coding and framing associated with PRI is not discussed in detail because they are the same formats that are used on standard T1 and E1 circuits. For more information on these coding standards, refer to Chapter 5, "T1 Technology," and Chapter 6, "E1, R2, and Japanese Carrier Technology."
The big difference in PRI is how it is deployed in Japan. Japanese PRI, also called INS-Net 1500 by NTT, is normally deployed by using fiber optics to the customer's premises. Figure 8-26 shows the different deployment methods that are supported in Japan with PRI circuits. NTT in Japan offers two main services, one with 23 B+D service and one with 24 B+D service. The 24 B+D service is offered by sending the D channel through a separate trunk to the customer's premises. Therefore, the customer has access to all 24 B channels on the other circuit.
)
Figure 8-26 Japanese Deployment of a PRI Circuit
NFAS
NFAS is a function of ISDN that is typically only supported in the U.S. and that allows your equipment to be more efficient with channel use if more than one PRI circuit is in use. The basic premise of NFAS is to take a single D channel and configure it so that it can control multiple PRI circuits (up to 479 B channels). NFAS is limited to 479 B channels because the D channel is only 64 kbps. If you have five PRI circuits coming into the same router, you can use NFAS to reclaim a 64-kbps B channel on four of the circuits. Figure 8-27 shows the use of one ISDN D channel to control multiple PRI circuits to reclaim DS0s for bearer traffic.
)
Figure 8-27 NFAS Configuration with Multiple PRI Circuits
The configuration in Example 8-5 shows three T1 controllers, using PRI, that are controlled by the same D channel. The first interface is set up as the primary D channel. For the sake of redundancy, another controller can be set up as the backup D channel, in the case of a loss of signal (LOS) on the primary circuit.
As with any ISDN configuration, you must configure the ISDN switch type in global configuration mode first.
Example 8-5 Configuration of NFAS on a T1 PRI Circuit Group
isdn switch-type primary-ni -=snip=- controller T1 0 framing esf clock source line primary linecode b8zs pri-group timeslots 1-24 nfas_d primary nfas_int 0 nfas_group 0 ! controller T1 1 framing esf clock source line secondary 1 linecode b8zs pri-group timeslots 1-24 nfas_d backup nfas_int 1 nfas_group 0 ! controller T1 2 framing esf clock source line secondary 2 linecode b8zs pri-group timeslots 1-24 nfas_d none nfas_int 2 nfas_group 0
Configuring a T1 and E1 PRI Connection
T1 and E1 PRI configuration is simple. The first thing that you must do is configure the ISDN switch type in global configuration mode and then configure the T1 or E1 controller. Example 8-6 shows a T1 configuration.
Example 8-6 T1 Configuration
Raleigh#conf t Raleigh(config)#isdn switch-type primary-ni Raleigh(config)#controller t1 7/0 Raleigh(config-controller)#framing esf Raleigh(config-controller)#linecode b8zs Raleigh(config-controller)#clock source line primary Raleigh(config-controller)#cablelength short 133 Raleigh(config-controller)#pri-group timeslots 1-24
NOTE
In the T1 configuration there is a command for cable length. Remember, this is used in DSX-1 or short-haul applications for T1.
Example 8-7 shows an E1 configuration.
Example 8-7 E1 Configuration
Raleigh#conf t Raleigh(config)#isdn switch-type primary-net5 Raleigh(config)#controller e1 7/0 Raleigh(config-controller)#framing no-crc4 Raleigh(config-controller)#linecode hdb3 Raleigh(config-controller)#clock source line primary Raleigh(config-controller)#pri-group timeslots 1-31
NOTE
HDB3 is the default line coding and does not have to be configured if that is what you are using. Although AMI is an option, it is almost never used for E1 circuits. To set up a Japanese PRI, you can use the primary-ntt switch type in IOS.
After the controllers have been configured with the pri-group command, you can configure the D channel. Any of the group-based commands in IOS create a virtual serial interface. In this case, it is the D channel. Typically, it is referred to as the controller/D channel. T1 PRI can be something along the lines of 7/0:23 and E1 can be 7/0:15. The virtual serial interfaces that are created are zero-based count.
A typical D-channel configuration might look something similar to Example 8-8.
Example 8-8 Configuration of an ISDN PRI D Channel
interface serial 7/0:23 no ip address isdn switch-type primary-ni isdn incoming-voice modem isdn protocol-emulate network isdn bchan-number-order ascending
This configuration is specifically for a back-to-back T1 PRI on an AS5400. You can tell it is back-to-back by the isdn protocol-emulate network command. That command sets this router to act as the network side of the ISDN connection.
The command isdn incoming-voice modem specifies that incoming calls are treated as inbound analog modem calls and are connected to the proper resources within the device. This same command can map inbound voice calls to the proper voice resources for VoIP when using an AS5300.
The command isdn bchan-number-order ascending specifies which direction the B channel selection occurs. The choices are ascending or descending (default).
Resolving Issues with ISDN PRI
Many of the same troubleshooting techniques involved with PRI circuits are standard with T1 and E1 circuits. First and foremost, check to make sure that your controller is up and that no alarms are being detected. As a refresher, a red alarm is if you are receiving a loss of frame (LOF) or LOS. This means that you are unable to receive the proper information from the service provider's network. Next, look for a yellow or blue alarm, also called and alarm indication signal (AIS). If you are receiving a red alarm, your equipment attempts to send a yellow alarm to the remote end to notify them that you are experiencing a problem. The blue alarm is sent from the service provider to both ends of the circuit to notify them that there is a problem within the service provider's network cloud.
After you have verified that there are no alarms detected, check your controller for path code violations and clock slips. Severe clocking slips can cause your circuit to malfunction even if the circuit hardware is operating properly.
The next thing that you should check is the ISDN network status (show isdn status). You are looking for Q.921 to be MULTIPLE_FRAME_ESTABLISHED. If that is the case, you should be able to make ISDN calls. If you are in a TEI_UNASSINED or AWAITING_ESTABLISHMENT state, you need to verify your configuration. Remember that if you are in a back-to-back configuration you have to set one of the sides to emulate the network. If you do not, you do not come up on Layer 2.
After you can place calls, the debug isdn q931 command becomes your greatest asset in troubleshooting ISDN calls. The first thing to monitor is the direction of the disconnect (are you sending or receiving it). You also want to make sure that the bearer capability is correct. In other words, if you are making a voice call, but it's coming in as data, you have a problem. Receiving a disconnect cause code of "Bearer Capability not Implemented" typically means that a command such as isdn incoming-voice modem is missing from the D channel configuration.
Next, take a look at the channel ID, and find out what the status of the attempted channel is with the show isdn status command. If the channel the call is being attempted on is B, for some reason it has been busied out. You can manually attempt to reset that B channel or the entire range (although the range isn't recommended in production environments).
Last but not least is certainly the cause code for the release. The q931 debug tells you what the cause code is, although it doesn't necessarily spell out the problem for you. They have a tendency to be rather cryptic.
Q.Sig
Q.Sig was developed for private integrated services network exchange (PINX) applications. Based on Q.931, Q.Sig is an evolving technology that allows communication with legacy PBX and key systems. When used with Cisco routers, Q.Sig can connect PBX systems with private IP networks or other service provider network service offerings. Using Q.Sig with private IP transport allows businesses long-haul transport of voice traffic without the need for inter-exchange carrier (IXC) interconnection, which saves on long distance charges.