Intelligent network

From Wikipedia, the free encyclopedia

Jump to: navigation, search

This article includes a list of references or external links, but its sources remain unclear because it
has insufficient inline citations. Please help to improve this article by introducing more precise
citations where appropriate. (April 2009)
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 on the service layer, distinct from the switching layer of the
core network, as opposed to solutions based on intelligence in the core switches or telephone equipments.
IN is based on the Signaling System #7 (SS7) protocol between telephone network switching centers and other
network nodes owned by network operators.

Contents
[hide]

1 Examples of IN services
2 History and key concepts

3 SS7 Architecture

4 Protocols

5 Variants

6 Future

7 See also

8 References

9 External links

10 Notes

[edit] Examples of IN services

Examples of such services are:

Televoting
Call screening

Telephone number portability

Toll free calls / Freephone

Prepaid calling

Account card calling

Virtual private networks (eg : Family group calling)

Centrex 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

Premium Rate calls

Call distribution based on various criteria associated with the call

o

Location Based Routing

Time based routing

Proportional call distribution (eg between two or more call centres or offices).

Call Queueing

Call transfer

[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, prior to this a number of
telecommunications providers had proprietary IN solutions[1]. 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.
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 major driver 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
were 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) were
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.

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, dialing, 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.

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.

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 (now Telcordia
Technologies) 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 infeasible to
implement, which lead to the definition of simplified AIN 0.1 and AIN 0.2 specifications. In North America,
Telcordia Special Report SR-3511 (originally known as 1129+) and Telcordia Generic Requirements document
GR-1129-CORE protocols are used to link switches with the IN systems such as Service Control Points (SCPs)
or Service Nodes. Telcordia SR-3511 details a TCP/IP-based protocol which directly connects the SCP and
Service Node. Telcordia GR-1129-CORE provides generic requirements for an ISDN based protocol which
connects the SCP to the Service Node via the SSP.

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.

See also

Intelligent computer network

IP Multimedia Subsystem

Service layer

Value-added service

References

Ambrosch, W.D., Maher, A., Sasscer, B. (editors) The Intelligent Network: A Joint Study by Bell
Atlantic. IBM and Siemens, Springer-Verlag, 1989. ISBN 3-540-50897-X. ISBN 0-387-50897-X. Also
known as the green book due to the cover .
Faynberg, I., Gabuzda, L.R., Kaplan, M.P., and Shah, N.J. The Intelligent Network Standards: Their
Application to Services, McGraw-Hill, 1997, ISBN 0-07-021422-0.

Magedanz, T., and Popescu-Zeletin, R.. Intelligent Networks: Basic Technology, Standards and
Evolution, Thompson Computer Press, 1996. ISBN 1-85032-293-7.

Intelligent Networks By John R. Anderson, Institution of Electrical Engineers,2002. ISBN 0852969775,

ISDN Architecture

Overview

This section describes the modules that form the ISDN PRI software architecture. These modules are:

Layer 3 Plus

Layer 3

Layer 2

Configuration

Management

Diagram

ISDN PRI Software Architecture illustrates the functional modules involved in the PRI implementation
on an ISDN card.

Figure 8-5 ISDN PRI Software Architecture

Layer 3 Plus

The Layer 3 Plus (L3P) module is an interface between Layer 3 and Layer 4 Central Call Processing
(CCP) on the Matrix Controller, and Layer 5 (host). L3P formats information from Layer 3 into the
programmed format for the host. It also manages application specific variants for call control. It is made
up of the following PPL components:

L3P Call Control [Component (0x05), per D channel]

This component is the interface between Layer 3 and Layer 4 central call processing, which resides
on the Matrix Controller. This component manages which messages to send internally for call
processing as well as notifying the host of various events related to the protocol.

L3P D Channel Control [Component (0x06), per D channel]

This component manages the enabling/disabling of the D channel per terminal (for PRI ISDN there is
only one terminal). It manages the sending of the Alarm message when the D channel is establishing a
connection, and informs the L3P B channel control component of the availability of D channel.

L3P B Channel Control [Component (0x07), per B channel)

This component manages the service state of the channel based upon the following:

Host service states

Layer 1 states (span framed or not)

D channel availability

B channel availability from the network

Layer 3

The Layer 3 (L3) module provides ITU-T Q.931 implementation. The L3 state diagrams mirror the SDL
diagrams of the interface specifications. It consists of the following PPL components:

L3 Call Control [Component (0x08) per D channel]

This component implements Q.931 variants, which has state tables that are SDL equivalents with
some validation logic embedded. This component is managed per call reference, and manages B
channel bearer capability as well as B channel allocations.

L3 Global Call Control [Component (0x09) per D channel]

This component manages the protocol for the restarting logic. It implicates active calls per a channel
RESTART message, ACKs them, and then arbitrates sequencing with the B channel control
components.

L3 D Channel Control [Component (0x0A) per D channel]

This component manges the D channel availability as defined by the Data Link Connection state
diagram in ITU-T Q.931. It communicates with the L3P DSM upon D channel failure.

L3 B Channel Control [Component (0x0B) per B channel]

There is one state machine per B channel to manage the SERVICE messages for the protocol using
the protocol discriminator (0x03). This state machine manages availability for the B channels as well as
in-use status.

Layer 2

The Layer 2 (L2) module is the ITU-T Q.921 (LAPD) implementation. It performs flow control, sequence
numbering (module 128), retry logic, and it also guarantees message delivery.

Configuration

The Configuration (CFG) module manages all configuration of parameters and options for the ISDN
protocol. This task communicates with the Matrix Controller during configuration. It also verifies battery
backed data and card level configuration.

Management

The Management (MGMT) module performs terminal endpoint identifier (TEI) management logic for
Basic Rate Interface (BRI) access and it synchronizes Layers 2 and 3 correctly. It also acts as an alarm
manager for the L2 protocol.