This document provides supplementary information to the System Manager Guide that is specific to the Sprint Site Remote Processor (RP) and Enhanced Site RP network interface.
For more information on document conventions, see the Cisco Technical Tips Conventions.
Readers of this document should be knowledgeable of the following:
The information in this document is based on the software and hardware versions below.
The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.
The Sprint Intelligent Network Service Delivery facility allows customer premise-based equipment to participate in the Sprint Network N00-number (for example: 700, 800, 900) call routing. A set of Service Control Points (SCPs) in the Sprint network provide the communications function between the Sprint network and customer premises equipment (called External Routing Processor, or “SiteRP”) involved in the call routing process.
The SCP is an end node responsible for processing N00-number call inquiry requests received from telephone switches throughout the Sprint network. The SiteRP node is an end node located at a customer site to which the SCP redirects inquiry requests. Cisco ICM assumes the role of the SiteRP. The SiteRP interface in the ICM system is implemented as a Microsoft Windows NT process, known as the Sprint NIC, running on the ICM Central Controller. ICM receives call inquiries from and returns inquiry responses to the Sprint network through the Sprint NIC.
The SCP executes N00-number routing plans the customer, in conjunction with Sprint, creates and maintains using the Sprint routing control applications. The N00-number routing plans specify the forwarding of call inquiry requests from the SCP to the SiteRP.
The Sprint network incorporates fault-tolerance for network nodes and communications links. Currently, there are five geographically distributed SCPs in the Sprint network. One of the five SCPs is a back-up, ready to assume the load of any one of the four active SCPs, should an outage occur. Each SCP shares the routing load in the network and has spare capacity to ride through SCP outages.
A SiteRP is typically connected to each of the five SCPs through a Sprint-provided 56-kilobit Fibernet circuit. In the event of an SCP failure, the back-up SCP picks up the load. In the event of a link failure between an SCP and a SiteRP, Sprint Fibernet provides automatic re-routing of the data links. Each SCP continues to communicate with the SiteRP through an alternate path and no redistribution of load is required. The International Telecommunication Union Telecommunication Standardization Sector (ITU-T) (1984) standard X.25 link protocol is used to interconnect each SCP to each SiteRP.
The Sprint network architecture supports both link redundancy and node redundancy. Redundant links from a SiteRP to the SCPs may be used. Redundant SiteRPs are supported. Each of the redundant SiteRPs must be connected to each Sprint SCP using at least one data link. All the SiteRPs in a redundant configuration are used by the Sprint SCPs in a load sharing manner. Figure 1 depicts the Sprint Network routing architecture.
Figure 1: Sprint Network Architecture
In Cisco ICM terminology, the Sprint NIC is a logical interface controller that connects the ICM to the SCPs in the Sprint network.
For reliability, the Sprint NIC can be duplexed, for example, a pair of computers is used to perform the job of a single Sprint NIC. Each computer is a separate physical interface controller. Both computers however, correspond to the same logical interface controller. The Sprint network perceives this configuration as a single SiteRP with redundant links to the SCPs.
A single SiteRP corresponds to one logical interface controller and either one or two physical interface controllers.
A routing client is an abstraction for any source of routing requests processed by Cisco ICM. The Sprint NIC behaves as a routing client on behalf of the Sprint network. In the Sprint network, a single SiteRP (consisting of either one or two Sprint NICs) is regarded as one routing client by ICM.
A label is an identifier associated with a particular termination or branch within a N00-number routing tree. When an SCP sends a route request to ICM, it expects to receive a reply message that contains a select code. The label can specify one of several possible call termination types or, alternatively, can specify continued execution under the current routing plan.
The label types defined by ICM are a superset of the select code types defined by Sprint SiteRP. The relationship between ICM labels and SiteRP select codes is described below.
Note: Valid SiteRP select codes must contain only valid ASCII characters and must not exceed 10 characters in length.
Cisco ICM destination label maps directly to a SiteRP, select code of type " T ".
Cisco ICM defines a special announcement label, @NPA Blocked Recording, for the Sprint SiteRP interface. This special announcement label maps to the SiteRP select code type, R with the reject treatment code of 02. The SiteRP select code type, R is used to reject a N00-number call. The reject treatment code, 02 directs a N00-number call to a recording which states, “The number you have dialed cannot be called from this calling area.” All other ICM announcement labels map to SiteRP select codes of type, T.
Cisco ICM defines a special busy label , @Slow Busy, for the Sprint SiteRP interface. This special busy label maps to the SiteRP select code type, R with the reject treatment code 01. The reject treatment code 01 directs an N00-number call to the “network busy” node.
Cisco ICM ring label is not supported in the Sprint SiteRP interface.
Cisco ICM post-query label maps to a SiteRP select code type T.
The ICM DNIS override label is not supported in the Sprint SiteRP interface.
This section describes configuration requirements specific to Sprint NIC. Configuration data created and maintained by you, is kept in the Cisco ICM database. This data is managed using the Configure_ICR tool. Additional configuration data created and maintained by Cisco is kept in the Microsoft Windows NT registry on the ICM Central Controller, where Sprint NIC resides.
This section describes the use of Configure_ICR to add Sprint NIC specific configuration elements to the ICM database.
The following parameter settings are required for the Sprint NIC:
| Controller Type
|| Network Interface Controller
| Client Type
| Configuration Parameters
|| None required
There are no parameter settings required specific to the Sprint NIC.
The following parameter settings are required for the Sprint NIC:
| Timeout threshold
| Late threshold
| Timeout limit
| Configuration parameters
|| None required
Local configuration data for the Sprint NIC is kept in the Microsoft Windows NT registry on the Cisco ICM Central Controller. The registry keys are created during the ICM CallRouter Device Setup with the Sprint NIC option selected. The configuration data specifies the parameters of the SiteRP network interface as well as internal ICM parameters.
Prior to the release of ICM version 4.1, no changes were required although the correct labeling of the SCP entries is helpful. Starting with the release of ICM version 4.1, there is a new Windows NT Registry entry for each SCP starting with “SCP1CardNumbers”. They specify which card each SCP port resides. The individual bytes in the long word indicate the Eicon card numbers. The high order byte contains the card number of the first port used by the SCP while the low order byte contains the card number of the fourth port used by the SCP. The default values assume that only one port is used by each SCP and that the Eicon cards used by the SCP start with number one.
For example: SCP1CardNumbers:REG_DWORD:0x1000000 indicates the first SCP has a single port residing on card number one while SCP1CardNumbers:REG_DWORD:0x1010200 indicates the first SCP has three ports with the first and second ports residing on card one while the third port resides on card two.
The Sprint network does not support the following Cisco ICM features:
There are five SCPs in the Sprint network. In a duplexed Cisco ICM environment, each NIC connects to the Sprint network using five 56-kbps point-to-point communication links, one to each SCP, provisioned on the Sprint Fibernet network. The five communications links are five DS0 channels derived from a dedicated T1.5 circuit. Two T1.5 circuits are provisioned on the Sprint Fibernet network to connect the duplexed ICM to the five Sprint SCPs. The Sprint Fibernet circuit terminating equipment for each side of a duplexed ICM consists of a channel bank-like device called TP7. The terminating equipment is provided by Sprint.
Each Sprint NIC contains three Eicon Technology Dual-Port Network Adapter/PC (DPNA) cards. The two ports on a DPNA card are designated as port 1 and port 2, where port 1 is the port closest to the top edge of the card and port 2 is the port closest to the PC connector edge of the card. Five of the six DPNA ports are used to connect to the SCPs. The remaining DPNA port is not used and is disabled. In a simplexed ICM configuration, five DPNA cards are required if the Sprint NIC is connected to the SCPs through redundant links.
Cisco supplies five 9-foot cables, each of which connects from a DPNA port to the Sprint circuit terminating equipment using a V.35 interface. The cable has a male DB-26 connector to the DPNA card and a standard male 34-pin V.35 connector to the Sprint circuit terminating device. The communication links are routed to the SCPs in the Sprint network. The physical network interface for the duplexed ICM configuration is shown in Figure 2.
Figure 2: Network Interface for Duplexed ICM Configuration
Cisco ICM may be deployed in either colocated or geographically separated configurations. The physical connection to the Sprint network is the same in both ICM configurations. As mentioned in Logical and Physical Interface Controllers, ICM (in either configuration) is logically considered as one single SiteRP to the Sprint network. In a colocated configuration, the ICM nodes are connected using LAN. In a geographically separated configuration, the ICM nodes communicate using WAN.
In a colocated configuration, ICM may be either simplexed or duplexed. In either case, ICM connects to all the SCPs in the Sprint network through redundant links. Ten dedicated point-to-point links connect ICM to the SCPs, as shown in Figure 2. Redundant links from a simplexed ICM to the SCPs are recommended. Simplexed links from a simplexed ICM to the SCPs, although not recommended, are also supported.
In a geographically separated configuration, Cisco ICM connects to the Sprint network SCPs using a total of ten physical connections (five from each Central Controller site), as shown in Figure 2. An SCP spreads the traffic to a SiteRP over the direct connect links.
Upon startup, the Sprint NIC calls the Eicon card administration command ecmodule status to get a list of active virtual circuits (if any), and it then hangs up those connections in an attempt to flush out lingering SVCs from a previous run. Since the Eicon card setup program does not set up a path to the command line utilities such as ecmodule, this must be done manually.
The path environment variable already exists on Microsoft Windows 2000/NT.
Select the path variable from the category of user variables.
Move the cursor to the end of the text field.
Add it to the directory where Eicon card administration commands reside.
To ensure the path is set correctly, run ecmodule status x25 from a command window, the output should look like Figure 3. Figure 3: Output of ecmodule status x25
The following Sprint SiteRP interface features are not supported by the current implementation of the Sprint NIC:
EnhanCED SiteRP supports routing based on call context information carried in the EnhanCED inquiry message, such as Caller Entered Digits (CED), as well as all SiteRP routing features.
The Sprint NIC conveys call context information carried in inquiry messages (both EnhanCED Inquiry and Inquiry) to the Router through peripheral variables, with an exception that CED is accessed through a dedicated script node. The Script Editor allows the user to examine the value of peripheral variables and direct script execution to the desired branch. There are ten peripheral variables defined, from PeripheralVariable1 to PeripheralVariable10. For convenience, PeripheralVariableN is referred as PV#N in the following sections.
The CED node is used in a routing script to differentiate various values of Customer Entered Digits, see Figure 4 for an example.
Figure 4: CED Routing Script
The X25 label is populated into PV#1. The script “IF” node may be used to check the value of PV#1. Figure 5 shows an example of X25 label routing script. X25 label routing is not new with EnhanCED SiteRP. The preceding supports SiteRP as well.
Figure 5: X25 Label Routing Script
II Digit and Feature Indicator exclusively exist. PV#2 represents II Digit in the case an EnhanCED inquiry message is received and represents Feature Indicator in the case an inquiry message is received. Since the formats are different, you can differentiate one from the other in a routing script by examining the value of PV#2.
An Object (excluding CED) is populated into a peripheral variable (PV#3 ~ PV#10) in the format of “Type(2 characters) + Nature(2 characters) + Content(≤ 35 characters) + \02 ”, where the plus sign does not really exist. For example, if an object has Type 03h (like DNIS), Nature 02h and Digits “1111”, the corresponding peripheral variable is encoded as “03021111\0”. Notice there is no fixed mapping between the object and peripheral variable. For example, PV#3 might represent DNIS or SSN. Objects can be identified according to the first four characters. Figure 5 shows an example of routing based on DNIS (Type: 03h, Nature: 02h) and SSN (Type: 0Bh, Nature: 02h). Label “SELCOD02” is returned if the first three digits of DNIS are “111” and the first three digits of SSN are “018”; label “SELCOD03” is returned if the first three digits of DNIS are “111” and the first three digits of SSN are “019”; the SelectCodeType “E” is returned otherwise.
The Sprint NIC accepts, at most, 35 characters as the content of an object (see the following note for explanation). The excess is truncated, which causes an unconditional tracing message to be generated.
Note: Since a peripheral variable has the length limit of 40 characters, this format explains why the Sprint NIC accepts, at most, 35 characters as the content of an object. While this does not generate the prefix of “Type + Nature” for CED, the 35-character limit also applies to it for consistency.
The Sprint NIC is able to process at most eight objects excluding CED, as shown in Figure 6, because there are ten peripheral variables available, and PV#1 and PV#2 are used for X25 label and II digit (or feature indicator) respectively. If an EnhanCED inquiry message contains more than eight objects excluding CED, the Sprint NIC discards the excess and generates an unconditional tracing message.
Figure 6: DNIS Object and SSN Object Routing Script