PDF of this tutorialWithin traditional public switched telephone networks, the hierarchy of switching equipment and software must be upgraded each time a new service is added to the network. This is a complex and costly process. Further, network switches could not provide new number translation, routing, and charging capabilities. As telecommunications services have evolved, the need to reduce the overhead for service use has increased along with the need to simplify maintenance and service upgrades or additions.
The IN essentially separates these services from switching equipment and organizes a centralized system so that providers need not perform major modifications on multiple switches when they introduce new services. The first step in IN development was to create separate service data in a centralized database outside the switching nodes. The second step was to separate the service programs, or service logic, and to define a protocol that would permit interaction between switching systems and intelligent nodes containing the service logic and data.
For service switching points and service control points (intelligent nodes) to work, common channel signaling, or out-of-band signaling, was required as opposed to the traditional inband signaling. Relying on out-of-band signaling, or signaling system 7 (SS7) protocols, provides the mechanism to place service logic and service data into dedicated network elements that can remotely handle call control and connection. SS7 also enables intelligent applications to communicate with other applications and to access databases located in various parts of the network.
Certain network elements can be distinguished in every IN, as shown in Figure 1.
Figure 1. IN Functions and Functional Relationships for CS–1 (from Q.1211)
Service switching points (SSPs) are stored program control switches that interface to the SS7 signaling network. The SSP embodies the call control function (CCF) and service switching function (SSF) entities. The SSF recognizes IN service calls and routes the appropriate queries to the service control function (SCF) that resides in a service control point (SCP) via the SS7 network through signaling transfer points (STPs). STPs are high-capacity, high-reliability packet switches that transport signaling messages, using large routing databases, between the IN nodes.
SCP commands are used by the SSP to process calls. The SCP is a fault-tolerant, high-capacity, transaction-processing entity that provides call-handling information in response to SSP queries. The service management point (SMP) provides operation, administration, and maintenance functions for the IN. The intelligent peripheral (IP) provides enhanced services or functions under the control of an SCP, possibly relayed by an SSP, such as play announcements and speech recognition.
As seen in Figure 2, the IN architecture is fundamentally based on SS7 and its protocol architecture. A common signaling transport capability known as the message transfer part (MTP) handles the corresponding open systems interconnection (OSI) physical, data-link, and network layers. The next level, signaling connection control part (SCCP), augments the MTP by providing both connectionless and connection-oriented message transport, as well as enabling addressing capabilities for message routing. The transaction capabilities application part (TCAP) provides procedures for real-time transaction control. The final layer, IN application protocol (INAP) defines the operations required between IN network elements, such as SSPs and SCPs.
Figure 2. IN Protocol Stack
All of these basic elements form the infrastructure in IN, which supports the notion of separating service-control functions from service switching-functions, to realize more rapid-services development and deployment. Another equally important concept in IN has been the notion of service independence. Here, the primary goal has been to identify and create generic sets of reusable service components that could be used to build new services and loaded into SCPs to generate new services rapidly. These service components are also known as service independent building blocks (SIBs).
To provide a framework that would lead toward IN engineering standardization, the IN conceptual model (INCM) was developed (Figure 3). The INCM, which is solely a tool for describing IN capabilities and characteristics, is composed of four "planes" that represent different aspects of implementing IN services. This model depicts the relationship among services and service features, global service logic (SIBs), distributed service logic, and the physical network entities such as SCP and SSP. These planes include the service plane, the global functional plane, the distributed functional plane, and the physical plane as shown in Figure 3.
Figure 3. IN Conceptual Model—INCM (from Q.1201)
The service plane describes services from a user's perspective, where a service consists of generic blocks or service features that make up part or all of a service (e.g., Freephone). The global functional plane deals with service creation and is comprised of the SIBs that will be used to create service features. Global service logic defines how SIBs are linked together to form features and how these SIBs interact with another basic SIB known as the basic call process (BCP). The BCP is the process that optimally supports services that do not require special features and is basic to the processing of all services. The distributed functional plane defines a set of functional entities that perform specific actions. SIBs are implemented through a specific sequence of functional-entity actions performed by those functional entities. Table 1 describes functional-entity components as well as their relationship to IN physical entities.
| Physical Component | Distributed Functional Component | Description |
| Service Switching Point (SSP) | Call Control Function (CCF) | Controls call processing and provides network connection services |
| Service Switching Function (SSF) | Supports IN triggering during call processing and access to IN functionality | |
| Specialized Resource Function (SRF) | Supports the interaction between the call processing software on the switch and the service control function | |
| Call Control Agent Function (CCAF) | Supports specialized network resources generally associated with caller interaction; provides user access to the network | |
| Service Control Function (SCF) | Executes IN service logic and influences call processing on the switch via its interface to the SSF | |
| Service Data Function (SDF) | Manages customer and network data for real-time access by the SCF in the execution of an IN service | |
| Intelligent Peripheral (IP) | Specialized Resource Function (SRF) | Supports specialized network resources generally associated with caller interaction |
| Service Management Point (SMP) | Service Management Function (SMF) | Allows deployment and provision of IN services and allows the support of ongoing operation |
| Service Management Access Function (SMAF) | Provides an interface between service managers and the SMF (could be implemented in a separate physical element, the SMAP) | |
| Service Creation Environment Point (SCEP) | Service Creation Environment Function (SCEF) | Allows services provided in the IN to be defined, developed, tested, and input to the SMF |
| Service Data Point (SDP) | Service Data Function (SDF) | Manages customer and network data for real-time access by the SCF in the execution of an IN service |
Table 1. IN Physical and Functional Entities
As Table 1 also shows, each functional entity is mapped to a particular physical entity within the network. This is depicted in Figure 4. The information flows defined in the distributed functional plane are implemented in the physical plane through the appropriate INAP.
Figure 4. Mapping of Functional and Physical Elements
