Intelligent Network Article Index for
Intelligent 		Shopping
Intelligent 		Website Links For
Intelligent Network 		 

Information About

Intelligent Network
  CATEGORIES ABOUT INTELLIGENT NETWORK
   
itu-t recommendations
   
gsm standard
   
signaling system 7
   
network architecture
   
APPAREL
BABY
BEAUTY
BOOKS
CAR TOYS
CELL PHONES
DVD'S
ELECTRONICS
GOURMET FOOD
GROCERIES
HEALTH & PERSONAL
HOME & GARDEN
JEWELRY
MUSIC
MUSIC INSTRUMENTS
OFFICE PRODUCTS
SOFTWARE
SPORTING GOODS
TOOLS & HARDWARE
TOYS
VIDEO GAMES
SHOPPING HOME
MORE SHOPPING...




OVERVIEW


The IN concepts, architecture and protocols were developed originally as standards by the ITU-T which is the Standardization committee of the International Telecommunication Union . The 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 would then provide a way for Operators to build services in addition to those already present on a standard Telephone Exchange . Examples of the kind of Custom Services which could be offered are:


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.


KEY CONCEPTS


The main concepts surrounding IN services or architecture are:

  • 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.


  • 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. 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.


  • 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, 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 unfamiliar 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 environment, and allowed Mobile Phone Operator s to offer the same IN services to subscribers whilst 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.


FUTURE


Whilst 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 it is difficult to predict an obscelence window.

Nevertheless, new technologies and architectures are emerging, especially in the area of VOIP and SIP . More attention is being paid to the use of API s 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.