Previous Table of Contents Next


Advanced Intelligent Networks (AINs)

Once upon a time, the networks were truly dumb. Through the 1960s, and even into the 1970s, they remained fairly dumb. In other worlds, the networks were composed largely of switches and pipes that could do little more than connect calls as directed, based on a hierarchical order of limited switching intelligence. That intelligence was in the form of very limited programmed logic, housed in databases that interacted at a minimal level. In other words, each switch performed its own job, with little thought of the network, as a whole.

Intelligent Network, Version 1 (IN/1) was born in 1976, with the introduction of IN-WATS (800) services and the first Common Channel Signaling (CCS) system. IN/1 provided for the switches to consult centralized, service- and customer-specific databases (Figure 11.12) for routing instructions and authorization code verification. NI/1 services include INWATS, calling card verification and Virtual Private Networks (VPNs).


Figure 11.12  Intelligent Network (IN) supporting 800 services and calling card verification.

The linchpin of the intelligent network is the Service Creation Element (SCE), which is a set of modular programming tools allowing services to be developed independently of the switch, the nature and capability of which can vary by manufacturer. The SCE divorces the service-specific programmed logic from the switch logic, allowing the independent development of the service—the service is available to all switches in the network. The concept of a sparse network is one of dumb switches supported by centralized intelligence. This concept is highly viable in terms of both performance and economics.

The IN/1 approach was lacking in that it still required substantial programming work at both the SCE and the switch level. Bellcore research led the development of IN/2, which required substantial investment in the end offices. IN/2 was dropped in favor of IN/1+, the current version of AIN [11-53].

AIN Defined

AIN was defined by Bellcore in the early 1980s as AIN Software Release 1.0. This release is intended to provide a generic and modular set of tools that allow the creation, deployment and management of services on a flexible basis. The software tools yield a suite of service offerings which are accessible to all network switches, but which operate independently from the switch logic. The services, therefore, can be defined, developed and deployed quickly, and in a multivendor environment.

The depth and complexity of AIN Software Release 1 caused the telephone companies to move forward with their own various AIN releases, known as Releases 0.X. All Releases 0.X are fully compatible with Bellcore’s Release 1.0, which may never be implemented in its original and defined form. AIN Release 0.0 addresses basic call modeling functions for Service Switching Points (SSPs) and database functions for Service Control Points (SCPs). AIN Release 0.1 defines generic call model for interaction between SSPs and SCPs; it includes features in support of N-ISDN services. AIN Release 0.2 adds Intelligent Peripherals (IPs). [11-53].

Characteristics of AINs include service creation toolkits, that allow the creation of centralized logic residing in centralized databases for the development and delivery of features across the network. AINs support all ISDN Features, including Caller ID, Selective Call Blocking, and Distinctive Ringing. Finally, AINs are intended to provide support for Personal Communications Services (PCS), which allow subscribed features to be supported across networks of all types; PCS is conceptual at this time.

Service Creation Environment (SCE)

The Service Creation Environment (SCE) is the key distinction of an AIN. The SCE offers the carrier a toolkit for the development of service offerings that can be provided on a network basis. The services can be generic or customer-specific. The customer-specific services often can be created through the linking of generic services and the varying of the available options and parameters. Additionally, the SCE can be opened to the user organization, which can then customize the service offering as desired.


Previous Table of Contents Next