Intelligent network
The Intelligent Network, typically stated as its
acronym IN, is a
network architecture intended both for fixed as well as
mobile telecom networks. It allows operators to differentiate themselves by providing value-added services in addition to the standard telecom services such as
PSTN,
ISDN and
GSM services on
mobile phones.
In IN, the intelligence is provided by network nodes owned by telecom operators, as opposed to solutions based on intelligence in the telephone equipment, or in Internet servers provided by any part.
IN is based on the
Signaling System #7 (SS7) protocol between telephone network switching centers and other network nodes owned by network operators.
Examples of IN services
Examples of such services are:
TelevotingCall screeningTelephone number portabilityToll free callsPrepaid callingAccount card calling
Virtual private networksCentrex service (Virtual
PBX)
Private-number plans (with numbers remaining unpublished in directories)
Universal
Personal Telecommunication service (a universal personal telephone number)
Mass-calling service
Prefix free dialing from cellphones abroad
Seamless
MMS message access from abroad.
Reverse charging
Home Area Discount
Freephone
Premium Rate calls
Location Based Routing
[
edit] History and key concepts
The IN concepts, architecture and protocols were originally developed as standards by the
ITU-T which is the
standardization committee of the
International Telecommunication Union. The primary aim of the IN was to enhance the core telephony services offered by traditional telecommunications networks, which usually amounted to making and receiving voice calls, sometimes with call divert. This core would then provide a basis upon which
operators could build services in addition to those already present on a standard
telephone exchange. Examples of the kind of
custom services.
A complete description of the IN emerged in a set of
ITU-T standards named Q.1210 to Q.1219, or Capability Set One (CS-1) as they became known. The standards defined a complete architecture including the architectural view, state machines, physical implementation and protocols. They were universally embraced by telecom suppliers and operators, although many variants were derived for use in different parts of the world (see
Variants below).
Following the success of CS-1, further enhancements followed in the form of CS-2. Although the standards were completed, they were not as widely implemented as CS-1, partly because of the increasing power of the variants, but also partly because they addressed issues which pushed traditional
telephone exchanges to their limits.
The primus motor behind the development of the IN system was the need for a more flexible way of adding sophisticated services to the existing network. Before IN was developed, all new feature and/or services that was to be added had to be implemented directly in the core switch systems. This made for very long release cycles as the bug hunting and testing had to be extensive and thorough to prevent the network from failing. With the advent of IN, most of these services (such as toll free numbers and geographical number portability) was moved out of the core switch systems and into self serving nodes (IN), thus creating a modular and more secure network that allowed the services providers themselves to develop variations and value-added services to their network without submitting a request to the core switch manufacturer and wait for the long development process. The initial use of IN technology was for number translation services, e.g. when translating toll free numbers to regular
PSTN numbers. But much more complex services have since been built on IN, such as
Custom Local Area Signaling Services (CLASS) and prepaid telephone calls.
[
edit] SS7 Architecture
The main concepts(functional view) surrounding IN services or architecture are connected with
SS7 architecture:
Service Switching Function (SSF) or Service Switching Point (SSP) This is co-located with the
telephone exchange itself, and acts as the trigger point for further services to be invoked during a call. The SSP implements the Basic Call State Machine (BCSM) which is a
Finite state machine that represents an abstract view of a call from beginning to end (off hook; dialling; answer; no answer; busy; hang up etc). As each state is traversed, the exchange encounters Detection Points (DPs) at which the SSP may invoke a query to the SCP to wait for further instructions on how to proceed. This query is usually called a trigger. Trigger criteria are defined by the operator and might include the subscriber calling number or the dialled number. The SSF is responsible for entertaining calls requiring value added services.
Service Control Function (SCF) or Service Control Point (SCP) This is a separate set of platforms that receive queries from the SSP. The SCP contains service logic which implements the behaviour desired by the operator, i.e., the services. During service logic processing, additional data required to process the call may be obtained from the SDF. The logic on the SCP is created using the SCE.
Service Data Function (SDF) or Service Data Point (SDP) This is a database that contains additional subscriber data, or other data required to process a call. For example, the subscribers prepaid credit which is remaining may be an item stored in the SDF to be queried in real time during the call. The SDF may be a separate platform, or is sometimes co-located with the SCP.
Service Creation Environment (SCE) This is the development environment used to create the services present on the SCP. Although the standards permit any type of environment, it is fairly rare to see low level languages like
C used. Instead, proprietary graphical languages have been used to enable telecom engineers to create services directly. The languages usually belong to
4G languages, the user can use Graphical Interface to manipulate between different functions to formulate a service.
Specialized Resource Function (SRF) or Intelligent Peripheral (IP) This is a node which can connect to both the SSP and the SCP and delivers additional special resources into the call, mostly related to voice data, for example play voice announcements or collect
DTMF tones from the user.
[
edit] Protocols
The core elements described above use standard protocols to communicate with each other. The use of standard protocols allows different manufacturers to concentrate on different parts of the architecture and be confident that they will all work together in any combination.
The interfaces between the SSP and the SCP are
SS7 based and may look familiar to those familiar with
TCP/IP protocols. In fact, the
SS7 protocols implement much of the
OSI seven-layer model. This means that the IN standards only had to define the
application layer which was called the Intelligent Networks Application Part or
INAP. The INAP messages are encoded using
ASN.1.
The interface between the SCP and the SDP is defined in the standards to be an
X.500 Directory Access Protocol or DAP. However, a more lightweight interface called
LDAP has emerged from the
IETF which is considerably simpler to implement, so many SCPs have implemented that instead.
[
edit] Variants
The core CS-1 specifications were adopted and extended by other standards bodies. European flavours were developed by
ETSI, American flavours were developed by
ANSI and Japanese variants also exist. The main reasons for producing variants in each region was to ensure interoperability between equipment manufactured and deployed locally (for example different versions of the underlying
SS7 protocols exist between the regions).
However, new functionality was also added which meant that variants diverged from each other and the main ITU-T standard. The biggest variant was called
Customised Applications for Mobile networks Enhanced Logic, or CAMEL for short. This allowed for extensions to be made for the
mobile phone environment, and allowed
mobile phone operators to offer the same IN services to subscribers while they are
roaming as they receive in the home network.
CAMEL has become a major standard in its own right and is currently maintained by
3GPP. The last major release of the standard was CAMEL phase 4. It is the only IN standard currently being actively worked on.
The Advanced Intelligent Network (AIN) is the variant of Intelligent Network developed for North America by Bellcore (now
Telcordia). The standardization of the AIN was performed by Bellcore on behalf of the major US operators. The original goal of AIN was AIN 1.0 which was specified in the early 1990s (AIN Release 1, Bellcore SR-NWT-002247, 1993). AIN 1.0 proved technically infeasabile to implement, which lead to the definition of simplified AIN 0.1 and AIN 0.2 specifications. In North America the SR-3511 (originally known as 1129+) and GR-1129-CORE protocols are used to link switches with the IN systems such as
Service Control Points (SCPs) or Service Nodes. SR-3511 is a TCP/IP based protocol which directly connects the SCP and Service Node. GR-1129-CORE is an ISDN based protocol which connects the SCP to the Service Node via the SSP.
[
edit] Future
While active development in IN standardization has declined in recent years, there are many systems deployed across the world which use this technology. The architecture has proved to be not only stable, but also a continuing source of revenue with new services added all the time. Manufacturers continue to support the equipment and obsolescence is not an issue.
Nevertheless, new technologies and architectures are emerging, especially in the area of
VoIP and
SIP. More attention is being paid to the use of
APIs in preference to protocols like INAP and new standards have emerged in the form of
JAIN and
Parlay. From a technical view, the SCE is beginning to move away from its proprietary graphical origins and is moving towards a
Java application server environment.
