Intelligent Network (IN)

The first service introduced in the PSTN with the help of network databases in 1980 was calling card service; soon after that, a series of value-added services for businesses called inward wide area telecommunications service (INWATS) were introduced. When the U.S. Federal Communications Commission (FCC) approved a tariff for expanded 800 service in 1982, the Bell system was ready to support it with many new features due to the distributed nature of the implementation. For example, a customer dialing an 800 number of a corporation could be connected to a particular office depending on the time of day or day of week. As the development of such features progressed, it became clear that in many cases it would be more efficient to decide how to route a customer’s call after prompting the customer with a message that provided several options, and instructions on how to select them by pushing dial buttons on the customer’s telephone. For the purpose of customer interaction, new devices that could maintain both the circuit connections to customers (in order to play announcements and collect digits) and connections to the SS No. 7 network (to receive instructions and report results to the databases) were invented and deployed. The network database ceased to be just a database—its role was not simply to return responses to the switch queries but also to instruct the switches and other devices as to how to proceed with the call. Computers previously employed only for storing the databases were programmed with the so-called service logic, which consisted of scripts describing the service. This was the historical point at which the service logic started to migrate from the switches.

After the 1984 court decree broke up the Bell System, the newly created Regional Bell Operating Companies (RBOCs) ordered their R&D arm, Bell Communications Research, to develop a general architecture and specific requirements for central, network-based support of services. An urgent need for such an architecture was dictated by the necessity of buying the equipment from multiple vendors. This development resulted in two business tasks that Bellcore was to tackle while developing the new architecture: (1) The result had to be equipment-independent and (2) as many service functional capabilities as possible were to move out of the switches (to make them cheaper). The tasks were to be accomplished by developing the requirements and getting the vendors to agree to them. As Bellcore researchers and engineers were developing the new architecture, they promoted it under the name of Intelligent Network. The main result of the Bellcore work was a set of specifications called Advanced Intelligent Network (AIN), which went through several releases.

AT&T, meanwhile, continued to develop its existing architecture, and its manufacturing arm, AT&T Network Systems, built products for the AT&T network and RBOCs. Only the latter market, however, required adherence to the AIN specifications. In the second half of the 1980s, similar developments took place around the world—in Europe, Japan, and Australia. In 1989, a standards project was initiated in ITU to develop recommendations for the interfaces and protocols in support of Intelligent Network (IN).

To conclude the historical review of IN, we give you some numbers: Today, in the United States, at least half of all interexchange carrier voice calls are IN supported. This generates on the order of $20 billion in revenue for IXCs. LECs use IN to implement local number portability (LNP), calling name and message delivery, flexible call waiting, 800 service carrier selection, and a variety of other services (Kozik et al., 1998). The IN technology also blends wireless networks and the PSTN, is being used strategically in the PSTN-Internet convergence.

We are ready now to formulate a general definition of IN: IN is an architectural concept for the real-time execution of network services and customer applications. The architecture is based on two main principles: network independence and service independence. Network independence means that the IN function is separated from the basic switching functions as well as the means of interconnection of the switches and other network components. Service independence means that the IN is to support a wide variety of services by using common building blocks.

The IN execution environment includes the switches, computers, and specialized devices, which, at the minimum, can communicate with the telephone user by playing announcements and recognizing dial tones. (More sophisticated versions of such devices can also convert text to voice and even vice versa, send and receive faxes, and bridge teleconferences). All these components are interconnected by means of a data communications network. The network can be as small as the local area network (LAN), in which case the computers and devices serve one switch (typically a PBX), or it can span most switches in an IXC or LEC. In the latter case, the data network is SS No. 7, and usually the term IN means this particular network-wide arrangement. [In the case of a single switch, the technology is called computer-telephony integration (CTI).]

The overall IN architecture also includes the so-called service creation and service management systems used to program the services and distribute these programs and other data necessary for their execution among the involved entities.

Figure 1 depicts the network-wide IN execution environment. We will need to introduce more jargon now. The service logic is executed by a service control point (SCP), which is queried—using the SS No. 7 transaction mechanism—by the switches. The switches issue such queries when their internal logic detects triggers (such as a telephone number that cannot be translated locally, a need to authorize a call, an event on the line—such as called party being busy, etc.). The SCP typically responds to the queries, but it can also start services (such as wake-up call) on its own by issuing an instruction to a switch to start a call.

Figure 1: The IN architecture.

As we noted before, to support certain service features (such as 800 number translation), the SCP may need to employ special devices (in order to play announcements and collect digits or establish a conference bridge). This job is performed by the intelligent peripheral (IP). The IP is connected to the telephone network via a line or trunk, which enables it to communicate with a human via a voice circuit. The IP may be also connected to the SS No. 7 network, which allows it to receive instructions from the SCP and respond to them. (Alternatively, the SCP instructions can be relayed to the IP through the switch to which it is connected.) As SCPs have become executors of services (rather than just the databases they used to be), the function of the databases has been moved to devices called service data points (SDPs).

Finally, there is another device, called a service node (SN), which is a hybrid of the IP, the SCP, and a rather small switch. Similar to the SCP, the SN is a general-purpose computer, but unlike the SCP it is equipped with exotic devices such as switching fabric and other things typically associated with an IP. The SN connects to the network via the ISDN access mechanism, and it runs its own service logic, which is typically engaged when a switch routes a call to it. An example of its typical use is in voice-mail service. When a switch detects that the called party is busy, it forwards the call to the SN, which plays the announcement, interacts with the caller, stores voice messages and reads them back, and so on. The protocols used for the switch-to-SCP, SCP-to-SDP, and SCP-to-IP communications are known as Intelligent Network Application Part (INAP), which is the umbrella name. INAP, has evolved from the CCS switch-to-database transaction interactions; it is presently based on the Transaction Capabilities (TC) protocol of Signalling System No. 7.

Because the SCP and SN are general-purpose computers, they can be easily connected to the Internet and thus engage the Internet endpoints in the PSTN services. This observation was made as early as 1995, and it has already had far-reaching consequences, as will be seen in the material that follows.