Building a Reliable Intelligent Peripheral/Service Node

Steve Silberstang

Intelligent peripherals (IPs) and service nodes (SNs) are advanced intelligent network elements and must provide the reliability required for deployment and operation in the central office. Intelligent peripherals (IPs) work in cooperation with service control points (SCPs) to provide media services in support of call control. Service nodes combine the functions of the SCP and the IP. When viewed as point nodes in the network, these elements (IPs and SNs) are subject to failure and require redundant components and multiple communication paths. Software and procedures in support of central office reliability are also required.

The Bellcore recommendations call for multiple intelligent peripherals within the network, each of which is capable of working with multiple independent service control points (ISCPs) via communication across multiple data paths. Additionally, each IP is specified as being distributed across multiple host platforms interconnected by multiple local area networks. Accordingly, introducing IP capability into an AIN environment is a major effort, requiring significant investment in hardware, networking, and supporting software.

The Bellcore philosophy of providing redundant components and data paths to eliminate single points of failure is a good one. There are, however, many situations in which an IP or SN provides an ideal mechanism for supporting a service, yet the service does not warrant so great an investment in infrastructure. Instead, a solution is required in which the IP or SN provides suitable reliability in and of itself so that it may satisfy the overall reliability requirements of the service provider and still remain economically sound. This is certainly true for pilot programs, boutique applications, and offerings from smaller service providers.

This paper addresses the concerns of building and operating a reliable IP or SN. It describes the reliability issues associated with redundant components and multiple communication paths. A brief overview of how the IP and SN are placed within an AIN is presented, followed by a discussion of reliability with respect to hardware architecture. This is followed by a related discussion of software architecture. Finally, some IP/SN service creation concepts are discussed in terms of how a useful and practical IP/SN can be constructed and operated within an AIN.

The IP/SN within the AIN Architecture

Bellcore has defined 1129+ as the mechanism by which a service control point (SCP) calls upon the service of an intelligent peripheral (IP). The Bellcore specifications calls for multiple service control points (SCPs) and multiple intelligent peripherals (IPs), each with multiple hosts and multiple LANs (see Figure 2).

Capabilities of the Intelligent Peripheral

When the functions of the intelligent peripheral are decomposed in this manner, it becomes clear that there are different reliability requirements for different components. These basically fall into two categories -- application processing and resource processing. This is not surprising as many large scale, commercial media processing systems separate these functions as well.

The application processor supports the call processing logic and access to the databases and data networks. It communicates with the SCP to initiate transactions, receive instructions and report results. It also supports data connections to other network elements such as the service management subsystem (SMS) and other hosts. It encodes and decodes messages and houses the support services. It is here that the service logic resides, supplementing the call control functions of the SCP.

The resource processor manages the switching, voice channel facilities and media processing resources. The media processing normally requires extensive processing power (DSPs) and storage facilities (disk arrays) to handle the manipulation and storage of media streams. It may also require switching facilities such as internal time division multiplexor channels (e.g. SC-bus, PEB) or external switches (e.g. Summa Four, Excel, etc.).

These two elements are very different. They perform different functions and, more importantly, require very different hardware and software processing elements. Accordingly, the requirements for making them reliable and providing redundancy are also very different.

Redundancy for the Application Processor and the Resource Processor

Providing a duplex environment for the application processing functions is much easier and more economical if the media processing services are housed separately. Media processing facilities can only grow so large before they run into processing bottlenecks such as channel bandwidth, file access times, card slots, etc. When the media processing services are separated from the application processing services it becomes feasible to build an application processor capable of handling the entire processing workload with independent network and database access.

It is too expensive and overly complex to provide redundancy for the resource processor. The support and management of the channel connections to the voice network adds significant complexity. Rather than trying to make the media processor immune to failure, it makes more sense to spread these resources over multiple, simplex platforms so that the system can survive the loss of a single processing element without undue impact on the overall system performance. For this reason, N+1 redundancy for the resource processor is provided (See Figure 3).

Provisioning resource processors involves a tradeoff between footprint and density. On one hand, it is best to make resource processors as dense and large as possible to reduce footprint and cut costs. On the other hand, it is desirable to make the media processor as granular as possible so that an outage does not cost a large percentage of the network.

Multiple Control Paths

The application processors also require connections to communication networks and hosts. An IP needs multiple data paths because it must be able to contact multiple hosts and, in many cases, must be able to survive the loss of a single communication pathway. It needs to communicate with SCPs to receive instructions and with switching facilities in order to terminate circuits. It also needs to communicate with other network elements, such as the SMS (for provisioning) and to internal and external databases. This requires multiple data paths and alternate routing.

Host processors and networks are also cross-connected to application processors to support the functions of load balancing, automatic failover, and automatic failback (see Figure 5). The system should be able to survive the loss of any network component or any communication link without losing any capacity or service other than the N+1 capacity of the resource processor. The IP must be designed so that components can be taken out of service and returned to service gracefully for repair and upgrade (see Figure 6).

Software Architecture: Client, Router, Server

The router handles message routing and session management functions. It makes decisions about where to route traffic and how to balance load.

The servers support both local and remote devices. The local devices include local file systems, databases, and locally attached devices such as encryption boxes. The remote devices are networks and hosts. The remote servers must be multi-threaded in order to handle multiple transactions in flight They must support typical communication functions such as time-out and late response processing.

In order to provide reliable, continuous service, the intelligent peripheral must support multiple clients and multiple applications. Applications must operate somewhat independently of one another so that they have minimum impact on one another. They must be able to be brought up and taken down independently so that new applications and application upgrades can be safely installed without taking the entire system out of service.

The intelligent routing function of the software must be able to support multiple physical connections, the balancing of load between multiple connections, the detection of loss, and the rerouting of traffic. It must be able to bring links back in service automatically and manage session control for communication protocols that are session-oriented (see Figure 7).

It is also important for an intelligent peripheral to be able to support multiple servers across multiple data paths (see Figure 8). Servers must be able to be taken up and taken down independently of one another without disruption of service. Multiple servers must be accommodated for the support of multiple protocols, multiple paths, and multiple sessions required for intelligent peripherals.

Application Software

Reliability and the Service Creation Model

Service logic for the SCP is created using a service creation environment (SCE) to build a service logic program (SLP) using service independent building blocks (SIBBs). The SLP is then deployed to the service logic execution environment (SLEE) running on the SCP. The service creation environment for an IP should parallel this model. A service creation tool geared for media processing as opposed to call control is required to construct processing elements that work in concert with SIBBs to produce reusable processing elements.

Figure 9 depicts an IP with a separate application processor driving two voice response units. Calls are distributed by the Call Server to the 1129+ client application where a Provide Instructions message is constructed. These new calls are routed to the SCP/TCP/IP remote server for delivery to the SCP. Thereafter, SCP requests are received by the server and routed to the 1129+ client for decoding and interpretation. As required, the VRUs are asked to perform media processing on behalf of the application processor.

Some 1129+ instructions are not fully defined by the 1129+ interface specifications. Some instructions like Verify User require access to local or remote subscriber files. The catch all Play Application function is also not well defined by the interface document. An 1129+ local services module is provided to take these decoded requests and pass them to appropriate processing facilities. In this way there is a clear and clean separation of generic 1129+ processing function from site specific or command specific processing functions. The generic code is not altered from site to site or from application to application. This tends to increase the reliability of the base IP product and simplifies regression testing of new cooperating application modules.

Three types of Play Applications are shown in the diagram. Play App #1 shows an application that requires continued caller interaction. The 1129+ application, the original recipient of the call, passes the call off to an independent application using the Call Server. The Play App #1 client, router and server are shown on the right side of Figure 9. This application can be operated independently of the 1129+ application and can even be housed on its own processing platform. When it is through with its caller interaction it returns control of the call to the 1129+ application for response back to the SCP. This model, for example, could be used to solicit a restricted number from a caller for storage of the local application database.

Play App #2 is implemented using a local server. Accordingly, no 1129+ generic function need to be modified. Application requests and responses are passed between the 1129+ application and the local server using a well defined message interface. This, for example, would be used if a restricted card number had be solicited using 1129+ control (Play Announcement and Collect Digits) and now needed to be stored locally as a result of a Play Application request.

Play App #3 is similar to Play App #2 except that in this case, following the example, a remote server is used to add a number to a restricted list host on an external host.

Conclusion