Contents Intelligent networks - Instytut …mareks/ute/in-zuidweg.pdfIntelligent networks As the majority of switches became digital in the 1980s, vendors and operators saw that, like

Intelligent networks

As the majority of switches became digital in

the 1980s, vendors and operators saw that,

like computers, they could be programmed,

making it possible to introduce intelligent

services, such as call forwarding, call block-

ing, freephone, and premium rate numbers,

into the network.

At first, these services were programmed

in assembler-like languages, and had to be

installed manually in each switch. Installing

a new service meant reprogramming the

switch and manually resolving the interac-

tions with the service programs already run-

ning on it. The process of defining the

service, specifying, implementing, testing,

and finally deploying it would typically take

between 2 and 4 years. The management of

these services was obviously inefficient, as

even the smallest patch required going to

each switch in turn and reinstalling the

new software. It was soon recognized that it

would be much more convenient if services

could be designed in more high-level lan-

guage, and could be deployed and managed

from one point rather than separately in

each switch.

23

Contents

2.1 SS7

2.2 IN standards

2.3 Service plane

2.4 Global functionalplane

2.5 Distributedfunctional plane

2.6 Physical plane

2.7 CS-2

2.8 CS-3 and CS-4

2.9 Implementing IN

2C H A P T E R

The introduction of SS7 in the early 1980s was a leap forward. SS7 is

a metanetwork for signaling. It provides reliable signaling links that are

independent of the bearer connections. The SS7 protocols1

have a high

degree of flexibility for supporting new features and are still state of the

art today, more than 20 years after AT&T introduced the concept.

After the breakup of AT&T, it was Telcordia (formerly Bellcore) that

first proposed the advanced intelligent networks (AIN) concept using the

protocols of SS7. The purpose of AIN was to allow the regional Bell oper-

ating companies (the Baby Bells) to simplify the deployment and man-

agement of value-added services in the network by centralizing their

control.

Based on the success of the Telcordia design, the International Tele-

communication Union (ITU) began the process of standardizing INs in

the late 1980s. After 4 years of standardization efforts, the first IN stan-

dard was published in 1993 as the ITU Q.1200 series. Although numer-

ous improvements and extensions have been made since then, today’s

IN standards and products are still largely based on the first ITU

standards.

2.1 SS7

SS7 is such an important milestone in the development of switched

telephony networks that it would require a whole book to do it justice. In

fact, many books were dedicated entirely to this signaling system, which

today still rules our telephony network.

It is difficult to understand the birth of IN without seeing it in the

context of SS7. In this section we take a bird’s-eye view of SS7 and see

how it led to the invention of IN.

As electronic switches became widespread in the 1970s the need

arose for modernizing the signaling protocols. AT&T defined SS7 in 1975,

using data network technology. SS7 is a metanetwork for out-of-band

signaling, as opposed to in-band signaling systems that use the same

24 Next Generation Intelligent Networks

1. In its most general definition, a protocol is a well-defined set of messages and rules to

make two or more entities communicate. Protocols are used in hardware as well as in

software. Complex systems like computers and telecommunications systems are usually

divided up into several components or layers, each with its own set of protocols. This is

done because it is easier to design, test, and debug a system with simple protocols for

each task than a system consisting of one overarching protocol.

connections for voice and signaling messages. SS7 is designed in such a

way that it guarantees reliable signaling links. In 1980 the ITU started

standardizing SS7, and in 1984 it issued the SS7 standard as the famous

red book. Since then, the ITU maintains and updates the standards regu-

larly.

Unfortunately, there is not one SS7 standard. The ANSI and ITU ver-

sions of SS7 are slightly different, and there are several different versions

of SS7 deployed around the world. There are, however, gateways that

interface between the different protocols.

An SS7 network contains three kinds of elements:

1. Signaling points (SPs): network equipment that can send or receive

signaling messages;

2. Signaling links (SLs): links that carry signaling messages (in SS7 they

are either 56-Kbps or 64-Kbps data connections);

3. Signaling transfer points (STPs): intermediate nodes that route sig-

naling messages from one place to another.

Figure 2.1 shows a typical SS7 configuration for two connected net-

works. STPs are usually configured in pairs to ensure high reliability. The

Intelligent networks 25

SL

SL

SL SL

SL SL

SL

SL

SL

SL

SL

Network 1 Network 2

Bearer connection

STP

STP

SL

SP

SP

SP

SP

STP

STP

SLSL

Figure 2.1 SS7 network elements.

SS7 protocols ensure that when an STP or SL goes down, the messages

are automatically rerouted over links that are still operational.

To ensure secure and flexible signaling connections, the SS7 protocol

architecture is layered. It roughly follows the seven-layer open-systems

interconnection (OSI) model, which was popular when SS7 was defined.

The main idea of the OSI model is to make complex telecommunications

protocols more manageable by dividing them up into layers. Each layer

provides certain services to the layer above it, and uses the services of the

layer below. This results in a modular protocol stack in which each layer

encapsulates a well-defined set of functions.

Figure 2.2 shows the SS7 protocol stack, which is made up of the fol-

lowing protocols:

◗ Message Transfer Part 1 (MTP1) represents the physical layer, consist-

ing of hardware and firmware resources such as network cards,

transceivers, and cables.

◗ Message Transfer Part 2 (MTP2) is responsible for the secure transmis-

sion of messages between two signaling (transfer) points.


Message Transfer Part (MTP) 3



Signaling Connection Control Part (SCCP)

Transaction Capabilities ApplicationPart (TCAP)

Ori

en

tati

on

,A

dm

inis

tra

tio

n,a

nd

Ma

na

ge

me

nt

Pa

rt(O

AM

P)

Mo

bil

eA

pp

lic

ati

on

Pa

rt(M

AP

)

InA

pp

lic

ati

on

Pa

rt(I

NA

P)

ISD

NU

ser

Pa

rt(I

SU

P)

Te

lep

ho

ny

Use

rP

art

(TU

P)

Figure 2.2 SS7 protocols.

◗ Message Transfer Part 3 (MTP3) takes care of routing a message from

one point in the SS7 network to another, passing through intermedi-

ate signaling transfer points.

◗ Telephony User Part (TUP) describes the signaling messages for the

setup of calls and connections in analog telephony networks. This

protocol is used in older telephony networks that still use electrome-

chanical or analog electronic switches.

◗ ISDN User Part (ISUP) describes the signaling messages for the setup

of calls and connections in digital networks. Despite the name, ISUP

is used in all digital telephony networks, not only ISDN.

◗ Signaling Connection Control Part (SCCP) sets up and manages signaling

connections, using MTP3 to route messages reliably from one node

to another. In fact, SCCP supports both connection-oriented and

connectionless signaling contexts. SCCP also carries the information

that STPs need to perform global title translation. This transla-

tion allows global titles (dialed numbers) to be translated into

destination-point codes (network addresses). This is needed for

translating 800 numbers, number portability, and other services in

which the dialed number must be translated to a different destina-

tion address.

◗ Transaction Capabilities Application Part (TCAP) allows signaling nodes

to do transactions. Transactions are groups of actions that must be

performed as one indivisible action. They are typically used for

accessing network databases, for example databases that map 800

numbers to their destination address. A TCAP message contains

two types of information: the transaction portion is for starting and

ending transactions, and maintains the state of the dialog; the com-

ponent portion carries the actual protocol queries and responses.

A TCAP message is a kind of container that can carry the signaling

messages of other protocols in the component portion. Some of the pro-

tocols that have been defined include the following:

◗ Operation, Administration, and Management Part (OAMP). Still only

partly defined, this protocol is intended for verifying network rout-

ing databases and diagnosing link problems.


◗ Mobile Application Part (MAP). The protocol for mobility management

GSM networks, it describes the messages that are exchanged

between a subscriber’s home and visited network when he or she is

roaming. We will discuss MAP in more detail in Chapter 4.

◗ IN Application Part (INAP). This is the protocol defined for IN; we

will discuss it in more detail later in this chapter.

The fact that SS7 provides a secure data network for signaling mes-

sages meant that it was easy to add special processing nodes in the net-

work for call processing. Telcordia called these processing nodes service

control points (SCPs), and this is how IN was born. Figure 2.3 illustrates

how SCPs were added in SS7 networks for special call processing.

The SCP allows an operator to install and manage services like call

forwarding and call blocking more easily than when they had to be pro-

grammed in the switch. Consider the example of call forwarding. When a

call is made, the call setup signaling message is routed first to the SCP.

The SCP looks at the dialed number, and if it is to be forwarded, it substi-

tutes this number with the new destination number. The resulting modi-

fied signaling message is then sent on into the SS7 network to complete

the call.

The introduction of the SCP in SS7 amounted to the first step toward

what would be called IN. The next section discusses how IN was further

developed and standardized.


Bearer connection

SP

SCP

SPSTP

STP

SP

Figure 2.3 Introduction of service control points in SS7 networks.

2.2 IN standards

When Telcordia successfully implemented its AIN architecture in the late

1980s, the idea caught on with the international community and stan-

dardization efforts began in the ITU. The ITU took 4 years to publish the

first IN standard in 1992, and by that time the first products were already

coming onto the market. It comes as no surprise that the early IN imple-

mentations, for example those by Telcordia, Ericsson, and Alcatel, were

still mostly proprietary and only superficially respected the standards.

Today, however, the level of standardization has much improved.

The main philosophy behind the ITU standardization process was to

standardize service capabilities, but not services. This is very important in

understanding the IN architecture. Many people talk about IN services,

but it is important to realize that these in fact do not exist. What does

exist are services that can be implemented with IN, but there is no such

thing as a service standardized by IN. It is a subtle difference, but it

matters.

2.2.1 Standardization bodies

IN is a framework for implementing value-added in telecommunications

networks. It is not a set of services and it is more than an architecture

alone. Today there are several groups involved in the standardization of

IN. The most important group is undoubtedly the ITU Telecommunica-

tion Standardization Sector (ITU-T). In Europe ETSI is contributing to IN

standardization by endorsing the ITU standard and by proposing a

number of extensions such as core-INAP and CAMEL.

Though not a standardizations body, Eurescom did a great deal of

work on IN, both on paper and in prototyping. Eurescom is a cooperative

research and development organization founded in 1991 by Europe’s

leading network operators; it publishes requirements and feedback on

standards as seen from the operator’s viewpoint.

In the United States, IN started as a de facto standard promoted by

Telcordia. Even today’s ITU-T standards for IN resemble those of the

original Telcordia model, but the Telcordia and ITU-T protocols have

been diverging over time. The differences between the American and

international IN standards manifest themselves more on the protocol

level than in concept.

Apart from Telcordia, the T1S1 group of the American National Stan-

dards Institute (ANSI) has contributed to the American standardization of

IN. There are also industrial groups that are not standards bodies, but that


do play a role in promoting IN standards. The most significant of these is

the Value-Added Services Alliance (VASA). Other industry groups that

have relevance to IN are Sun’s JAIN group, Parlay, and the Third Genera-

tion Partnership Program (3GPP). In this book we will discuss the contri-

butions of all of these groups.

2.2.2 Standardization cycles

One of the problems that the ITU had to cope with is the standardization

of a framework that is by nature expanding all the time, in an environ-

ment that is changing all the time. Telephony switches offer more and

more features, with every release and new network. Technologies such

as GSM and the Internet are constantly changing the environment that

IN operates in.

The ITU therefore decided to standardize IN in a continuous process,

and to freeze the standards at regular intervals. These interval specifica-

tions are called capability sets (CSs). As the name suggests, a CS defines a

set of service capabilities out of which services can be created. These sets

are upward compatible; in other words, each new CS adds new features

while the existing ones remain valid.

The first CS, standardized in 1992, was CS-1. As IN was new at the

time and there were few implementations around to validate the con-

cept, it was necessary to polish the definition in 1995, resulting in the

revised CS-1 (CS-1 R). Since then, the ITU has frozen CS-2 in 1997 and

CS-3 in 1999. The most recent version, CS-4, was issued in 2001.

As explained in the previous section, there are some differences

between the U.S. and the international IN standards. The U.S. standards

are also defined in releases, but the timing of these is slightly different

from that of the ITU CSs. All IN CSs are built on the same foundation, the

IN conceptual model. The following section explains this model and how

it structures the IN standards.

2.2.3 IN conceptual model

There are several ways to explain what IN is about. One of the ways to

look at IN is simply as an add-on to the existing switching architecture. If

we look at it this way, then IN is just a collection of dedicated computers

that perform special control functions. Another way of looking at IN is to

consider it as a software architecture that runs services, much like an

operating system runs applications. If we look at it this way, IN is not as

much a set of nodes as it is a software framework.


The ITU standards combine these different views in an elegant IN

conceptual model (INCM). The INCM reconciles the different physical

and logical views of the IN architecture.

The INCM defines four different views of IN: the service plane (SP),

the global functional plane (GFP), the distributed functional plane (DFP),

and the physical plane (PP). At first sight it may seem that these four

planes are like different protocol layers, but they are not. Many people

mistake the INCM for the IN architecture itself. The INCM is however just

a convenient way of looking at IN from different angles.

The INCM is defined in the ITU recommendations2

Q.1200, Q.1201

to Q.1205, Q.1208, and Q.1290, as shown in Table 2.1.

The INCM can be seen as the foundation for IN and provides the

structure for defining each CS. Each CS is described in the same way:

CS-x is described by recommendations Q.12x0, Q.12x1–Q.12x5, Q.12x8,

and Q.12x9, where x = 1, 2, 3, and so on. Table 2.2 shows the numbering

scheme for IN CS-x recommendations.

In the following sections we will take a closer look at the different

planes of the INCM, the foundation of all IN capability sets. After that we

can compare the different capability sets.

2.3 Service plane

The service plane is the top plane of the INCM. It describes services from

the user’s point of view. The service plane describes what features a


Table 2.1

ITU-T Recommendations Defining the INCM

Number Recommendation

Q.1200 General Series IN Recommendations Structure

Q.1201 Principles of the IN Architecture

Q.1202 IN Service Plane Architecture

Q.1203 IN Global Functional Plane Architecture

Q.1204 IN Distributed Functional Plane Architecture

Q.1205 IN Physical Plane Architecture

Q.1208 General Aspects of the IN Application Protocol

Q.1290 Glossary of Terms Used in the Definition of IN

2. ITU refers to its standards as recommendations.

service is composed of, but not how they are implemented in the net-

work. A feature in the service plane can be seen as a reusable unit of

functionality. The freephone service, for example, consists of two

features:

1. One-number feature: routes incoming calls to a single external

number to different telephones;

2. Reverse charging: reverses charging on calls to the freephone

number, so that the owner of the freephone number pays instead

of the caller.

Figure 2.4 illustrates the IN service plane concept.


Featu

reA

Featu

reA

Service 1

Service 2Fe

ature

B

Featu

reC

Figure 2.4 IN service plane.

Table 2.2

Structure of ITU-T Recommendations, Series Q.1200

Number Recommendation

Q.12x0 Structure of IN CS-x

Q.12x1 Introduction to IN CS-x

Q.12x2 IN Service Plane Architecture for CS-x (not for CS-1)

Q.12x3 IN Global Functional Plane Architecture for CS-x

Q.12x4 IN Distributed Functional Plane Architecture for CS-x

Q.12x5 IN Physical Plane Architecture for CS-x

Q.12x8 IN Interface Recommendations for CS-x

Q.12x9 IN User Guide for CS-x

The concept of services being composed of features is essential to IN.

The key philosophy behind IN is that it standardizes reusable service fea-

tures rather than services. The composition of services out of features is

up to the network operator, and is limited only by the imagination.

The main features defined in CS-1 are shown in Table 2.3. In this

chapter we will not discuss each feature in detail, since the idea is only to

understand how the INCM works. Many of the features shown in

Table 2.3 may look familiar, as they are similar to features found in pri-

vate branch exchanges (PBXs).

Of course, in practice the available features determine to a large

extent the kind of services that can be deployed. The features defined for

CS-1 are few and rather simple. They correspond closely to PBX services

and to existing supplementary services, such as call forwarding, that were

programmed directly in the switch before IN was introduced. As IN

evolves, however, the amount of features increases and with them the

possible ways of combining them into new services.

2.4 Global functional plane

Whereas the service plane describes how services are composed from fea-

tures from the user’s viewpoint, the GFP looks at services from the


Table 2.3

Features Defined in the CS-1 Service Plane

Feature Group Features

Numbering Abbreviated dialing, one number, personal number,

private numbering plan

Routing Call forwarding, follow-me diversion, time-dependent routing,

origin-dependent routing, call distribution

Charging Premium rate, reverse, split

Access Authentication, authorization code, off-net access

Restriction Call limiter, call gapping, closed user group, originating call

screening, terminating call screening

Customization Customer profile management, customer recorded announcement,

customized ringing

User interaction Originating user prompting, destination user prompting, attendant,

consultation calling

Other features Call waiting, automatic call-back, call hold with announcement, call

logging, call queuing, call transfer, mass calling, meet-me conference

service provider’s viewpoint. The GFP describes the software components

that a service provider must deploy in order to assemble services. These

components are called SIBs. Depending on what you grew up with, the

easiest way to envision SIBs is as LEGO, Meccano, or Tinkertoy parts out

of which you can build structures by simply clicking one part onto

another.

A feature defined in the SP is implemented by one or more SIBs in

the GFP. Figure 2.5 illustrates this relationship between the SP and the

GFP.

2.4.1 SIBs

SIBs are software components that can be composed into service scripts.

Each SIB has one logical starting point and several logical ends. The logi-

cal start and ends are where the SIB is connected into the control flow.

Multiple logical ends allow each SIB to be used as a decision point in the

service script.

The SIB acts on call-instance data (CID). This is the call-dependent

data, and includes the originator’s address, the dialed number, and the

destination routing address. Furthermore, the SIB may need service


Featu

reA Fe

ature

B

Featu

reC Fe

ature

AService 1

Service 2

BCPChargeSIB Queue

SIB

ScreenSIB

TranslateSIB

Service plane

Global functional plane

Figure 2.5 Mapping from service plane to global functional plane.

support data, which is independent of the call. Examples of SSD are a

call-screening list (black list), a call-forwarding table, or a charging

scheme. Figure 2.6 shows the structure of a SIB with its parameters.

The global functional plane for IN CS-1 describes a total of 14 SIBs,

which are summarized in Table 2.4 (in alphabetical order).

As this table shows, the functionality of SIBs is elementary, although

the granularity varies somewhat between SIBs. For example, the user

interaction SIB is more complex than the screen or algorithm SIB.

The IN standard describes for each SIB exactly what the logical start,

the logical ends, the SSD, and CID are. Figure 2.7 shows a simplified dia-

gram of the parameters for the screen SIB. This SIB can take the dialed

number as CID input parameter, and uses a screening list (typically a

black list or white list of telephone numbers) as SSD against which to

check the number. Depending on the outcome of this check, the screen

SIB returns either at the in-list or the not-in-list logical end.

The screen SIB is typically used to implement services such as

originating-call screening (OCS) and terminating-call screening (TCS). In

the case of OCS, the dialed number is screened at the originating end of

the call (as in the screen SIB of Figure 2.7). This service is mostly

intended for limiting international calls or calls to premium rate numbers

from certain telephones.

In the case of TCS, the identity of the calling line is screened at the

receiving end of the call. This service is typically used to block unwanted

incoming calls, for example malicious calls or calls from telemarketers.

Of course, Figure 2.7 is a simplified diagram; in reality the parame-

ters are more complex. The logical ends usually also include an error


Service independentbuilding block (SIB)

Logical start Logical ends

Service support data (SSD)

Call instance data (CID)

Input Output

Figure 2.6 A SIB.

clause for cases in which there is a syntactical error in one of the inputs.

Figure 2.7 does not show such details. The important thing for now is to

understand the mechanism whereby the SIBs are defined.

2.4.2 Basic call process

Among the SIBs there is one special building block that represents the call

itself. This SIB is called the basic call process (BCP). The BCP describes the


Table 2.4

SIBs Defined in the CS-1 Global Functional Plane

SIB Description

Algorithm Applies an algorithm to the CID or SSD (the algorithm to

be applied is specified as a parameter of the SIB)

Authenticate Verifies a user’s privilege to place and receive calls and to

access particular service logic and data

Charge Initiates special charging treatment, that is, any charging

different from the standard charging of a call by the SSP;

special charging treatment to be applied is a parameter of

the SIB

Compare Performs a comparison of the input parameter against a

specified reference value

Distribution Distributes the treatment of calls on the basis of specified

parameters

Log call

information

Writes detailed call information into a file; information is

intended for off-line use, not within the context of the call

Queue Queues calls for completion to a specific network address

Screen Compares the input parameter against a list of data

Service data

management

Enables the retrieval, storage, deletion and modification of

service data in the database

Service filter Accepts or rejects calls according to specified parameters;

SIB initially called LIMIT in the 1992 version of IN CS-1

because it was mostly used for call limiting (to prevent

network overloads)

Translate Translates input parameter value into output parameter

value, based on a specified algorithm or table

User interaction Allows information to be exchanged between the network

and a call party, for example by playing an announcement

or by receiving DTMF tones from a party

Verify Performs a syntactic check on the input parameter,

according to a given syntax

Basic call

process

Basic SIB which represents the setting up of a

point-to-point call

phases of setting up a telephone call from one user to another. At each of

these phases it is possible to interrupt the call setup process and to start

executing a service program.

The points at which the call processing can be interrupted are the

points of initiation (POIs). When a service is started at a POI, we say that

the service is triggered; for this to happen it is necessary to arm a trigger

at the POI beforehand so that the BCP knows it must suspend processing.

At the time of triggering, the BCP passes the CID to the first SIB in the

chain to be executed. The SIBs that make up the service can then change

the CID as required by the service. In the case of call forwarding, for

example, they can change the destination address.

After finishing the processing of the service, the last SIB hands back

control to the BCP. The service can order a jump to any point in the BCP

call processing; it does not have to be at the same point that the service

was invoked.

The point at which control is handed back to the BCP is called the

point of return (POR), and at this point the BCP can be instructed to han-

dle the call in a specific way. Table 2.5 show the POIs (on the left) and the

parameters that can be passed to the BCP with the POI (on the right).

To illustrate how a service is described at the global functional plane,

we will now consider the example of a call made with a calling card.


ScreenStartIn list

Service support data

Call instance dataInput: dialed number

Not in list

Screening list

Figure 2.7 Parameters of the screen SIB.

Figure 2.8 shows how this service could be implemented with three

SIBs. The example is of course oversimplified, and only serves to further

an understanding of how services are defined with SIBs. Figure 2.8 shows

only the logical flow of SIBs. All SIB parameters (CID and SSD) have

been omitted for simplicity’s sake.

According to Figure 2.8, the service could be implemented as follows.

Imagine that the user dials a special number corresponding to the

calling-card-call service. The following would then take place:


Table 2.5

POIs and PORs of the CS-1 BCP

POIs PORs

Call originated

Address collected

Address analyzed

Call arrival

Busy

No answer

Call acceptance

Active state

End of call

Handle as transit

Continue with existing data

Proceed with new data

Provide call-party handling

Initiate call

Clear call

Basic call process

Userinteraction

Service datamanagement

Charge

POI POR POR

Addresscollected

Not OK

OK

Calling-card service

Continue with new data Clear call

(1)

(2) (3)

(4)

(5)

Figure 2.8 Calling-card-call service defined at GFP level (simplified).

1. At the address-collected POI, the BCP immediately recognizes that

the dialed number is special and triggers the calling-card-call

service.

2. The first SIB to be executed is the user-interaction SIB. This SIB

plays a message to the user: Please enter your card number, PIN

code, and the number you want to dial. It collects the DTMF tones

from the user and converts them to numbers.

3. The next SIB in sequence, service data management, uses these

numbers to look up the calling card for this user and check the PIN

code.

4. If the card exists and the PIN code is correct (the OK branch), then

the charge SIB starts charging the call to this calling card. After this,

control is passed back to the BCP at the same point at which call

control was suspended. The POR carries the instruction continue

with new data, causing the call to proceed with the destination

number input by the user.

5. If the card number or the PIN code is incorrect (the not-OK

branch), then the service instructs the BCP to terminate the call

immediately by jumping to the clear-call POR.

This is of course a simplified example. Real-life services can take up to

1,000 SIBs, although most of the service logic is usually for error han-

dling. Services like the calling card call have to take into account any pos-

sible error: wrong card number, incorrect PIN, invalid destination

number, time-out of user response, and so on. Service providers say that

as much as 80% of the service logic can be spent on error handling.

2.5 Distributed functional plane

Whereas the GFP helps to identify the building blocks out of which to

construct services, its view of the network is simplistic. In reality we can-

not manage the network as if it were one machine with a single BCP for

each call. In practice, the network has a complex layered structure and

consists of many specialized elements. Things get even more complicated

if we think about calls that start in one operator’s network and end in

another’s. The GFP does not give us any clues as to how to actually

implement the services in the network.


The purpose of the DFP is to provide a more realistic view of the net-

work, reflecting the distribution of functions. In reality, the setup of a

telephony call is not a centralized function, as the GFP assumes. It is the

result of interactions between switches that use protocols to decide how

to route the call from source to destination. To reflect this reality, the DFP

distinguishes different functions in the network.

2.5.1 Functional entities

The DFP identifies the different functional entities (FEs) that make up the

telephony network. FEs are distributed network functions that run the

BCP and the other SIBs defined at the GFP. A single SIB can map onto

more than one FE.

The DFP also describes the information flows between FEs. They

define what information must be exchanged between the different func-

tional entities to implement each SIB. The information flows are specified

in the specification and development language (SDL)3

and with message

sequence charts (MSC). Both are ITU-standardized languages for the for-

mal description of distributed systems. Figure 2.9 illustrates how the

implementation of SIBs is distributed over FEs.

The most important FEs defined in CS-1 are as follows:

◗ Call control function (CCF): keeps the state of a call, such as alerting or

terminating line busy;

◗ Service switching function (SSF): takes care of controlling the bearer

connections in a call, typically voice circuits;

◗ Service control function (SCF): contains the programs that control serv-

ices. Such programs are called service logic in IN;

◗ Service data function (SDF): represents the databases that keep the

service support data, for example number translation tables or pre-

paid account credit data;

◗ Service management function (SMF): contains all management func-

tions, such as installing new services, adding or deleting service sub-

scribers, and updating service data;


3. The SDL and MSC standards are defined in ITU recommendation Z.100.

◗ Special resource function (SRF): represents special functions in the

network that could be needed to realize services, such as playing

announcements, playing tones, generating special ringing patterns,

or bridging and mixing of conference calls.

The difference between the CCF and SSF should be noted. It is natu-

ral to wonder why there are two separate functions to represent the set-

ting up of telephone calls. From the user perspective, the call and the

connection are the same thing: Wouldn’t it be sufficient to have the SSF

alone represent the functionality of the switch?

Remember that SS7 already separates signaling from connections. In

other words, the signaling involved in setting up a call is carried on a dif-

ferent network than the voice connections themselves. Taking this a step

further, we could imagine a call as being not just a connection from A to

B, but a general concept that associates parties (users placing or receiving

the call) with connections and network resources during a delimited

period of time.


BCPChargeSIB

QueueSIB

ScreenSIB

TranslateSIB

Global functional plane

Distributed functional plane

CCF

SSF

SRF

SCF

SDF

SMF

Figure 2.9 Distributed functional plane.

There are important advantages to distinguishing between calls and

connections. Such separation allows for the concept of the call to extend

naturally to conferences, multimedia communications, and even Internet

connections. And it allows service logic programs (like IN) to control the

adding and dropping of connections within the context of a single call. It

is especially for this reason that IN separates the CCF from the SSF.

2.5.2 Half call

The DFP provides a more detailed representation of the basic call process.

The most important refinement is that the DFP takes into account the dis-

tributed nature of a call. At the DFP level, the call is no longer seen as a

single abstract process, but a distinction is made between call processing

for the originating (calling) party and for the terminating (called) party.

The DFP introduces the concept of a half call: the BCP is now split

into two parts, called the originating basic-call-state model (O-BCSM)

and the terminating basic-call-state model (T-BCSM). The O-BCSM

describes the procedure for initiating a call, while the T-BCSM describes

the process of receiving one. Both the O-BCSM and T-BCSM can trigger

services in the SCF, as Figure 2.10 illustrates.

It is obvious why the DFP distinguishes between O-BCSM and

T-BCSM: There exist IN services that deal with outgoing calls (for exam-

ple, abbreviated dialing) and services that deal with incoming calls (for

example, blocking of malicious calls). Apart from this, the caller and


O-BCSM T-BCSM

SCF

SSF

Called partyCalling party

TriggerTrigger

Figure 2.10 The half-call concept as defined in the DFP.

called party are not necessarily connected to the same switch or even to

the same network, so one cannot assume that there is one global process

that has control over the whole call.

2.5.3 Detection points

The O-BCSM and T-BCSM can both be seen as more detailed versions of

(half of) the BCP of the GFP. Both the O-BCSM and T-BCSM are repre-

sented as state-transition diagrams that describe the call-processing states

and transitions between them. The states are called points in call (PIC),

and the transitions are caused by events, such as taking the phone off the

hook, dialing a number, putting the phone on the hook, or flashing

(swiftly pushing) the hook.

An event can have a detection point (DP) associated with it. DPs can

be seen as implementations of the POIs defined at the GFP: They are

points at which the SSF can suspend call processing and hand over con-

trol to the SCF. Figure 2.11 shows the PICs and DPs of the O-BCSM and

T-BCSM.

Each large dark box in Figure 2.11 represents a PIC. The lines and

arrows represent events, and the small lighter boxes represent DPs. The

PICs and DPs are rather self-explanatory, apart from a few odd names such

as O_Null_and_Authorize_Origination_Attempt, T_Null_and_

Authorize_Termination_Attempt, and Route_Select_Failure. The

DPs can imply different courses of action, depending on the kind of service

requested and the DP that requests it, as follows:

◗ Trigger detection points (TDPs): set statically at the time of deployment

of a service or when a user subscribes to it;

◗ Event detection points (EDPs): set dynamically by service logic during

the course of a call.

For example, one would use a TDP for a static service such as freephone,

but an EDP would have to be dynamically set to realize a service such as

automatic callback on busy.

When the O-BCSM or T-BCSM encounters a detection point, two

kinds of action are possible:

1. Notification. The BCSM only sends information to the SCF and con-

tinues without waiting for a response.


44 Next Generation Intelligent NetworksO

-BC

SM

T-B

CS

M

O_N

ull

an

d_A

uth

ori

zeO

rig

ina

tio

n_a

tte

mp

t

Co

lle

ct_

Info

An

aly

ze_In

fo

Ro

uti

ng

&A

lert

ing

O_A

ba

nd

on

Co

lle

cte

d_In

fo

An

aly

zed

_In

fo

O_A

nsw

er

O_N

o_A

nsw

er

O_M

id_C

all

O_D

isc

on

ne

ct

O_Exception

Ori

gin

ati

ng

_A

tte

mp

t_A

uth

ori

zed

O_A

cti

ve

Ro

ute

_S

ele

ct_

Fa

ilu

re

O_C

all

ed

_P

art

y_B

usy

_T

_N

ull

_a

nd

_A

uth

ori

ze_

term

ina

tio

n_A

tte

mp

t

Se

lec

t_Fa

cil

ity

an

dp

rese

nt

ca

ll

T_A

cti

ve

T_A

ba

nd

on

T_D

isc

on

ne

ct

T_A

lert

ing

T_A

nsw

er

T_M

id_C

all

T_N

o_A

nsw

er

T_Exception

Te

rmin

ati

ng

_A

tte

mp

t_A

uth

ori

zed

T_C

all

ed

_P

art

y_B

usy

Fig

ure

2.1

1B

CS

Ms

for

ori

gin

ati

ng

an

dte

rmin

ati

ng

sid

es.

2. Request. The BCSM suspends call processing, hands control to the

SCF, and awaits a response before continuing, possibly with modi-

fied call parameters.

The call-forwarding service, for example, can be started only as a request,

because call processing must wait for the number to be translated. On the

other hand, a televoting service may only need information to be sent to

the SCF without suspending the call.

Depending on whether a detection point is a TDP or an EDP, a notifi-

cation or a request, there are four possibilities, as shown in Table 2.6.

2.5.4 Trigger processing

The SSF must have a mechanism for handling DPs when they are

encountered during the processing of a call. In practice, this is usually a

table that lists which DPs are armed and whether they are TDP-N, TDP-R,

EDP-N, or EDP-R. The IN standards also define a function in the SSF that

detects and resolves conflicts between different services triggered on the

same call, the feature interaction manager (FIM).

Figure 2.12 shows an example of the DP processing mechanism in

the SSF. It makes no difference in this example whether we are looking

at an O-BCSM or T-BCSM, since DP processing is the same for both.

Figure 2.12 shows the following sequence of events and triggers:

1. The first DP encountered by the BCSM is not armed, and the

BCSM is instructed to continue.

2. The next DP is armed as TDP-N, meaning that only a notification is

sent to the SCF, and the BCSM immediately resumes without

waiting for a response. Before relaying the TDP-N to the SCF, the

FIM checks for interactions with other services activated on the

same call.


Table 2.6

Detection Point Types

Trigger Detection Point Event Detection Point

NotificationTrigger detection

point—notification

(TDP-N)

Event detection

point—notification (EDP-N)

Request Trigger detection

point—request (TDP-R)

Event detection

point—request (EDP-R)


PIC

DP

PIC

DP

PIC

DP

DP

pro

ce

ssin

gFe

atu

re-

inte

rac

tio

nm

an

ag

er

no

ta

rme

d

Re

sum

e

TD

P-N

!

PIC

DP

SS

FS

CF

Pro

ce

ssn

oti

fic

ati

on

TD

P-N

Re

sum

e

TD

P-R

!P

roc

ess

req

ue

st

TD

P-R

arm

DP

arm

ED

P-R

ED

PR

!C

he

ck

co

nfl

icts

Ch

ec

kc

on

flic

ts

Ch

ec

kc

on

flic

ts

Pro

ce

ssre

qu

est

TD

P-R

Re

sum

ere

spo

nse

BC

SM

Se

rvic

e-

log

icp

rog

ram

(1)

(2)

(3)

(4)

Re

sum

e

Fig

ure

2.1

2D

Pp

roc

essin

ga

nd

fea

ture

inte

rac

tio

nm

an

ag

er.

3. The third DP encountered is armed as a TDP-R. This time it is a

request, so call processing is suspended and the request is sent via

the FIM to the service logic. In this example, the service logic

responds with a command to arm an EDP-R further on in the

BCSM. This command is passed back to the DP processing module,

which takes care of arming the EDP-R. Then it instructs the BCSM

to resume.

4. The last DP encountered in this example is the one previously

armed by the service logic. This is an EDP-R, which means that call

processing is also suspended until the SCF returns a response, for

example a translated number.

In this example, the BCSM resumes at the next PIC. It is important to

note that the service logic may instruct an event to be armed at any DP in

the BCSM, and that call processing can resume at any point in the BCSM.

In other words, it is unnecessary that call processing always resume at the

next PIC. For example, in a service in which a PIN code is checked, it

makes sense to jump directly to the end of the BCSM and release the call

if the PIN is entered incorrectly.

From the discussion in this section, it is obvious that the distributed

functional plane is significantly more complex than the global functional

plane, but also more realistic in its modeling of call processing and the

ways in which control can be passed to the SCF.

2.6 Physical plane

The DFP takes into account the distributed nature of the network, but

only in a superficial way. The DFP recognizes the difference between the

calling and called party, and between service switching and service con-

trol, but does not go so far as to allocate functions to physical locations or

machines. This is done in the physical plane.

2.6.1 Physical entities

The physical plane allows for different mappings of IN functions onto

physical nodes. The simplest mapping simply allocates a distinct node, as

follows, for each function:


◗ Service switching point (SSP): contains the switch, but typically also

holds the CCF and SSF.

◗ Service control point (SCP): contains the SCF.

◗ Service data point (SDP): contains the database or databases that make

up the SDF.

◗ Service management point (SMP): hosts the SMF.

◗ Intelligent peripheral (IP): implements the SRF.

Figure 2.13 illustrates this straightforward mapping of functional entities

onto physical ones.

It is clear that the mapping of Figure 2.13 would require at least four

or five machines to implement an IN system. In smaller networks or in

cases in which there are few services or few service subscribers, the

number of machines can be reduced by colocating certain DFP functions

on the same physical node. For performance reasons, the SCP very often

also hosts the service databases. In other words, the SCF and SDF are

often combined into one SCP. This is shown in Figure 2.14.

The configuration requiring the least hardware is one in which the

SCF, SDF, and IP are located together on one machine. Such a configura-

tion is often referred to as a service node. Many switch vendors actually


SSF

CCF

SRF

SCF SMF

SDF

SSP SCP

IP

SDP

SMP

SDP

Physical plane


Figure 2.13 IN physical plane.

combine these functions with the switch itself, and in this case the service

node even includes the SSF. Figure 2.15 illustrates the service node

concept.


SSF

CCF

SRF

SCF SMF

SDF

SSP SCP

IP

SMP

Physical plane


Figure 2.14 Colocation of SCF and SDF at the physical plane.

SSF

CCF

SRF

SCF SMF

SDF

ServiceNode

Physical plane

SMP


Figure 2.15 Colocation of IN functions in a service node.

In practice, one can find all of these configurations on the market.

Obviously it is more difficult to support high throughput with a service

node implemented on a single machine than with a multimachine con-

figuration. Service nodes therefore tend to be used in smaller networks,

or in networks with few value-added services. Nevertheless, service

nodes represent an important market, and some vendors concentrate

completely on this business segment.

Many manufacturers support a range of configurations and adapt

their offer to the operator’s requirements and budget. The INCM allows IN

to be built in a modular way, by creating a software module for each FE.

This allows the manufacturer to distribute FEs over physical machines

according to the customer’s needs.

2.6.2 IN application protocol

The INCM is useful in understanding IN, but in the end, building an IN

system comes down to implementing protocols. The protocol used for

communications between FEs is INAP. This protocol is called an applica-

tion protocol because in terms of the seven-layer OSI model, it is situated

in the uppermost application layer (layer 7). We will not discuss OSI in

any further detail here, because it is of little relevance in understanding

IN.

Strictly speaking, INAP is not defined as part of the physical plane,

but is described in separate documents (Q.1208, Q.1218, and Q.1228).

But since INAP is about implementing IN, we will cheat a little and dis-

cuss it here.

INAP messages contain the information exchanged between func-

tional entities, in particular between the SSF and SCF and between

the SCF and SRF. The communication between the SCF and SDF is a

special case, since it is not defined by INAP but is based on the Direc-

tory Access Protocol (DAP), also specified by the ITU in its X.500

recommendations.

INAP is not just a collection of stand-alone messages, but messages

that when sent must follow a certain order, called a dialogue. These dia-

logues implement the information flows defined in the distributed func-

tional plane. Figure 2.16 shows a simple example of such a dialogue for

the freephone service. The procedure is as follows:

1. When the BCSM recognizes the number dialed by the user as a

freephone number, this triggers a TDP-R.



O_

Nu

lla

nd

Au

tho

rize

Ori

gin

ati

on

Att

em

pt

SS

FS

CF

SD

F

An

aly

ze_

Info

Co

lle

cte

d_

Info

O_

Ac

tiv

e

O_

Dis

co

nn

ec

t

TD

P-R

TD

P-N

TD

P-R

init

ialD

P(c

all

id,d

iale

dn

um

be

r,‘f

ree

ph

on

e’)

,re

qu

est

Info

(fre

ep

ho

ne

DB

,d

iale

dn

um

be

r)

req

ue

stIn

foR

esp

on

se

(de

stin

ati

on

id)

co

nn

ec

t(c

all

id,d

est

ina

tio

nid

);re

qu

est

Re

po

rt(O

_A

nsw

er,

O_

Dis

co

nn

ec

t)

ev

en

tRe

po

rt(c

all

id,

O_

An

swe

r,ti

me

sta

mp

)

ev

en

tRe

po

rt(c

all

id,

O_

Dis

co

nn

ec

t,ti

me

sta

mp

)

Sta

rtre

ve

rse

ch

arg

ing

Sto

pre

ve

rse

ch

arg

ing

BC

SM

(1)

(2)

(3)

(4)

(5)

(6)

(7)

Lo

ok

up

dia

led

nu

mb

er

infr

ee

ph

on

ed

ata

ba

se

O_

An

swe

r

Fig

ure

2.1

6S

imp

lifi

ed

INA

Pd

ialo

gu

efo

rfr

ee

ph

on

ese

rvic

e.

2. As a result, the SSF sends an initialDP message to the SCF with

the calling line identifier, dialed number, and service identifier as

parameters. The meaning of the initialDPmessage is to start the

service processing in the SCF. As explained before, a service is

defined as a sequence of SIBs in the GFP. In the DFP these SIBs

map to programs in the FEs that communicate by sending mes-

sages to each other.

3. In this example, the service program in the SCF first queries the

database in the SDF to find out where to route this call. It does this

by sending a requestInfo message to the SDF.

4. The SDF looks up the dialed freephone number in the database,

finds the corresponding destination network address, and returns

it to the SCF in a requestInfoResponse message.

5. The SCF then orders the SSF to connect the calling party to the des-

tination address, using the connect message. The SCF also

requests the SSF to be notified when the connection is actually

established and stopped. For this it sends a requestReport mes-

sage to the SSF, indicating the DPs where it wants to be notified (in

this case O_Answerwhen the call is accepted, and O_Disconnect

when the call is disconnected).

6. When the destination party answers the call, the SSF sends an

eventReport message with a time stamp. As a result, the SCF

starts reverse charging the call to the destination address (remem-

ber, this is a freephone service; the caller does not pay).

7. Finally, when one of the parties releases the call, the SSF sends

another eventReport message to the SCP, causing the SCP to

stop charging and terminate the freephone service processing.

Of course, this example is oversimplified. In reality the dialogues are

much longer and the messages have many more parameters. In fact, the

INAP specifications are hundreds of pages long and grow with each capa-

bility set. But what is important here is to understand the basic mecha-

nism: dialogues of INAP messages implement the information flows

between FEs, which in turn implement the SIBs, the building blocks out

of which services are developed.


INAP carries only the information directly related to information

exchange between IN FEs. It does not take care of the correct transmis-

sion of messages, error corrections, or keeping track of the state of a dia-

logue. All this is taken care of by the SS7 protocols situated below INAP,

shown in Figure 2.2 in Section 2.1.

INAP messages are transported within TCAP messages. As explained

in Section 2.1, TCAP is a protocol for establishing dialogues and keeping

track of transaction states. A TCAP message contains two parts: the trans-

action portion for managing the transaction, and the component portion

for carrying protocol messages. INAP messages are carried in the compo-

nent portion of a TCAP message, as part of a TCAP-managed dialogue.

The syntax of INAP is formally specified in the abstract syntax nota-

tion 1 (ASN.1). ASN.1 is a complex language and that can be difficult to

read, but the bottom line is that the grammar of INAP is unambiguously

defined. The standard is also very precise about what data types can be

exchanged; for example, a series of digits is different from a number or a

string.

Now that we are familiar with the basic concepts of IN, in the next

section we will look at the extensions that have been made over the years

in CS-2 and CS-3.

2.7 CS-2

The first IN standards were defined at a time when telecommunications

operators were still mostly state-owned monopolies, the Internet was a

tool only for the research community, and GSM was in the embryonic

stage. In fact GSM was standardized more or less in the same time frame

as IN CS-1 (that is, between 1988 and 1992), but IN and GSM standardi-

zation were quite different activities.

IN was initially designed for fixed voice telephony networks gov-

erned by a single operator. The IN CS-1 standard was powerful and sim-

ple, but by the time IN platforms were being deployed in real networks in

the 1990s, the world was undergoing radical changes. Telecommunica-

tions markets were deregulated and opened to competition. Even within

the same country, calls could now initiate in one operator’s network and

terminate in another’s. To stimulate competition, many regulatory bodies

began requiring number portability, allowing customers to change opera-

tors without changing their number.


The second half of the 1990s was also the era of the mobile phone

and the Internet. All this contributed to a true explosion of complexity in

the network. Even in the first years that IN was being deployed, between

1992 and 1995, it became clear that the CS-1 standard was already out of

date. Some of the limitations of the CS-1 standard were as follows:

◗ The CS-1 specifications assume that the network is controlled by a

single operator and does not provide for adequate mechanisms to

provide services over operator boundaries (so-called internetwork-

ing services).

◗ CS-1 deals with point-to-point telephone calls and does not offer

sufficient features for multiparty and multimedia communications

(such as videoconferences).

◗ CS-1 has only limited features for mobility. A particular problem

with CS-1 is that user interactions can take place only when a call

is set up first. In mobile networks, however, many procedures take

place outside the context of a call, for example user authentication

or location updating.

The target for CS-2 was to lift some of these limitations while

remaining backward compatible with CS-1. The extensions to CS-1 that

were made in CS-2 (and maintained in CS-3) can be summarized as

follows:

◗ CS-2 allows communications from one SCF to another and from

one SDF to another. This means that service logic and data can be

distributed and that services can be controlled across operator

domains.

◗ CS-2 can handle calls between more than two parties. In technical

terms this means that one service logic instance in the SCF can con-

trol more than one BCSM at a time.

◗ CS-2 allows user interactions to take place outside the context of a

call, by creating a basic call-unrelated process (BUCP) in addition to

the BCP in the GFP. Likewise, CS-2 defines a basic call-unrelated

state model (BCUSM) at DFP level as a call-unrelated counterpart of

the BCSM.


◗ CS-2 allows call-related and call-unrelated user interactions to use

out-channel signaling connections (i.e., signaling connections that

are not related to the call or even the telephony network; for exam-

ple, a GSM short message or a TCP/IP connection).

◗ CS-2 generalizes the service-creation concept. By refining the con-

cept of SIBs and making it recursive, it becomes more of a true com-

ponent model.

◗ Service management guidelines are better defined in CS-2 than they

were in CS-1.

◗ CS-2 contains guidelines for service-interaction processing, neces-

sary for resolving conflicts between incompatible services.

Straightforward as they may appear at first sight, these points require

complex changes in the global functional plane, the distributed func-

tional plane, and in the definition of the INAP protocol. We will now take

a closer look at how CS-2 refines the INCM.

2.7.1 CS-2 service plane

The IN service plane was first properly defined in CS-2. Although the

INCM was defined with the CS-1 specifications, the service plane was not

formally defined for CS-1. According to the Q.1200 series recommenda-

tion structure explained in Section 2.2.3, recommendation Q.1212

should define the CS-1 service plane. In reality, this document was never

produced.

The first IN specifications were an evolution from existing network

features that were until then programmed in the switch. These supple-

mentary services were widely known and were not unique to IN, and ITU

never bothered to specify them. CS-2, on the other hand, does define a

service plane, because it introduces new features that provide for more

than the classic switch-based services.

It is important to keep in mind that IN does not standardize services.

The CS-2 service plane only provides a benchmark for the minimal set of

services and features that can be implemented in CS-2. It does not say

that these are the CS-2 services, but rather that this is the minimal set of

features and services that you should be able to implement in CS-2.

The CS-2 service plane is backward compatible with the CS-1 serv-

ices, but adds features for internetworking, call-party handling (CPH),

out-channel user interactions, service management, and service creation.


2.7.2 CS-2 global functional plane

An important change in the GFP is the addition of BCUP. This is a special

SIB much like the BCP, except that it describes the process of call-

unrelated user interaction. A typical case of such call-unrelated user inter-

action is the registration of a user to a network or terminal. Such interac-

tions are common in GSM networks, for example when a user switches

on a mobile or moves between radio cells. The BCUP models such authen-

tication and registration procedures outside the context of a call.

CS-2 also provides more points of control in a call by extending the

BCP with new POIs and PORs. It introduces new POIs for midcall inter-

ruptions, like a hook flash or pushing the special R button on the phone.

The new PORs are mostly related to the individual handling of connec-

tions between call parties. In CS-1 this type of control was not possible.

In CS-2 a service process does not have to be a single chain of SIBs as

in CS-1, but can involve multiple processes.4

During its execution, a serv-

ice logic program can create new processes that run in parallel and can

communicate between each other by messages.

The CS-2 global functional plane redefines some of the CS-1 SIBs and

includes a number of new ones. The user interaction SIB is extended so

that it also handles out-channel and call-unrelated user interactions.

Apart from the special BCUP, the new SIBs are for the following:

◗ CPH: to manage the attachment and detachment of parties within a

call;

◗ Process management: to manage the creation and destruction of par-

allel service processes and the communication between them.

Without going into detail, Table 2.7 summarizes the new CS-2 SIBs and

their functions.

CS-2 also extends the mechanism by which services are created out

of SIBs. CS-1 defined a fixed set of SIBs that cannot be modified or

extended. In CS-1, it is not possible to create reusable components out of

groups of SIBs, something that can be very useful in practice. CS-1

proved to be too rigid and in practice many manufacturers ended up

implementing their own nonstandard SIBs.

CS-2 refines the SIB concept by defining a recursive service-creation

model:


4. These processes can be compared with threads in some programming languages.

◗ A SIB operation represents an atomic operation that cannot be

divided into smaller components.

◗ A high-level SIB (HLSIB) is a component that can be composed

out of SIB operations, SIBs, or other HLSIBs, as illustrated in

Figure 2.17.


Table 2.7

New SIBs in CS-2

Basic Call-Unrelated Process

BCUP Describes user interactions that take

place outside the context of a call (e.g.,

authentication, registration, location

update)

SIBS for Call-Party Handling

Split Detaches one or more call parties from

an existing call, and attaches them to

another call

Join Attaches one or more call parties to a call

SIBs for Process Management

Initiate

service

process

Starts a new service process to be run in

parallel

End Ends a service process

Message handler Sends a message to, or receives a

message from, another service process

SIB

SIBoperation

SIBoperation

High-levelSIB

High-levelSIB

High-level SIB

Logicalstart

Logicalends

Figure 2.17 CS-2 high-level SIB concept.

This new definition of SIBs is quite powerful and allows for service com-

ponents to be specified at any desired level of granularity. To make CS-2

backward compatible with CS-1, the original notion of SIBs was kept in

CS-2. This is why the definition of HLSIBs also allows the possibility of

including normal SIBs. A CS-2 service logic program can be composed out

of any combination of SIB operations, CS-1 or CS-2 SIBs, and HLSIBs.

2.7.3 CS-2 distributed functional plane

The CS-2 DFP describes the FEs and the information flows between

them, following the rules of the INCM. It is backward compatible with

the CS-1 DFP, so it maintains the CCF, SSF, SCF, SDF, SMF, and SRF and

extends them with new functionality. CS-2 also introduces a number of

new FEs:

◗ Call-unrelated service function (CUSF) processes events from call-

unrelated user interactions, and can trigger service processing in

the SCF. The CUSF is like the SSF, but for call-unrelated events.

◗ Service control user agent function (SCUAF) represents the call-unrelated

user interface that allows a user to communicate with the CUSF.

Although the SCUAF does not have a real counterpart in CS-1, one

could argue that its function is similar to that of the SRF except for

call-unrelated interactions.

◗ Service management access function (SMAF) provides a user interface for

external access to the SMF, for example through the Internet.

◗ Intelligent access function (IAF) is an interworking function that

allows an SCF to control non-IN equipment.

In addition to these new FEs, CS-2 defines three functions for mobile net-

works: the call-related radio access control function (CRACF), call-

unrelated radio access control function (CURACF), and radio control

function (RCF). As the control of radio access is not a major concern for

CS-2, however, these FEs and their information flows have only an infor-

mative status in the standard.

Apart from defining new FEs, CS-2 also introduces new information

flows between existing FEs that did not exist in CS-1. CS-2 allows SCFs to

communicate directly with each other and service control to be distrib-

uted. CS-2 also lets data be distributed over SDFs. This is illustrated in

Figure 2.18.


The possibility of distributing service control and data is particularly

useful in cases in which services must be delivered across service provider

domains. An example is the international virtual private network (IVPN),

in which an international company may have employees and terminals

distributed over different networks.

The CS-2 O-BCSM and T-BCSM contain new PICs and DPs that are

refinements of those defined for CS-1. Table 2.8 shows how the CS-2

PICs relate to the CS-1 PICs shown in Figure 2.11.

As Table 2.8 shows, many PICs have remained the same, but some,

such as O_Null&Authorize_Origination_Attempt, Routing&

Alerting, and Select_Facility&Present_Call were split up in

finer PICs. There are two new PICs in CS-2 that did not exist in CS-1:

O_Suspended and T_Suspended. These new PICs represent a half call

that is neither active nor released (for example, when a party is put on

hold). CS-2 also defines new DPs for the new PICs where service logic can

be triggered.

Apart from the O-BCSM and T-BCSM, CS-2 defines a new BCUSM

that represents user interactions taking place outside the context of a call.

The BCUSM has a simple structure and is shown in Figure 2.19. The states

and transitions of the BCUSM represent the activation and release of a sig-

naling channel for user interaction, and the reception of user data in the

form of components. All this takes place outside the context of a call.

One of the most important new features in CS-2 is CPH. In CS-1 it

was only possible to set up and release a call between two parties. The call


CS-1

CS-1

CS-1

CS-1CS-2

CS-2SDF

SDF

SCF

SCF

SSF

SSF

Network 1

Network 2

Figure 2.18 New relationships between FEs in CS-2.

and the connection set up as the result of the call were the same thing. In

CS-2 it is possible to manipulate the individual parties in a call and their

connections. Within the context of a call, CS-2 lets you add or drop call

parties and connections. This means that the call and the connection are

no longer the same thing: The configuration of connections set up within

a call can change as parties are added and dropped.

It was necessary to add CPH in CS-2 to control services like confer-

ence calls where there are more than two parties involved in the commu-

nication. But CPH is also required to realize more elementary services

such as call waiting.

The addition of CPH makes CS-2 much more complex than CS-1. At

the level of the GFP, this complexity is not so apparent; there are only


Table 2.8

Comparison of CS-1 and CS-2 PICs

CS-1 PIC CS-2 PIC

O-BCSM

O_Null&Authorize_Origination_

Attempt

O_Null

Authorize_Origination_Attempt

Collect_Info Collect_Information

Analyze_Info Analyze_Information

Routing&Alerting Route Select

Authorize_Call_Setup

Send Call

O_Alerting O_Alerting

O_Active O_Active

O_Exception O_Exception

— O_Suspended

T-BCSM

T_Null&Authorize_Termination_

Attempt

T_Null

Authorize_Termination_Attempt

Select Facility&Present Call Select Facility

Present Call

T_Alerting T_Alerting

T_Active T_Active

T_Exception T_Exception

— T_Suspended

two new SIBs: split and join. At the network equipment level, the story is

quite different: CHP requires connections to be associated to a call, and

could involve special resources like audio bridges.

One of the most important requirements is that the service logic in

the SCF must always have a consistent view of the configuration of the

connections in a call. When the SCF loses track of who is connected to

the call, the service gets into an inconsistent state and the effect of a join

or split operation becomes unpredictable. For this reason, CS-2 defines a

formal model for describing the state of connections in a call. This is

called the connection view state (CVS) model.

The main elements in a CVS are as follows:

◗ Call segment (CS) describes a half call as explained in Section 2.5.2,

but in CS-2 a half call can also apply to multiparty calls. A CS is

described in terms of legs and connection points.

◗ Connection point (CP) is a joint between two or more legs or between

just one leg and the network. The notion of a CP is generic; it can be a

switched connection, but it can also be an audio bridge or a media

distribution point.


Active

Release

Release

Activationfailed

ReleaseReleased

Componentreceived

Activation receivedand authorized

Association releaserequested

Idle and authorizeactivation/association req.

Figure 2.19 BCUSM.

◗ Leg represents a part of the communication path between parties in a

call. A leg can be controlling or passive, depending on whether serv-

ice logic was invoked for this leg or whether it receives instructions

passively.

◗ Call segment association (CSA) is the group of all call segments that are

involved in a given service and that are controlled by the SCF. In

principle a call segment can be made out of any combination of legs

and connection points, but not all combinations are meaningful.

CS-2 identifies 14 specific configurations that are found in the most

common services.

The CS-2 standard uses a graphical notation to describe CVS. The dia-

grams for call segments show a connection point and the legs attached to

it. For each leg it is indicated whether it is controlling (indicated by the

letter c) or passive (indicated by the letter p). The diagram also shows

whether the leg has actually been set up (called joined) or whether it is

still in the phase of being set up (called pending).

To show how the CVS represents the state of the connections in a

call, we will now consider the very simple example of the follow-on call

feature. This feature is used for example in credit card calls and allows a

user to make several calls without putting the telephone on-hook and

entering the credit card details every time. Figure 2.20 shows a simplified

version of the information flows between the SCF and SSF for the

follow-on call feature, and the resulting CVS.

The information flow for the follow-on call leads to the following

connection view states:

1. When the user places the first call, the O-BCSM in the SSF detects a

trigger and sends the initialDP message to the SCF.

2. The SCF instructs the SSF to connect the originating and destina-

tion parties, and requests the SSF to report any midcall events.

3. When the user ends the first call and wishes to make a follow-on

call, he or she does not put the telephone on the hook, but simply

flashes the hook. This causes a midcall event to be reported to the

SCF.

4. As a result, the follow-on call service logic does not terminate the

call, but only disconnects the leg to the destination party.


Intelligent networks 63S

SF

SC

F

init

ialD

P(c

all

id,d

iale

dn

um

be

r‘f

ree

ph

on

e’)

ev

en

tRe

po

rt(O

_M

id_C

all

,O

_S

wit

ch

ed

_H

oo

k_F

lash

_Im

me

dia

te)

Co

nn

ec

tio

nst

ate

vie

w

dis

co

nn

ec

tLe

g(l

eg

id)

co

nn

ec

tTo

Re

sou

rce

(SR

F)

pro

mp

t&C

oll

ec

tUse

rIn

form

ati

on

(me

ssa

ge

id)

pro

mp

t&C

oll

ec

tUse

rIn

form

ati

on

_R

esu

lt

dis

co

nn

ec

tFo

rwa

rdC

on

ne

cti

on

(SR

F)

co

nn

ec

t(c

all

id,n

ew

de

stin

ati

on

id)

O-B

CS

M

cp

O-B

CS

M

cp

O-B

CS

M

c

O-B

CS

M

c

SR

F

Ori

gin

ati

ng

setu

p

Sta

ble

2-p

art

y

1-p

art

y

Fo

rwa

rdc

on

ne

cti

on

O-B

CS

M

c

1-p

art

y

O-B

CS

M

cp

Sta

ble

2-p

art

y

(1)

(2)

(3)

(4)

(5)

(6)

(7)

(8)

Joined

Joined

Joined

Joined

JoinedJoined

Joined

Joined

Pending

co

nn

ec

t(c

all

id,d

est

ina

tio

nid

);re

qu

est

Re

po

rt(O

_M

id_C

all

)

Fig

ure

2.2

0C

on

ne

cti

on

-sta

tev

iew

sfo

rfo

llo

w-o

nc

all

.

5. Next, the SCF instructs the SSF to establish a connection to the

SRF.

6. The SCF instructs the SRF to play an announcement message and

prompt the user to dial the number for the follow-on call.

7. When the SCF has received the digits for the next call, it orders the

disconnection from the SRF.

8. Finally, the SCF sets up the connection to the new call destination

specified by the user.

This scenario was taken from recommendation Q.1229. Of course, the

example is simplified; the INAP messages between the SSF and SCF are

more complex in reality. What is important is an understanding of the

principle: The CVS represents how the SCF sees the connections in the

SSF. When a command from the SCF to the SSF changes the connections

in a call, the CVS changes accordingly.

CVSs can become very complex, and in practice it is difficult to read

and interpret them in the standards. This is because IN CS-2 tries to

implement multiparty communications by using classic switching tech-

nology intended only for point-to-point telephone calls. This is like trying

to map a complex three-dimensional model to a two-dimensional picture

without losing any detail.

2.7.4 Implementing CS-2

Although CS-2 does not introduce significant new network elements at

the physical plane, the new CS-2 functionality does have its impact on

the definition of INAP. The most important extensions made to INAP in

CS-2 are those for CPH, call-unrelated interactions, and communication

between SCFs that share control of a call.

CS-2 is significantly more complex than CS-1, both conceptually and

in terms of the INAP protocol. As it turns out, the CS-2 standard contains

a certain amount of ambiguities and errors that proved a stumbling block

for a quick introduction into commercial platforms. For this reason CS-1

has remained the most frequently used capability set even years after

CS-2 was published (and it continues to be widely used today).

For CS-2 to become truly usable, it was necessary to resolve certain

problems with the specifications. Rather than producing a new version of

CS-2, these necessary revisions were made during the specification of


CS-3. As a result of this, CS-3 should probably be considered more as the

updated and extended version of CS-2 than as a new capability set.

The CS-3 recommendation respecifies INAP, but does not revise the

service plane, global functional plane, distributed functional plane, and

physical plane. One could say that CS-3 is to CS-2 what CS-1 R (version

1995) is to CS-1 (version 1992). In the following section, we will take a

brief look at CS-3 and its successor, CS-4.

2.8 CS-3 and CS-4

When standardization of CS-3 started, manufacturers and operators were

still struggling with the consolidation of CS-2. CS-2 introduced a new

level of complexity and with that, new ambiguities and problems with

the interpretation of the standards. Many of the necessary refinements

and corrections to the CS-2 standards were actually made during the

specification of CS-3. As a result, CS-3 should be regarded more as an

updated version of CS-2 than as a new capability set in its own right.

2.8.1 CS-3 features

CS-3 does not introduce new concepts in the INCM. For this reason the

ITU recommendations for IN CS-3 do not include documents

Q.1232–Q.1235, which would have specified the CS-3 SP, GFP, DFP, and

PP (see Table 2.2 in Section 2.2.3).

CS-3 does improve the CS-2 facilities for interworking with mobile

networks, broadband and narrowband ISDN, and the Internet. For this

reason the CS-3 standard includes two new documents:

1. Q.1236 is a document that describes a high-level management

information model for IN CS-3. In fact, one can hardly speak of it as

a standard; it is more of an informative document that presents

some considerations on service management.

2. Q.1237 gives a description of the extensions made in CS-3 to sup-

port broadband ISDN.

The most important part of the CS-3 standard is the redefinition of

the INAP protocol in document Q.1238. This document has seven parts,

each describing the interaction between specific functional entities.


CS-3 provides a couple of new facilities with respect to its predecessor

CS-2, such as support for number portability. Number portability means

that a subscriber can keep his or her telephone number when changing

operators or even when moving to a new geographical location. By now

this has been declared mandatory by regulatory bodies in most countries.

At first sight number portability does not seem difficult, because it

simply involves a number translation. This was possible even in CS-1.

The problem is that many operators started with non-IN implementations

for number portability. In many countries number portability requires

access to an external database managed by the national regulator. CS-3

offers the mechanisms for interworking with such hybrid systems.

A new technical feature of CS-3 is to allow multiple points of control.

This is a fundamental departure from CS-2, which allows only a single

point of control. In CS-2 only one service logic instance can control a call

segment at a time, whereas CS-3 allows several service logic instances to

control the same call segment at a time. This means that there must be

some way to arbitrate between service logic instances that try to execute

incompatible requests.

An example of a conflict that can arise with multiple points of control

is when two SCFs try to join and disconnect the same call leg at the same

time. CS-3 describes some mechanisms to detect and resolve such feature

interactions, although more work on this is still needed.

2.8.2 ETSI improvements in CS-2 and CS-3

Although the ITU standards can be seen as the master specification of IN,

the role of ETSI has proven crucial for the development of CS-2 and

CS-3. The ETSI group involved in the standardization of IN was the Serv-

ices and Protocols for Advanced Networks, Group 3 (SPAN 3).

Because the ITU CS-1 and CS-2 standards contain certain ambigui-

ties, many manufacturers ended up implementing IN with their own pro-

prietary version of INAP. In the mid-1990s it was practically impossible to

connect one vendor’s IN system to another’s for this reason. The different

manufacturers’ protocols simply were not compatible, although they

were all called INAP.

ETSI recognized this problem and specified core INAP, a simplified

version of INAP stripped of unnecessary complexity and a kind of com-

mon denominator of the INAPs in the market. Today many manufactur-

ers have core INAP-compatible IN systems.

Another important contribution of ETSI SPAN 3 was to specify the

entire distributed functional plane of CS-2 and CS-3 in SDL. ITU already


described the DFP information flows in SDL, but used the language rather

informally.

SDL is a formal language that allows for protocols and systems to be

specified unambiguously as communicating finite state machines. As

such, SDL provides a formal framework for validation, simulation, and

conformance testing. SDL can be used at various degrees of formality,

however, and the ITU specifications were not rigorous enough to serve as

a true conformance framework.

ETSI sharpened the SDL specifications to the point where they are

formal enough to allow for the automatic generation of test scenarios.

ETSI used the SDL models to specify protocol implementation confor-

mance statements (PICS) that can be used as formal references for IN

implementations. With this formal approach, ETSI also revealed and

resolved a number of ambiguities in the original ITU standards.

Although the ITU provided the ignition for the definition of IN, it is

fair to say that ETSI made some decisive contributions to IN during the

second half of the 1990s.

2.8.3 New additions in CS-4

While time pressure resulted in CS-3 being little more than a revised

version of CS-2, many new requirements for IN were delayed to CS-4.

Internet, mobile networks, and deregulation were changing the tele-

communications scene in a dramatic way, and object-oriented program-

ming was becoming the industry standard in computing. Against this

backdrop CS-4 was expected to introduce important innovations in the

INCM.

CS-4 was to accommodate the communications of the new era:

voice, video, multimedia, data communications, possibly involving multi-

ple parties, possibly involving mobile terminals, and using packet-based

transmission rather than switched connections. CS-4 was also expected

to provide an object-oriented model for services and service components,

up-to-date with industry standards.

The specification of CS-4 started in the summer of 1999 and was

completed in 2001. It has already become clear that CS-4 fulfills only part

of its promises. The ITU recommendations for CS-4 are little more than

another update of the INAP protocol.

The dominant part of the CS-4 standard is recommendation Q.1248,

a revision of the seven-volume CS-3 INAP specification. The only part of

the INCM updated in CS-4 is the DFP, defined in recommendation

Q.1244.


The most important new feature in CS-4 is its support for communi-

cations over the Internet. The CS-4 DFP introduces the session manager

(SM), a new FE for handling voice and multimedia sessions on the Inter-

net. The SM can set up and receive voice and multimedia calls over the

Internet using either of the two well-known protocols H.323 or SIP.5

From the Internet point of view, the SM looks like an H.323 gate-

keeper or SIP proxy and communicates with other H.323 gatekeepers

and SIP proxies. On the IN side, it looks like a special kind of telephone

exchange that can trigger services through the SSF. Figure 2.21 gives a

simplified view of the SM in the CS-4 DFP.

Figure 2.21 is somewhat simplified with respect to the standard. In

reality the standard describes two scenarios, one for H.323 and one for

SIP. For simplicity, Figure 2.21 collapses these views into one, and omits

FEs such as the CUSF, SMF, and SMAF that were already defined in CS-2

and CS-3.

CS-4 also includes protocols for the integration of telephony services

and Internet. The most important are the following:

◗ PINT: a protocol to set up IN calls from Web sites;

◗ SPIRITS: a protocol for Internet call waiting, a service that notifies

users connected to the Internet of incoming telephone calls.


Internet

SIPproxy

H.323gatekeeper

IN-IP gateway

SSF

SSF SM

SCF

SRF

SDF

Figure 2.21 CS-4 distributed functional plane (partial view).

5. See Sections 3.2.2, 3.2.3, and 3.2.4 for details on H.323 and SIP.

The PINT and SPIRITS protocols were proposed by the IETF. We will

study them in detail in Chapter 3.

While the expectations for CS-4 were high, in reality its standardiza-

tion has been slow and cumbersome. The industry has been unable to

come up with an IN that provides simple models for Internet, mobile net-

works, and object-oriented programming. Instead the CS-4 specifications

have been an attempt to stuff more functionality into an already overly

complex model.

The IN model begins manifesting itself as a telephony-centered cor-

set that resists the modeling of other types of communication and soft-

ware creation. Even during the specification of CS-4, the industry was

experimenting with new, alternative models for delivering value-added

services. Some analysts doubt whether CS-4 will ever make it into

products.

2.8.4 Beyond CS-4

It looks like CS-4 is the end of the line for IN standardization. The ITU has

not expressed any intentions to produce a CS-5 standard, no doubt a con-

sequence of the disappointing results of CS-3 and CS-4 standardization.

The Internet, mobile networks, liberalization of the markets, and

new programming technologies are challenging the IN concept. A sur-

prising number of ad hoc groups have sprung up in industry, not only to

try and solve technical problems but to push certain commercial and stra-

tegic interests. Examples of such industry groups and their initiatives are

as follows:

◗ JAIN, which promotes a Java framework for implementing value-

added services;

◗ Parlay, which produces interfaces for opening up network control to

third-party software;

◗ OSA, 3GPP, and ETSI’s proposed service architecture for third-

generation (3G) mobile networks;

◗ TINA, a complete telecommunications architecture built on distrib-

uted object-oriented middleware.

This book is dedicated to the forces that are shaping the next genera-

tion of network intelligence solutions, and in the chapters that follow we

will be taking a closer look at all of these new initiatives.


In spite of industry initiatives, IN is alive and kicking and will remain

that way for the foreseeable future. Although limited in scope to teleph-

ony, IN is a proven concept. No matter how many new industry groups

come up with new ideas, there does not appear to be a satisfactory alter-

native to IN, at least for good old telephony.

2.9 Implementing IN

So far we have been investigating the definition of IN as it appears in the

standards. But what do the products based on these standards actually

look like? How do Lucent, Alcatel, Ericsson, and other telecommunica-

tions manufacturers implement the IN standards? And is it possible to

connect an SSP from one manufacturer to an SCP from another?

In this section we will consider a practical example: the Alcatel IN

platform. The choice of Alcatel is arbitrary; we could have chosen any

other manufacturer’s product. The choice is simply motivated by the fact

that Alcatel’s product offer is complete, state-of-the-art, and typical of IN

products on the market.

2.9.1 Alcatel IN

Alcatel, like most manufacturers, does not have a single IN product, but a

line of products that can be configured into many different IN configura-

tions. Alcatel’s IN uses hardware and software that is commercially avail-

able from third parties: Compaq and Sun processors, Unix operating

system, and Oracle database.

An example Alcatel SCP configuration is shown in Figure 2.22. This

is a typical configuration sold to customers with high traffic require-

ments, although if necessary the SCP can be scaled up even further.

The Alcatel SCP can consist of several machines. A typical SCP con-

figuration consists of two front-end processors (FEPs) and two to four

back-end processors (BEPs). The FEPs are the machines that terminate

the SS7 connections and run the SS7 protocols. They are effectively SS7

signaling points.

The BEPs run the actual service software and can be considered the

heart of the SCP. The FEP-BEP configuration was chosen for three

reasons:

1. Performance. Separating the SS7 protocol processing from the serv-

ice processing gives the configuration better performance. The


FEPs can also balance the load between BEPs, thus avoiding the

possibility that the machines will become overloaded.

2. Scalability. If you need more processing power, you simply add a

BEP.

3. Reliability. The FEPs and BEPs are always paired for redundancy. If

a machine goes down, the other still guarantees that the system

continues functioning.

The FEPs and BEPs are interconnected by a fast Ethernet, which can also

be duplicated to ensure system reliability. The BEPs contain a database

that is kept completely in memory for reasons of performance. The data-

bases of the BEPs are synchronized periodically with a master database

on disk, which resides in the SMP. The BEPs can be synchronized

between each other by a memory channel, a fast connection that allows

memory to be shared among machines.


BEP BEP BEP BEP

FEP FEP

SS7 network

DB

Ethernet

Memory channel

Service control point

Figure 2.22 Alcatel SCP architecture.

When the IN platform is deployed, the SCPs are usually deployed in

mated pairs in hot switchover mode. In other words, if one of the two

SCPs goes down, the other automatically takes over. It is easy to imagine

that such an IN platform can become very costly: Each SCP can consist of

several physical machines plus software and infrastructure.

Alcatel offers a range of smaller configurations for different needs.

The Alcatel Service Node is intended for the smallest operators and con-

tains all the IN functions in a single physical box: The SSF, SCF, SMF,

SDF, and SRF are colocated in one physical node.

Alcatel also sells intermediate platforms in which the SCF, SMF, SDF,

and SRF are colocated in the same machine, but separate from the SSF.

Figure 2.22 corresponds to the full IN solution: SSF, SCF, SMF are all

separate machines.

These different configurations actually run the same software; they

differ only in processing power. It is possible to use the same services

developed, for example, for the service node and run them on the full IN

platform discussed above, and vice versa. This allows operators to grow

with their markets without having to reimplement services.

The Alcatel IN platform includes an SCE for producing service logic

programs from SIBs. Figure 2.23 shows a screen shot of this SCE: It offers

a palette of SIBs and a work area in which the service creator can drag

and drop SIBs and connect them together.


Figure 2.23 Screen shot of the Alcatel SCE.

The Alcatel SCE (A8695) currently includes more than 100 SIBs,

many more than the 14 specified in the CS-1 standard. Many of these

SIBs represent functionality that can be reused in different services (for

example, time- or origin-dependent routing), but for which no basic SIB

exists in CS-1. This strongly illustrates the need for HLSIBs (see Section

2.7.2) that can be composed from more elementary components.

Like many other manufacturers, Alcatel effectively splits the service-

creation function in two levels: service engineering and service customi-

zation. The screen shot shown in Figure 2.23 comes from the service

engineering tool: This tool is normally only used by skilled engineers who

know about the network. The service customization tool allows operators

to tune their services and can be used by nonspecialists. It lets the user

decide how to complete or filter a call depending on its origin, the dialed

number, date, and time, but it does not allow the creation of new serv-

ices. Alcatel calls this tool the light SCE.

Other manufacturers, such as Fujitsu, Ericsson, Lucent, Nec, Nokia,

Nortel, Siemens, Telcordia, and others, offer similar IN platforms. Most of

these share similar characteristics, especially when it comes to the SCE:

Most offer rich palettes of tens or even hundreds of SIBs. There is now

also a growing business of smaller manufacturers that build service nodes

and IN platforms, like Teligent (Sweden) and Comverse (the United

States).

Recently, Alcatel began using the name Open Service Platform (OSP)

for its IN product line, and the company is adding new components that

are not exclusively IN. An important extension is the Parlay-OSA6

gate-

way, which opens the platform to third-party service provisioning. This

move is typical (many other vendors are doing the same) and shows that

IN CS-3 and CS-4 have failed to keep up with the industry’s requirements.

2.9.2 Multivendor IN products

In theory it is possible to connect an SSP from one manufacturer (for

example, Lucent) that speaks standard INAP to an SCP from another

manufacturer (for example, Nokia). Unfortunately, in practice this is not

the case.

Although the syntax of INAP was unambiguously defined in the IN

standards, there was much confusion about how to interpret the mean-

ing of the different messages. Many manufacturers also tried to make


6. More about Parlay and OSA can be found in Chapter 5.

Documents

Contents Intelligent networks - Instytut …mareks/ute/in-zuidweg.pdfIntelligent networks As the majority of switches became digital in the 1980s, vendors and operators saw that, like