The same qualities that make an intelligent network so flexible also make verifying and maintaining intelligent network services a challenge. Instead of a canned diagnostic approach, manufacturers and service providers require a test mechanism that allows them to create customized message contents and message flows.

An intelligent network consists of various network elements working together with shared control, data and resources to achieve rapid and efficient deployment of telecommunications services. Its fundamental elements are the service switching point (SSP), the intelligent peripheral and the service control point (SCP).

The SSP is logically represented by an abstract model called the basic call model. This model allows the service logic in the SCP to use trigger and event report mechanisms to interrupt normal POTS call handling so that new services can be created.

The model moves service logic intelligence from the SSP to the SCP. Implementing new services or modifying existing services can now be performed by modifying or creating the new service logic at the SCP instead of at the SSP.

The intelligent peripheral nodes provide a uniform resource type, availability and capability to the SSP and to the service logic in the SCP. Traditionally, resources become available as SSPs are added. With the shared resources in the intelligent peripheral, the network now has a consistent view of what resources are available and how to use them. By deploying intelligent peripheral nodes, resources do not need to be replicated for every SSP deployed.

The SCP acts as the service execution node that executes a service logic program and instructs the SSPs via the SS7 network. The data required for various services may be located within the same SCP or within an external SCP.

The service logic program is a collection of various generic functional blocks called service independent blocks (Figure 1). These are basic telecom service building blocks that can be reused to form new services. Service providers can create new service logic programs, and ultimately new services, via the service creation environment (SCE).

The SCE provides an abstract, high-level programming environment for creating telecom services. It is analogous to the environment computer software programmers use for high-level programming languages such as C or C++.

The SCE provides a network-independent programming environment that allows service providers to quickly deploy various customized services, independent of who supplies the network elements.

Before the intelligent network existed, new service deployments usually were accompanied by the introduction of new protocols, which were limited in their design and capabilities. These protocols were deterministic in nature since the protocol messages and their sequences were defined for each service.

Therefore, canned applications were developed to verify and maintain the non-intelligent network services. In contrast, programmability in an intelligent network brings about a non-deterministic approach to protocol diagnostics at the physical level.

Protocols deployed in an intelligent network are de- signed as a generic vehicle for carrying instructions from an SCP to various network elements. The Advanced Intelligent Network protocol and intelligent network application part (INAP) are non-service specific protocols and can be thought of as an instruction set for the telecommunications network's assembly language.

Since the intelligent network protocols are service-independent, message sequences are not predefined and message contents are not specified. The choice of INAP or AIN messages and their sequences are defined according to the services they perform. Messages and the sequence used in carrying out service A will differ from what is used to carry out service B.

Moreover, the same service may yield different protocol message flows because of variation in implementation of SCEs and service execution functions. This is analogous to compiling a high-level C programming language into its assembly language counterpart. Different optimization or schema used in the implementation of a service creation environment and service execution function may result in different but identifiable flows of AIN or INAP protocols in the physical plane.

The test creation environment Because of the varying nature of the protocol message flow, a canned diagnostic approach to AIN and INAP protocol verification cannot be achieved. Diagnosis of the intelligent network at the protocol level requires a powerful protocol analysis platform.

That platform must provide both manufacturers and service providers with highly flexible tool sets that allow the creation of any AIN and INAP protocol message contents and protocol message flows for simulation, capacity validation and monitoring purposes.

The goal would be to have a test creation environment that is analogous to the SCE. A test creation environment can provide the user with an environment that supports the creation, management and execution of various AIN and INAP test cases.

As the counterpart to the SCE, the test creation environment allows the user to create test cases to match any protocol message that flows from the service logic programs executed by the SCP. One approach is to use a protocol-adaptable state machine as a diagnostic platform.

The test creation and management functions that this environment enables answer three of the most fundamental intelligent network protocol verification questions: which messages to use, how these messages are to be transmitted or received, and which set of data is to be manipulated.

The first question deals with the definition, structures and contents of the AIN or INAP messages used in a test case. For a given intelligent network service, a finite set of AIN or INAP messages can be identified. A test creation environment provides a protocol editing service that allows the user to create a collection of the identified messages.

The second question involves defining the sequence in which messages are to be transmitted or received during a test execution. The test creation environment handles this by providing a sequence creation service based on the finite state machine concept.

With a state machine, users can specify exactly the sequence of transmitted or received messages along with their relationship. For example, users might specify that Message A will be transmitted first, and the test should wait for either Message C or Message B to come back (Figure 2).

As the message sequence is identified, two types of protocol data - static and dynamic - must be considered by carriers.

Static data can be determined before the execution of a test case. An example of a static data item is the type of equipment originating a call.

Dynamic data can be determined only during a test execution because it requires real-time manipulation of data, which may be evaluated only during test execution. The test creation environment allows the user to assign static data values and operations to handle dynamic data items in real time during a test execution.

The test creation environment also can create fault scenarios to verify the robustness of service logic execution. A verification environment can be created to develop functional and load verification of intelligent network offerings before the services are actually deployed (Figure 3).

Applying a test creation environment for intelligent network verification does not need to be limited to protocol verification at the physical intelligent network plane. Depending on the implementation of the service execution function and SCE, the test creation environment concept can be applied directly at various intelligent network planes defined in the intelligent network conceptual model.

This virtual testing method enables carriers to verify intelligent network service implementation without using any hardware resources; all intelligent network functions can be simulated in software using the test creation environment. This method can be beneficial since better software tools, such as a source-level debugger, can be used to trace and exercise the execution of service logic programs.

The traditional method of protocol testing and diagnosis is no longer adequate. The test creation environment is the first step toward providing a service verification and maintenance platform with enough power and flexibility to match what is provided by the intelligent network.

Dan Bantukul is Product Marketing Manager for Intelligent Network Diagnostics at Tekelec, Morrisville, N.C. His e-mail address is dan.bantukul@tekelec.com.