3
Intelligent Networks
3.1 INTRODUCTION
The Intelligent Network (IN) standards are divided into the Telcordia
standardisation called Advanced Intelligent Networks (AIN) and the
International Telecommunications Union telecommunications (ITU-T)
IN standards capability sets. The Telcordia standards are used mainly
in North America, whilst the ITU-T standards are relevant in pretty
much the rest of the world. Other work has taken place notably by a
group known as TINA-C, the Telecommunications Information Network-
ing Architecture Consortium, looking at the longer term architectures for
distributed intelligence in telecommunications networks.
The early implementations of IN were based on a database performing
number translation of non-geographic numbers such as the US 800
services, and these basic services continue today. These services were
built on a network enabled by signalling system number 7 (SS#7) and
IN continues to build on SS#7. More recently IN implementations cover
a more extensive set of services from time of day routing plans, find-me
follow-me services, pre-paid mobile services (wireless intelligent
networks), calling card services, to advanced network-based call centre
agent skill routing.
The basic aim of IN is to decouple the service logic from the control of
the switch fabric, a stage further than could be achieved by the use of a
stored program controller, and to create a platform that allows new
services to be constructed from smaller building blocks. This later capabil-
ity is expressed in Q.1201 as ‘‘integrated service creation and implemen-
tation by means of the modularised reusable network functions’’. The
principle business aim of IN is the removal of a dependency on switch
manufacturers for the provision of new services. In order to achieve this
Next Generation Network Services
Neill Wilkinson
Copyright q 2002 John Wiley & Sons, Ltd
ISBNs: 0-471-48667-1 (Hardback); 0-470-84603-8 (Electronic)
aim, the use of an SS#7 infrastructure is a prerequisite. Section 1.2
discusses the protocol stack of SS#7 and mentions the IN protocol – Intel-
ligent Network Application Part (INAP). It is INAP that facilitates the
decoupling of service logic from switching functions.
The development of IN service capabilities within the European Tele-
communications Standards Institute (ETSI) is specified in releases called
Capability Sets (CS), the first (obviously) being CS1. The ETSI work repre-
sents a clarification of the ITU-T standards and tries to add real-world
experience to the theoretical standardisation effort. Each capability also
creates a new release of the Intelligent Network Application Protocol
(INAP) to support the remote invocation of services in an intelligent
network, by providing the mapping from functional to physical entities
(see later in this chapter). Further work has taken the IN standardisation
to CS4, however, the actual number of implementations of anything other
than CS1 are low
1
. In Europe a number of IN implementations are based
on what has become known as ETSI core INAP – CS1, specified in ETS 300
374-1.
The time for IN is arguably gone, with new computing platforms and
open standards for service execution environments just around the corner
(see Chapter 10). The author also believes the telecommunications indus-
try has become restless and disappointed with IN implementations and
standards progress. The new software-based platforms called soft-
switches (see Section 10.3) being developed and session initiation protocol
(SIP) servers (see Section 5.6) will replace the IN infrastructure; Ovum
predicts this will happen by as early as 2003.
This sounds like a bleak future for IN, so why cover intelligent network
technology here? The truth is that a lot of network operators have imple-
mented IN successfully (and at considerable sunk cost), and are now
sitting on a cash cow that will continue to deliver revenue beyond 2003.
This revenue will be ploughed back into the development of new services
in one of two ways, either to continue the evolution of their incumbent IN
platforms to bridge circuit switched and packet switch worlds (in Chapter
10.4 the future of IN services is discussed and the work of a group in the
Internet Engineering Task Force that looks to provide the ability for IN to
interact with Internet-based services and vice versa), or to purchase soft-
switches and SIP proxy servers (see Chapter 5). Also the concepts for a
distributed service network that are introduced in the IN standardisation
are extremely useful in understanding the way new services in a call
server architecture might be developed and delivered (we’ll explore
this further in the next section on services and explore how IN as it is
INTELLIGENT NETWORKS34
1
It could be argued that CS3 implementations exist, because CS3 brings IN inline with the
next generation of mobile networks under the standardisation for the Unified Mobile
Telecommunications System standardisation (UMTS) activity and describes some of the
IN services for mobile use.
now could evolve to have a place in the next-generation networks, see
Section 10.4).
3.2 FUNCTIONAL COMPONENTS
The IN is decomposed into a number of layers, each of these layers are
called planes, which form the IN conceptual model – INCM (ITU-T,
Q.1201). This conceptual model is a framework for the construction of
an IN architecture, not the architecture itself, an important distinction.
The four planes are: service plane (Q.1202), global function plane
(Q.1203), distributed function (Q.1204) plane and physical plane
(Q.1205) (Figure 3.1).
I’ll only examine the planes at a high level. If you would like to explore
IN further than is presented here, I suggest [FAYN] as a good place to
start, followed by [IAKO] for how IN-based broadband networks have
been specified (the suspicion of the author is that the broadband IN stan-
dardisation effort will/has been overtaken by the adoption of application
frameworks and protocols such as media gateway control protocol
(MGCP) and SIP
2
).
The service plane is where the services reside. The global function plane
describes a model network of functionality from a global or network-wide
perspective. The distributed function plane describes, in a supplier inde-
pendent way, the functions of the components that constitute an IN. The
physical plane is where real network hardware resides and it embodies
the functions described in the distributed function plane, and arguably is
the easiest plane to understand.
The service plane recommendation (Q.1202) is a short document, four
pages to be exact. It describes how a service can be categorised and
describes the undesirable feature of service interaction. This is where
the capabilities provided by one service if used in conjunction with
another service produces an undesirable result. For example call waiting,
a service designed to inform a caller that the person they’re trying to reach
is already engaged in a call, whilst also informing the person already on a
call that someone else is trying to reach them. This service generally
allows the called party to toggle between their existing call and the new
caller to establish alternating conversations between the two. Addition-
ally the service also offers the ability to connect all three parties together
for a conference call. Clearly this service requires the called party to be
able to control the calls they have both in progress and trying to reach
them, it would be incompatible to try to implement this call waiting
service at the same time as implementing a call diversion on busy service,
3.2 Functional components
2
See Chapters 12 and 5 respectively for an explanation of application frameworks, MGCP
and SIP.
35
since call diversion on busy would try to divert the second caller away
before any conversation could take place. Clearly, these two services can’t
coexist.
The global function plane describes the proper location for the modu-
larity aspects of services construction. The concept of a Service Indepen-
dent Building Block (SIB) is introduced. It describes Points of Initiation
(POI), Points of Return (POR) and Basic Call Processing. The relationship
of these to each other (in the form of the Global Service Logic (GSL)) is
shown in Figure 3.2.
SIBs are standard (i.e. specified in the standards for each capability set)
reusable functional components that services can be constructed from.
Each SIB describes a single complete atomic capability that is independent
of any physical component of the network. A service is created by effec-
tively chaining SIBs together, these chains of SIBs create what is referred
to as the GSL. The Basic Call Process (BCP) is in essence a special SIB that
allows the passing of call related data from the other network elements,
and in this way provides both a mechanism for handing over control of a
call to the IN service and provides basic call processing functionality to
the service logic. The BCP SIB defines entry and exit points to the call
processing so that other SIBs can be invoked. These interaction points are
INTELLIGENT NETWORKS36
Figure 3.1 IN conceptual model
the POI, where call processing is handed over to the service (specifically
the GSL), and POR where the results of the service execution hands back
control to the call processing software.
The Distributed Function Plane (DFP) describes the functional
elements/entities of:
† Service Management Function (SMF), the provisioning, billing and
fault monitoring functions.
† Service Management Access Function (SMAF), interface between
administrators and the SMF.
† Service Creation Environment Function (SCEF), the offline function
for the creation of service logic from the SIBs.
† Service Control Function (SCF) controls the execution of services and
contains a function known as the Service Logic Execution Environ-
ment (SLEE), where the combined SIBs in the form of Service Logic
Programs (SLPs) execute.
† Call Control Function (CCF), basic call connection and release, essen-
tially the inheritance from the stored program controller basic call
control capability.
† Service Switching Function (SSF), the interface between the CCF and
SCF manages the triggers in the CCF for interaction with the IN
service. INAP is the protocol used to connect the SSF and SCF. This
is in essence an instance of the special BCP SIB described above.
† Special Resource Function (SRF), provides such things as digit recog-
nisers, recorded announcements and voice recognition capabilities for
the interaction between callers and service logic.
† Call Control Agent Function (CCAF), essentially the signalling
between the user and the network for example Integrated Services
Digital Network (ISDN) Q.931.
3.2 Functional components
Figure 3.2 Relationship of SIBs, POI and POR to BCP
37
The physical plane is populated with: Service Control Points (SCP, the
physical embodiment of the SCF), Service Creation Environment (SCE,
the physical embodiment of the SCEF), Service Switch Points (SSP, the
physical embodiment of the SSF), Signalling Transfer Point (STP), Specia-
lised Resource Platforms (SRP, also called Intelligent Peripherals (IPs), the
physical embodiment of the SRF) and finally the Service Management
Platform (SMP, the physical embodiment of the SMF and in some
instances the SMAF too). Their relationship is shown in Figure 3.3.
The SSP is the stored program controller that we discussed earlier, in
the case of IN the code for the call model (called the Basic Call State Model
(BCSM), essentially the CCF) finite state machine has been modified (with
the SSF) to include break points that allow the call routing to be paused for
originating calls and terminating calls called the o_BCSM and t_BCSM.
The break points in the SPC BCSM are called Detection Points (DPs). Each
one of these triggers is separately settable either by a maintenance action
or via a message from the SCP logic, to allow the call progress to be
interrupted as various stages in the call processing (called Points In Call
(PIC)). The PIC essentially map on to the POI and POR described in the
BCP SIB defined in the global function plane.
The CS1 specifications do not allow for interaction between the origi-
nating and terminating call models and describes what are called type A
services, i.e. single point of control (only one SCF can interact with the
INTELLIGENT NETWORKS38
Figure 3.3 IN physical architecture
BCSM at a time) and single ended (SCF can only interact with an isolated
half of a call, originating or terminating, but not both).
The STPs are responsible for routing SS#7 messages and whilst are
present in the IN architecture, are actually part of the SS#7 architecture
as discussed in Chapter 1. STPs were discussed in relation to a feature
known as Global Title Translation (GTT). With reference to Figure 3.3, we
will explain the importance of GTT. If the service code, say 0800 is used as
a Global Title (GT) (i.e. the reference used to find an instance of a service
that can be invoked) then the STP in the IN architecture can choose to
route the INAP messages via Signalling Connection Control Part (SCCP)
GTT to either of the SCPs in the diagram. This means that load sharing can
take place and also if an SCP fails, then the failure would be transparent to
the switch.
That’s a whistle-stop tour of IN that hopefully gives a flavour of the
work and thought that has gone into defining the way services can be
created in a manufacturer independent way. The IN Conceptual Model
(INCM) and the work of the TINA-C group (not described here) have
gone a long way in assisting in the thinking process for Next-Generation
Network (NGN) services and in some networks the current IN infrastruc-
ture may actually evolve to be the NGN service function or call agent
capability (see Section 5.6 for a description of a call agent). In Part 2,
Chapter 11, the IN’s integration with call centres will be explored as a
current service that can be improved upon by the use of NGN services.
3.2 Functional components 39