C-DOT IN

GENERAL DESCRIPTION

Section No. 404-005-0677

System
Practices

Draft 03, April 2000

C-DOT IN

GENERAL DESCRIPTION

2000, C-DOT
Printed in India

C-DOT IN
GENERAL DESCRIPTION

DRAFT 03
APRIL 2000
VAISHAKA 2057
SERIES 000 : OVERVIEW
CSP SECTION NO. 404-005-0677
THIS CDOT SYSTEM PRACTICE REFERS TO THE CDOT INTELLIGENT NETWORK
(ABBREVIATED AS C-DOT IN IN THE REST OF THIS PUBLICATION).

THE INFORMATION IN THIS SYSTEM PRACTICE IS FOR INFORMATION PURPOSES AND IS

SUBJECT TO CHANGE WITHOUT NOTICE.

A COMMENT FORM HAS BEEN INCLUDED AT THE END OF THIS PUBLICATION FOR
READER'S COMMENTS. IF THE FORM HAS BEEN USED, COMMENTS MAY BE ADDRESSED
TO THE DIRECTOR (SYSTEMS ), CENTRE FOR DEVELOPMENT OF TELEMATICS, 39, MAIN
PUSA ROAD, NEW DELHI - 110 005

2000 BY CDOT, NEW DELHI.

Table of Contents
Chapter 1.

Introduction .....................................................................................................................................5
1.1. Purpose & Scope.....................................................................................................................5
1.2. Organisation of Contents.......................................................................................................5
1.3. Overview of Intelligent Network Architecture ....................................................................6

Chapter 2.

SSP Architecture...........................................................................................................................14
2.1. Overview...............................................................................................................................14
2.2. C-DOT DSS MAX System Architecture .............................................................................14
2.3. C-DOT DSS MAX Software Architecture ...........................................................................17

Chapter 3.

SSP Functions & BCSM ...............................................................................................................24

3.1. Overview of SSP Functions .................................................................................................24
3.2. BASIC call State Model .......................................................................................................25

Chapter 4.

SCP Architecture ..........................................................................................................................43

4.1. Overview...............................................................................................................................43
4.2. System Architecture ............................................................................................................43
4.3. Hardware Architecture........................................................................................................43
4.4. Software Architecture..........................................................................................................51

Chapter 5.

SMP Architecture..........................................................................................................................54
5.1. Overview...............................................................................................................................54
5.2. Hardware and Software Architecture ................................................................................54

Chapter 6.

IN Services.....................................................................................................................................56
6.1. Overview...............................................................................................................................56
6.2. Freephone .............................................................................................................................57
6.3. Virtual Private Network (VPN) ..........................................................................................58
6.4. Virtual Card Calling (VCC).................................................................................................59
6.5. Account Card Calling (ACC) ...............................................................................................59
6.6. Universal Access Number (UAN) .......................................................................................59
6.7. Premium Rate (PRM) ..........................................................................................................60
6.8. Televoting (VOT)..................................................................................................................60

Chapter 7.

IN Call Information Flow .............................................................................................................61

7.1. Overview...............................................................................................................................61
7.2. Successful Freephone Local Call.........................................................................................61
7.3. Unsuccessful Freephone Local Call ....................................................................................62

Chapter 8.

SSP Administration ......................................................................................................................64

8.1. Overview...............................................................................................................................64
8.2. SSP Administration Commands .........................................................................................64
8.3. SSP Traffic Reports..............................................................................................................65

Chapter 9.

IN Subscriber Administration......................................................................................................68
9.1. Overview...............................................................................................................................68
9.2. SCP Administration Commands.........................................................................................68
9.3. SCP Traffic Reports .............................................................................................................72

H:\HOME\IN\WORD\INSSPGND.DOC

26 April, 2000

Chapter 1.

Introduction
1.1.

PURPOSE & SCOPE

The purpose of this document is to provide broad information on the C-DOT
Intelligent Network (IN) solution. This document would be useful to anyone
interested in Intelligent Networks in general and responsible for deploying C-DOT
IN solutions in particular. For technical persons involved in the design or testing
and validation of C-DOT IN, this document will be a good starting point for
understanding the implementation of various IN entities and the services.

1.2.

ORGANISATION OF CONTENTS
This document has nine chapters.
Chapter 1 is introductory and presents a brief overview of the Intelligent Network
concept and architecture.
Chapter 2 describes the Service Switching Point (SSP) architecture vis--vis the
C-DOT DSS MAX architecture.
In chapter 3, SSP functions and the IN basic call state model have been discussed.
Chapter 4 is on the Service Control Point (SCP) architecture.
Chapter 5 describes the Service Management Point (SMP) architectures and
functions.
In Chapter 6, IN services offered have been described in brief.
Chapter 7 illustrates information flows during an IN service call. For illustration, a
freephone service call has been described.
Lastly, in Chapters 8 & 9, operations and administrative interface in terms of manmachine commands and traffic reports of SSP and SCP respectively have been
briefly described.

GENERAL DESCRIPTION

Chapter 1

1.3.

OVERVIEW OF INTELLIGENT NETWORK ARCHITECTURE

Over the last thirty years one of the major changes in the implementation of Public
Switched Telephone Networks (PSTN) has been the migration from analogue to
digital switches. Coupled with this change has been the growth of intelligence in the
switching nodes. From a customers and network providers point of view this has
meant that new features could be offered and used.
Since the feature handling functionality was resident in the switches, the way in
which new features were introduced into the network was by introducing changes in
all the switches. This was time consuming and fraught with risk of malfunction
because of proprietary feature handling in the individual switches.
To overcome these constraints the Intelligent Network architecture was evolved
both as a network and service architecture.
In the IN architecture, the service logic and service control functions are taken out
of the individual switches and centralized in a special purpose computer. The
interface between the switches and the central computer is standardised. The
switches utilize the services of the specialized computer whenever a call involving a
service feature is to be handled. The call is switched according to the advice received
by the requesting switch from the computer. For normal call handling, the switches
do not have to communicate with the central computer.

1.3.1.

Objectives of the Intelligent Network

The main objectives of the IN are the introduction and modification of new
services in a manner which leads to substantial reduction in lead times and
hence development costs, and to introduce more complex network functions.
An objective of IN is also to allow the inclusion of the additional capabilities
and flexibility to facilitate the provisioning of services independent of the
underlying network's details. Service independence allows the service
providers to define their own services independent of the basic call handling
implementation of the network owner.
The key needs that are driving the implementation of IN are:

Rapid Service Deployment

Most businesses today require faster response from their suppliers,
including telecommunication operators. By separating the service logic
from the underlying switch call processing software, IN enables
operator to provide new services much more rapidly.

Reduced Deployment Risk

Prior to IN, the risk associated with the deployment of new services
was substantial. Major investments had to be made in developing the

C-DOT IN

INTRODUCTION

software for the services and then deploying them in all of the
switches.
With the service creation environment available, the IN services can be
prototyped, tested and accessed by multiple switches simultaneously.
The validated services can then be rolled out to other networks as well.

Cost Reduction
Because the IN services were designed from the beginning to be
reusable, many new services can be implemented by building on or
modifying an existing service. Reusability reduces the overall cost of
developing services. Also, IN is an architecture independent concept,
i.e. it allows a network operator to choose suitable development
hardware without having to redevelop a service in the event that the
network configuration changes.

Customization
Prior to IN, due to complexity of switch based feature handling
software, the considerable time frame required for service development
prevented the provider from easily going back to refine the service
after the customer started to use it. With IN, the process of modifying
the service or customization of service for a specific customer is much
less expensive and time consuming.
The customization of services is further facilitated by the integration of
advanced peripherals in the IN through standard interfaces. Facilities
such as voice response system, customized announcements and text to
speech converters lead to better call completion rate and userfriendliness of the services.

1.3.2.

IN Architecture
Building upon the discussion in the previous section, one can envisage that
an IN would consist of the following nodes:

Specialized computer system for - holding services logic, feature

control, service creation, customer data, and service management.

Switching nodes for basic call handling

Specialized resources node

The physical realization of the various nodes and the functions inherent in
them is flexible. This accrues from the "open" nature of IN interfaces.
Let us now look at the nodes that are actually to be found in an IN
implementation.

GENERAL DESCRIPTION

Chapter 1

The service logic is concentrated in a central node called the Service Control
Point (SCP).
The switch with basic call handling capability and modified call processing
model for querying the SCP is referred to as the Service Switching Point
(SSP).
Intelligent Peripheral (IP) is also a central node and contains specialized
resources required for IN service call handling. It connects the requested
resource towards a SSP upon the advice of the SCP.
Service Management Point (SMP) is the management node which manages
services logic, customers data and traffic and billing data. The concept of
SMP was introduced in order to prevent possible SCP malfunction due to onthe-fly service logic or customer data modification. These are first validated
at the SMP and then updated at the SCP during lean traffic hours. The user
interface to the SCP is thus via the SMP.
All the nodes communicate via standard interfaces at which protocols have
been defined by international standardization bodies. The distributed
functional architecture, which is evident from the above discussion, and the
underlying physical entities are best described in terms of layers or planes.
The following sections are dedicated to the discussion of the physical and
functional planes.
1.3.2.1.

Physical Plane
Service Switching Point (SSP)
The SSP serves as an access point for IN services. All IN service calls must
first be routed through the PSTN to the "nearest" SSP. The SSP identifies the
incoming call as an IN service call by analysing the initial digits (comprising
the "Service Key") dialled by the calling subscriber and launches a
Transaction Capabilities Application Part (TCAP) query to the SCP after
suspending further call processing. When a TCAP response is obtained from
the SCP containing advice for further call processing, SSP resumes call
processing.
The interface between the SCP and the SSP is G.703 digital trunk. The MTP,
SCCP, TCAP and INAP protocols of the CCS7 protocol stack are defined at
this interface
Service Control Point (SCP)
The SCP is a fault-tolerant online computer system. It communicates with
the SSP's and the IP for providing guidelines on handling IN service calls.
The physical interface to the SSP's is G.703 digital trunk. It communicates
with the IP via the requesting SSP for connecting specialized resources.

C-DOT IN

INTRODUCTION

SCP stores large amounts of data concerning the network, service logic, and
the IN customers. For this, secondary storage and I/O devices are supported.
For more details refer to the chapter on the "SCP Architecture".
As has been commented before, the service programs and the data at the SCP
are updated from the SMP.
Service Management Point (SMP)
The SMP, which is a computer system, is the front-end to the SCP and
provides the user interface. It is sometimes referred to as the Service
Management System (SMS). It updates the SCP with new data and programs
(service logic) and collects statistics from it. The SMP also enables the service
subscriber to control his own service parameters via a remote terminal
connected through dial-up connection or X.25 PSPDN. This modification is
filtered or validated by the network operator before replicating it on the SCP.
The SMP may contain the service creation environment as well. In that case
the new services are created and validated first on the SMP before
downloading to the SCP.
One SMP may be used to manage more than one SCP's.
Intelligent Peripheral (IP)
The IP provides enhanced services to all the SSP's in an IN under the control
of the SCP. It is centralized since it is more economical for several users to
share the specialized resources available in the IP which may be too
expensive to replicate in all the SSPs. The following are examples of
resources that may be provided by an IP:

Voice response system

Announcements

Voice mail boxes

Speech recognition system

Text-to-speech converters

The IP is switch based or is a specialized computer. It interfaces to the SSP's

via ISDN Primary Rate Interface or G.703 interface at which ISUP, INAP,
TCAP, SCCP and MTP protocols of the CCS7 protocol stack are defined.
The IN architecture is depicted in Fig. 1.1.

GENERAL DESCRIPTION

Chapter 1

SMP

DATA BASE
COMMUNICATION INTERFACE

X.25 OR ETHERNET

SCP
COMMUNICATION INTERFACE
PROGRAM INTERFACE

DATA BASE

COMMUNICATION INTERFACE

CCS7 NETWORK

IP

SSP

USER

USER

USER

USER

LEGEND :
SMP SCP SSP IP -

SERVICE MANAGEMENT POINT

SERVICE CONTROL POINT
SERVICE SWITCHING POINT
INTELLIGENT PERIPHERAL

FIG. 1.1
IN ARCHITECTURE
\DESIGN\SSP-GD\SSPGD-IN

10

C-DOT IN

INTRODUCTION

1.3.2.2.

Distributed Functional Plane

Functional model of IN contains nine functional entities (FE's) which are
distributed over various physical entities (PE's) described in the previous
section. A functional entity is a set of unique functions. Brief description of
the FE's is given below.
CCAF
Call Control Agent Function, gives users access to the network.
CCF
Call Control Function provides the basic facility for connecting the transport
(e.g. speech). It involves the basic switching function and trigger function for
handling the criteria relating to the use of IN.
SSF
Service Switching Function is used to switch calls based on the advice of the
SCF at the SCP. This function provides a service independent interface.
SCF
It contains the service logic components and advises the SSF at SSP on
further call handling.
SDF
Service Data Function contains the user related data and data internal to the
network.
SRF
Specialized Resources Function covers all types of specialized resources other
than the connection resources that are in the exchange. (e.g. recorded
announcements, tones, conference bridges, etc.).
SCEF
Service Creation Environment Function specifies, develops, tests and deploys
the services on the network.
SMAF
Service Management Access Function provides an interface between service
management function and the service manager who may be an operator.
SMF
Service Management Function enables a service to be deployed and used on
IN. Figure 1.2 depicts the distribution and interconnection of the various
function entities.

GENERAL DESCRIPTION

11

Chapter 1

SMAF

SMF
SCEF

SDF

SCF

SRF

SSF

CCAF

CCF

SSF

CCF

CCF

CCAF

Management Interface
IN Real Time Interface
Signalling Circuit Interface

Fig. 1.2 Distributed Functional Entities

12

C-DOT IN

INTRODUCTION

The distribution of functional entities over the physical entities and their
inter-connection is summarized in Tables 11 and 12 below. It may be noted
that all the physical entities may not be present in all IN's as the choice of
functional entities to be provisioned is entirely up to the service provider.
Table 1-1
Distribution of FE's over PE's
Physical Entity

Possible Functional Entities

SSP

CCF, SSF, CCAF

SCP

SCF, SDF

SMP

SCEF, SMF, SMAF

IP

SRF

Table 1-2
FE-FE Relationship to PE-PE Relationship
FE - FE

PE PE

Protocol

SSF-SCF

SSP-SCP

INAP, TCAP, SCCP

& MTP

SCF-SDF

SCP-SDP

X.25 or proprietary

SCF-SRF

SCP-IP

INAP, TCAP, SCCP,

& MTP

SCP-SSP-IP

ISUP, INAP, TCAP,

SCCP, & MTP

SSP-IP

ISUP & MTP

SRF-SSF

GENERAL DESCRIPTION

13

Chapter 2.

SSP Architecture
2.1.

OVERVIEW
The Service Switching Point (SSP) contains the following functionalities:
a.

Service Switching Function (SSF)

b.

Call Control and Call Control Agent Functions (CCF & CCAF)

Of the above, the SSF and CCAF are inherently present in a switching system.
Thus, the C-DOT DSS switches were chosen to be the platform for the SSP
implementation, the only additions being:
i.

CCS7 protocols, if not present already, for enabling the SSP-SCP interface.
For example, in a switch with ISUP call processing capability, additional
protocols such as SCCP, TCAP and INAP need to be added.

ii.

Call processing software for IN services' trigger processing (CCF), and

iii.

Administrative interface for IN services and additional CCS7 protocols. This

includes MML commands for creating, modifying and deleting data
concerning IN services, triggers, on-net VPN subscribers, and CCS7 entities.
Traffic reports on IN services and CCS7 entities are also provided.

In this chapter, for the sake of completeness, C-DOT DSS architecture has been
briefly described and relevant comments on the changes made for SSP working
have been included. These have been dealt with in detail in the subsequent
chapters.
2.2.

C-DOT DSS MAX SYSTEM ARCHITECTURE

C-DOT DSS MAX family of exchanges employ T-S-T switching architecture and can
be configured from four basic modules (Figure 2.1) :
a.
Base Module/Remote Base Module
b.
Central Module
c.
Administrative Module
d.
Input Output Module

14

C-DOT IN

SSP ARCHITECTURE

MDF

CM
BM 1

SUBSCRIBER LINES

ANALOG TRUNKS

DIGITAL TRUNKS

BM n
DIGITAL LINKS
FROM RSUs

ADP

AM

(I/O DEVICES)

IOM

DISK

TAPE

VDU

PRINTER

LEGEND :
BM CM AM IOM ADP MDF RSU n-

BASE MODULE
CENTRAL MODULE
ADMINISTRATIVE MODULE
INPUT OUTPUT MODULE
ALARM DISPLAY PANEL
MAIN DISTRIBUTION FRAME
REMOTE SWITCH UNIT
< 32

FIG. 2.1
C-DOT DSS MAX BASIC ARCHITECTURE
\DESIGN\SSP-GD\SSPGD-SA

GENERAL DESCRIPTION

15

Chapter 2.

The Base Module (BM)/Remote Base Module is the basic growth unit of the system.
It interfaces the external world to the switch and provides local resources such as
tones, announcements and terminal test facility. Presently, the Enhanced
Announcement Card (EAC) equipped per BM is being used for providing limited
Intelligent Peripheral (IP) functions to the SSP.
The interfaces may be subscriber lines, analog and digital trunks, CCB and PBX
lines and digital links from remote modules. Each Base Module can interface up to
2024 terminations. The number of Base Modules directly corresponds to the
exchange size. It carries out majority of call processing functions and, in a smallexchange application, also carries out operation and maintenance functions with the
help of the Input Output Module.
In the Single Base Module (SBM) exchange configuration, the Base Module acts as
an independent switching system and supports up to 1500 lines and 100 trunks. In
such a configuration, the Base Module directly interfaces with the Input Output
Module for bulk data storage and operations and maintenance functions. Clock and
synchronization is provided by a source within the Base Module.
The Central Module (CM) consists of a message switch and a space switch for intermodule communication and voice and data switching between Base Modules. It
provides control-message communication between any two Base Modules, and
between Base Modules and the Administrative Module for operation and
maintenance functions. It also provides clock and synchronization on a centralized
basis.
Administrative Module (AM) performs system-level resource allocation and
processing function on a centralized basis. It performs all the memory and time
intensive call processing support functions and also administration and
maintenance functions. It communicates with the Base Modules via the Central
Module. It supports the Input Output Module for providing man- machine interface.
It also supports an Alarm Display Panel (ADP) for the audio-visual indication of
faults in the system. In SBM configuration, ADP directly communicates with the
Base Processor.
CCS7 Signalling Unit Module (SUM) is based on duplicated 68010 or 68040
microprocessor and provides CCS7 signalling capability to the entire switch.
However, it resides in one of the BM's just like a terminal unit frame. This approach
makes it an easily retrofitable module.
The SUM provides up to 64 signalling terminals each of which can be configured as
internal message channels or external signalling links. The basic growth unit in the
SUM is the Signalling Handler Module (SHM) card which contains 8 signalling
terminals. The number of these cards to be equipped will depend upon the internal
and external connectivity requirements. Internally, the SUM communicates with
the BM's main processor for initializations and application processing. Externally,

16

C-DOT IN

SSP ARCHITECTURE

the SUM provides CCS7 network connectivity to other switching nodes, STPs and
SCPs.
Input Output Module (IOM) is a powerful duplex computer system that interfaces
various secondary storage devices like disk drives, cartridge tape drive and floppy
drive. It supports printers and upto 16 video display units that are used for manmachine communication interface. All the bulk data processing and storage is done
in this module.
Thus, a C-DOT DSS MAX exchange, depending upon its size and application, will
consist of Base Modules (maximum 32), Central Module, Administrative Module,
Signalling Unit Module, Input Output Module, and Alarm Display Panel. The Base
Modules can be remotely located or co-located depending on the requirement.
2.3.

C-DOT DSS MAX SOFTWARE ARCHITECTURE

The main subsystems of C-DOT DSS MAX software are briefly described below.
Their place in the overall software architecture is depicted in Fig. 2.2.

2.3.1.

C-DOT Real Time Operating System (CDOS)

The operating system is primarily responsible for the following functions and
services (Figure 2.3)
Management of Processes
Synchronization and Communication between Processes
Time Management
Interrupt Handling
Resource Management
Memory Management
On-line and Off-line Debugging Facility

2.3.2.

Peripheral Processor Subsystem

The software for handling line, trunk, and service circuits is resident as in
the Peripheral Processors. Presently, these are 8-bit microprocessors
programmed in assembly language. The main activity of the peripheral
software is to detect events and communicate them to the Base Processor,
where logical call handling is done. This subsystem also carries out the
commands given by the Base Processor for generating suitable telephony
events on the outgoing lines and trunks.

GENERAL DESCRIPTION

17

TE
M
APPLICATION SOFTWARE

E
AR
TW
F
O
**
\DESIGN\SSP-GD\SSPGD-ML

FIG. 2.2
C-DOT DSS MAX LAYERED SOFTWARE ARCHITECTURE

PERIPHERAL PROCESSOR SUBSYSTEM

** TERMINAL HANDLER SOFTWARE IS A PART OF THE

AND ADMINISTRATION SOFTWARE SUBSYSTEMS

R
LE
ND
HA

* APPLICATION SOFTWARE CONSISTS OF CALL PROCESSING, MAINTENANCE,

AP

LIC
AT
IO

O
F
TW
AR
E
O

L
NA
MI
R
TE

TIN
G

PE
RA

18
P
N

SY
S

AP
IO
AT
LIC

DATABASE MANAGER

HARDWARE

Chapter 2.

C-DOT IN

SSP ARCHITECTURE

MESSAGE I/O

PROCESS MANAGEMENT

PROCESS CO-ORDINATION

. SEND

. CREATE

. CREATE

. SET/RESET EVENT FLAG

. RECEIVE

. START

. START

. WAIT ON EVENT FLAG

. TERMINATE

. TERMINATE

. WAIT ON SEMAPHORE

MEMORY MANAGEMENT
. ALLOCATE

CDOS

DEBUGGING MONITOR

. DEALLOCATE

TIME MANAGEMENT

PERIPHERAL I/O
READ OS TABLES

. READ

. SET/CANCEL ALARM

. WRITE

. PAUSE/CANCEL PAUSE
. GET/SET TIME

FIGURE 2.3
OS SERVICES IN C-DOT DSS MAX
\DESIGN\SSP-GD\SSPGD-OI

GENERAL DESCRIPTION

19

Chapter 2.

2.3.3.

Call Processing Subsystem

The Call Processing software subsystem receives the information about
telephony events that occur outside the exchange. It processes this incoming
information and gives commands to the Peripheral Processors for
interconnecting subscribers through the switching network.
The Call Processing subsystem is divided into a number of eternal and
dynamic processes. The processing of a call is done on a `half-call basis', i.e.,
corresponding to an originating terminal, an Originating Terminal Process
(OTP) is created. Similarly, corresponding to a terminating terminal, a
Terminating Terminal Process (TTP) is created. To co-ordinate these two
processes, a Call Manager (CMR) is created on a `per-call basis'. Different
combinations of originating and terminating terminal processes enable the
system to handle local, outgoing, incoming, and transit calls. Figure 2.4
shows the processes involved in handling a call in a MAX configuration.
Feature handling decisions are taken at the Call. The call processing subsystem has been modified to accommodate trigger processing for IN service
calls. A new Basic Call State Model INBCSM has been included and is
described in detail in the next chapter.
Manager Level
Routing is handled by Global Routing and Resource Allocation Process
(GRRA) and path allocation is done by the Global Path Controller (GPC)
process.
In Single Base Module (SBM) configuration, GPC is not present. All access to
the data are made through Data Base Access Routines (DBARs).
A special feature of the Call Processing software subsystem is generation of
an exhaustive Call Event Record (CER) of every call. This Call Event Record
contains the complete detail of a call and is sent to the Administration
Software subsystem, at the termination of the call. The Administration
subsystem, in turn, processes the Call Event Records for extracting billing
and traffic related information in the form of reports. In case the call involves
a terminal under observation, a subscriber observation record is also
generated.

20

C-DOT IN

SSP ARCHITECTURE

*
GPC

GLOBAL ROUTING
&

GRRA

GLOBAL PATH
CONTROL

RESOURCE ALLOCATION

CALL MANAGER

OTP

CMR

ORIGINATING

TERMINATING

TERMINAL

TERMINAL

PROCESS

PROCESS

TTP

STATUS

SCP

CONTROL
PROCESS

PP

PERIPHERAL PROCESSORS

ORIGINATING

TERMINATING

LINE

LINE

ETERNAL PROCESS

PP

DYNAMIC PROCESS

GPC IS NOT REQUIRED IN SBM SYSTEMS.

GRRA DIRECTLY COMMUNICATES WITH TTP.

FIGURE 2.4
PROCESSES IN CALL PROCESSING SUBSYSTEM
\DESIGN\SSP-GD\SSPGD-CP

GENERAL DESCRIPTION

21

Chapter 2.

2.3.4.

Maintenance Subsystem
The Maintenance software subsystem is responsible for the following major
functions:
Initialisation
System integrity
Switch maintenance
Terminal maintenance
Human interface

2.3.5.

Administration Subsystem
Administration subsystem consists of traffic, billing, exchange performance
measurement, and human interface functions. It also provides on-line
software patching capability.
Administration subsystem is responsible for maintaining a large number of
traffic records on the basis of the information received by it through Call
Event Records and a large number of traffic-related commands. Similarly,
the Traffic and Exchange Measurement Process correlates a number of these
traffic records and generates reports on the overall exchange performance.
These reports are extremely useful in monitoring the health of the exchange
and for network planning.
Billing processes provide billing records and itemized/detailed billing
information for local and trunk calls. Detailed billing records for local calls
are provided for subscribers under observation. If the exchange is used as a
leading TAX, Centralized Automatic Message Accounting (CAMA) can be
easily incorporated, provided the signalling supports the required
information flow from the originating exchanges.
The exchange is connected with a number of VDUs for providing the human
interface. Man-machine communication is extremely user- friendly and
provides a large number of forms and menus for carrying out exchange
management functions. Over 200 man-machine commands are provided for
exchange operation, administration, and control.

2.3.6.

Database Subsystem
The management of global data, i.e., the data shared between various
applications and processes, is done by the Database subsystem.
Data is organised as global data structures and resource tables and the global
data is accessed via database access routines (DBARs). Global data
structures are maintained on terminal-related data (fixed office data and

22

C-DOT IN

SSP ARCHITECTURE

extended office data) and centralised routing and translation tables. In

addition, linked lists on free global and local resources and a reference
memory for unprotected terminal status data are maintained.
2.3.7.

Input Output Processor Subsystem

Input Output Processor (IOP) subsystem uses UNIX as the basic operating
system. IOP software subsystem is structured as a layer above UNIX and
comprises of the following parts :
Command Interpretation Layer : A topmost layer, like a shell, to
receive, validate, and execute operator commands
Administration Software : A layer above UNIX which provides the
man-machine interface.
Maintenance Software : Used for initialising communication protocol
with C-DOT DSS MAX. It also provides software for synchronization of
duplex Input Output Processor.
Communication Software : Used for providing connectivity to C-DOT
DSS MAX and network management centres.
The functions of IOP software subsystem in C-DOT DSS MAX are downloading and initialization, performance measurement of processes,
provision of man-machine interface, and handling billing, traffic, and
maintenance reports, etc.

GENERAL DESCRIPTION

23

Chapter 3.

SSP Functions & BCSM

3.1.

OVERVIEW OF SSP FUNCTIONS

This chapter provides an overview of the major functions of a SSP and how the IN
Basic Call State Model (BCSM) is used to achieve them. SSP basically comprises of
service switching and call control functionalities.
The major activities which constitute these functionalities are briefly described
below.
Call Processing
The SSP contains the basic call processing and processing required to determine IN
call and control the call flow as directed by the SCP. The SSP while communicating
with the SCP for more information suspends the call processing activity, if
necessary, and then resumes call processing on the basis of information received
from the SCP.
Trigger Processing
Trigger processing is the process of identifying calls that need IN service logic to be
invoked at the SCP. The SSP on detecting a trigger launches a query and suspends
the basic call processing. The call processing is resumed after getting the response
from the SCP. ITU-T has defined 18 trigger detection points (DP's) from where
query can be launched for handling Capability Set 1 (CS-1) services. Triggers have
been grouped into three categories : Subscribed, Office based and Group.
Call Gapping
When a trigger is detected and the trigger criteria are met, the SSP checks whether
Call Gapping is activated before communicating with the SCP. The call gapping
functionality is initiated at the SSP by the SCP in case of overload at the SCP.
Whenever this functionality is activated, SSP applies the final treatment to the call.
The final treatment involves clearing of the call.

24

C-DOT IN

SSP FUNCTIONS & BCSM

Feature Interaction
The existing switch has the logic for the basic services built into it while the service
logic for IN services is present in the SCP. The services that are present in the SSP
and the SCP might be same or different. The SSP has the functionality to
differentiate between the switch based features and IN trigger types. If there is a
contradiction between two features, the SSP resolves it. The switch based features
get priority over the IN services in case of interaction.
Trigger Activation & Deactivation
The SSP's capability to activate or deactivate triggers during the processing of the
call upon SCP's directive. A trigger type is required to be "armed" or "disarmed"
depending upon the service logic at the SCP.
Response Processing
The capability to receive and interpret the responses sent by the SCP. This can
include continuing with processing the call, redirecting the call, rerouting the call,
and notifying the SCP when the call terminates.
User Interaction
The capability to connect user with a resource (e.g., announcement) in the IP or
within the SSP itself. This is used to either provide or collect information to/from
the user.
Fault Handling
SSP has the functionality to apply fault treatment to the call on detecting an error
condition. The treatment can include clearing the call or routing the call to a default
number.
Resource Monitoring
The capability for monitoring the status of resources such as trunks and subscriber
lines as requested by the SCP.
3.2.

BASIC CALL STATE MODEL

This section describes the processing done by the SSP in order to complete a two
party call. The call model is the underlying functionality needed to provide IN based
services to the subscriber. The following terms are used to describe the call model:
End User
An addressable user in the network who employs analog (i.e., non-ISDN) access
signalling arrangement.

GENERAL DESCRIPTION

25

Chapter 3

Calling Party
The end user who originates the call.
Called Party
The end user who receives the call.
Originating Access
The path at the SSP towards the calling party. This can be an incoming ISUP
trunk, conventional (analog) trunk or analog subscriber line.
Terminating Access
The path at the SSP towards the called party. This can be an outgoing ISUP trunk,
conventional trunk or analog subscriber line.
Originating Half Call Segment
A logical representation within the SSP of that part of the call which connects to the
originating access and is associated with the call setup, conversation and release
phases.
Terminating Half Call Segment
A logical representation within the SSP of that part of the call which connects to the
terminating access and is associated with the call termination, conversation and
release phases.
The SSP call model is viewed as two blocks. One is the originating half call segment
and the other is the terminating half call segment. The originating half call segment
is the O-BCSM, i.e. the Originating Basic Call State Model, and the terminating
half call segment is the T-BCSM, i.e. the Terminating Basic Call State Model.
Every call within a SSP comprises of the originating and terminating BCSMs. The
O-BCSM and T-BCSM can be independently influenced and possess respective
Originating and terminating features.
For processing of a call, i.e. establishing, connecting, maintaining and releasing the
call, call processing points are represented by Points In Call (PICs) and Detection
Points (DPs) which are identified between the PICs. DP's identify when a query
can be launched towards the SCP. A Trigger Detection Point (TDP) is the DP where
a trigger can be detected, and, Event Detection Point (EDP) is the DP where an
event requested from the SCP can be detected.
3.2.1.

Originating Basic Call State Model (O-BCSM)

This section describes the Points In Call (PIC's) and DPs which come under
the purview of originating portion of the call. Figure 3.1 shows the
originating basic call state model.

26

C-DOT IN

SSP FUNCTIONS & BCSM

The originating portion of the call comprises 6 PICs and 10 DPs. The PICs
are :
1.

O_Null and Authorize_Origination_Attempt

2.

Collect_Information

3.

Analyze_Information

4.

Routing and Alerting

5.

O_Active

6.

O_Exception

The DPs are :

1.

Origination_Attempt_Authorised

2.

Collected_Information

3.

Analysed_information

4.

Route_Select_Failure

5.

O_Called_Party_Busy

6.

O_No_Answer

7.

O_Answer

8.

O_Mid_Call

9.

O_Disconnect

10.

O_Abandon.

The PIC's are described in the following paragraphs in terms of:

Entry Event: The events in call that cause initiation of the PIC.
Action : The processing done in that PIC.
Exit Event: The events that signify the completion of processing to be done
in that PIC (success and failure cases), and, the information available at the
exit of this PIC.

GENERAL DESCRIPTION

27

Chapter 3

1. O_NULL & AUTHORIZE ORIGINATION_ATTEMPT

10

6. O_EXCEPTION

O_ABANDON
1

ORIG. ATTEMPT_AUTHORIZED

2. COLLECT_INFO.

COLLECTED_INFO.

3. ANALYSE_INFO.

ANALYSED_INFO.
4

4. ROUTING & ALERTING

ROUTE_SELECT_FAILURE

5
7

O_ANSWER

5. O_ACTIVE

O_CALL_PARTY_BUSY

6
O_NO_ANSWER

O_DISCONNECT

T1136230-91/D05

8
O_MID_CALL

TRANSITION

DETECTION POINT (DP)

POINT IN CALL (PIC)

FIG. 3.1
ORIGINATING BCSM FOR CS-1
\DESIGN\SSP-GD\SSPGD-OG

28

C-DOT IN

SSP FUNCTIONS & BCSM

3.2.1.1.

O_Null and Authorise_Origination_Attempt

This is the first PIC encountered in the originating BCSM.
Entry Event
Origination attempt event, disconnection, clearing or exceptional handling of
a call. Based on the access type the origination attempt can be :

off-hook indication from an idle subscriber line,

seizure signal on a conventional trunk, or

Initial Address Message (IAM) on an ISUP trunk.

Action
When an origination attempt is detected, SSP verifies the authority of the
user to place a call with the given attributes. The authorization may vary
depending on the originating resource (i.e. line or trunk).
Exit Event
The SSP call model exits this PIC under the following conditions :

The user is authorized to make a call.

The user is not authorized, and hence denied permission to make the
call.

The user abandons the call, i.e., on-hook signal is received on the
subscriber line, clear forward indication is received on a conventional
trunk, or Release (REL) message is received on an ISUP trunk.

At the exit point of this PIC the following information is available:

Charge Number
The directory number of the party to be charged. This information is
available for subscriber line and ISUP trunk but not for conventional trunk.
Calling Party ID
The network address of the calling party. This information is also available
for subscriber line and ISUP trunk not for conventional trunk. In case of MF
signalling, the address is made available by the originating exchange if
explicitly demanded by the SSP.
Bearer Capability
The bearer capability is included in the received Initial Address Message
(IAM), else the default bearer capability is assumed.

GENERAL DESCRIPTION

29

Chapter 3

Terminal Type
This information is available in case of a subscriber line. It provides
information about the kind of instrument, i.e. dial pulse, DTMF, ISDN or
unknown.
Trunk Group Number
This is the SSP identifier for the incoming trunk group containing the seized
trunk. This information is available for conventional as well as ISUP trunks.
Trunk Circuit ID
This is the SSP identifier for the incoming trunk circuit seized. This
information is available for conventional as well as ISUP trunks.
Calling Party Sub-address
This information is present only in case of ISUP trunks.
Other Feature Related Information
The features which the subscriber line can invoke. In the case of ISUP trunk,
the information received in the IAM message is available at this PIC.
3.2.1.2.

Collect_Information
This is the second PIC in the originating BCSM.
Entry Event
Indication of desire to place an outgoing call and the authority/ability to place
the call verified. DP1, i.e. Origination_Attempt_Authorised, is present.
Action
In this PIC enough information is collected from the originating access to
process the call. This information is collected according to the dialling plan
assigned to the originating access. If customized dialling plan is assigned to
the originating access then that plan is assigned.
If the call is initiated from a subscriber line then dial tone is fed to the
subscriber and a digit receiver is attached (in case the subscriber is dialling
DTMF phone) and a timer for collection of digits started.
If the call initiation is received for a conventional trunk then a start signal
might be sent in the backward direction except for decadic trunks. A digit
receiver if required is attached and timer for collection of digits is started.
For an ISUP call with overlap signalling the digits are received in IAM and
SAM messages. If enbloc signalling is being used then all the digits are
received in the IAM message.

30

C-DOT IN

SSP FUNCTIONS & BCSM

After this, the SSP waits for a minimum number of digits (min_sub_dials)
before it finds out the total number of digits expected. After minimum
number of digits have been collected, preliminary analysis is done to find out
the remaining number of digits expected by using the information available
at the trigger criteria table for this particular O_BCSM and information
available at the switch.
If this information is not available in the trigger table, normal procedure for
finding out the remaining digits is applied. This includes matching the digits
received with the feature codes, level 1 service codes and exchange
codes/routing tables. In case the starting digit is zero then open numbering
scheme is followed.
If Collected_Information DP is armed then the SSP waits for all the digits to
be received in this PIC.
Exit Event
If Collected_Information DP is not armed, the Collected_Information PIC exit
event might be encountered when minimum digits required for doing the
preliminary analysis to find out the remaining number of digits expected
have been received.
If the Collected_Information DP is armed then this PIC is exited only after
collecting all the digits.
If Collected_Information DP is not armed then there is some parallelism done
between this PIC and the Analyse_Information PIC. After finding out the
digits expected, this exit event is encountered. In this case though the
Collected_Information DP is hit, still the Collect_Information PIC continues
to collect the digits and pass them on to the next PIC.
The exit event can also be due to collect timeout, collect information failure,
invalid information or abandon event. The first three reasons result in
transition to O_Exception PIC and the last one into O_Abandon.
The information available at the exit point of this PIC comprises all the
information that was available at DP1 and charge number, called party
number, Original Called Party ID, Redirection Information, Feature Code,
Access Code (for customized numbering plans), and carrier ID available at
DP2, i.e. Collected_Information.
3.2.1.3.

Analyse_Information
This is the third PIC in the originating BCSM.

GENERAL DESCRIPTION

31

Chapter 3

Entry Event
Availability of complete initial information from the originating party or
minimum digits required to find out the number of digits expected. At this
point, DP2 i.e. Collected_Information is present.
Action
In this PIC, the SSP analyses the information collected according to the
specified numbering plan for the purpose of determining the routing address
and call type (i.e. local, STD/ISD call, etc.).
After the minimum digits have been received and if DP3 is armed, then these
digits are matched with the trigger criterias assigned at this DP3.
If the digits received match one of the trigger criteria and the minimum
number of digits required to launch a query are available, then a query is
launched towards the SCP. The SSP suspends call processing and waits for
the response from the SCP.
If the trigger criterion is not satisfied or DP3 is not armed, then the SSP exits
this PIC.
Exit Event
The call model transits from this PIC into the next PIC under the following
conditions:

Availability of routing address and call type (As a result of the

response from the SCP )

Origination party abandons the call.

Unable to analyse information and translate the dialled digits

according to the dialling plan

Information Available
Before entering this PIC, the charge number (in case of line and CCS7 trunk),
calling party number, class of service, bearer capability, trunk circuit ID (in
case originating access is trunk), trunk group number (in case originating
access is a trunk), calling party subaddress, redirecting party ID, redirection
information, feature code, and access code are already available and thus is
available at the exit point of the PIC also.
As a result of processing in this PIC, the following extra information is
available at the exit point :

32

C-DOT IN

SSP FUNCTIONS & BCSM

In case of subscriber line:

Called party ID
Numbering Plan of the address
Type of the call
Carrier
Carrier selection
Collected information
Route list
In case of conventional and ISUP trunk:
Called Party ID
Numbering plan of the address
Call type
Carrier
Carrier Selection
Route List
3.2.1.4.

Routing and Alerting

This PIC is the fourth PIC in the originating BCSM.
Entry Event
Availability of routing address
Analysed_Information DP is present.

and

call

type.

At

this

point,

Action
In this PIC, SSP shall select the line or outgoing trunk group based on the
results of the processing in PIC 3 i.e. Analyze_Information. This involves
routing the call to a directory number or translating route code to trunk
group. SSP verifies the authority of caller to place the call before selecting the
route.
If the trunk group selected for the call is busy at SSP, then SSP shall attempt
to route the call on the next trunk group, if specified in the information
available after PIC3.
For subscriber line and conventional trunk, if overlap signalling is used, SSP
continues to collect the information.
If the caller is authorized to place the call, then SSP sends an indication to
set up a call to the specified called party number to the terminating BCSM.
GENERAL DESCRIPTION

33

Chapter 3

SSP sends the following information to terminating BCSM in case of an ISUP

trunk :
Charge Number,
Calling Party Number,
Bearer Capability,
Carrier,
Carrier Selection,
Route List,
Original Called Party In,
Redirect Party Id,
Redirection Information.
After the information is sent to the terminating BCSM, SSP shall wait for the
terminating party to answer. At this point, the caller receives inband audible
ringing (from the terminating switch) In case of SS7 trunk, SSP sends the
Address Complete Message when it finds the terminating party is free. In
case of conventional trunk supporting MF signalling, SSP sends signal
indicating that the called subscriber is free in the backward direction.
Exit Event
The exit events from this PIC are :
Indication from the terminating BCSM that the call is accepted and
answered by terminating party. In case of conventional trunk, an ANSWER
signal and in case of CCS7 trunk, an ANM or CONNECT message will be
the exit event.
When the SSP is unable to select route or encounters busy route while
routing the call, then the SSP encounters Route_Select_Failure DP. If this
DP is armed, then the SSP continues to give routing tone to the originating
subscriber and launch a query to SCP for further call processing guidance. In
case then DP is not armed, then there shall be a transition to O_Exception
PIC.
When O_BCSM gets an indication from the terminating BCSM that
terminating party is busy, then the SSP encounters O_Called_Party_Busy
DP. If this DP is armed, then the SSP shall not give busy indication to the
originating subscriber and launch a query to the SCP for further call
processing guidance.
When O_BCSM gets an indication from the terminating BCSM that
terminating party is busy and the O_Called_Party_Busy DP is not armed,
then it shall result into transition to O_Exception. In case of subscriber line
34

C-DOT IN

SSP FUNCTIONS & BCSM

or conventional trunk, busy tone shall be fed to the originating access from
the SSP. In case of CCS7 supported trunk, an ACM shall be sent in the
backward direction and busy tone shall be fed.
When the termination party does not answer within a specified period of time
after alerting and O_No_Answer DP is armed, then the SSP encounter this
DP. In this case, the SSP continues to give ring back tone to the originating
subscriber and launch a query to the SCP for further call processing
guidance. In case the DP is not armed, then there shall be transition to
O_Exception PIC.
When originating party abandons the call and O_Abandon DP is armed, then
the SSP encounters this DP and launch query to the SCP for further call
processing logic. If this DP is not armed, then the SSP shall transit to O_Null
and Authorise Origination Attempt PIC.
At the exit point of this PIC following information is available :
Since there are multiple exit points in this PIC, the number of DPs at the
exit is 5. These are 1. Route_Select_failure
2. O_Called_Party_busy
3. O_No_Answer
4. O_Answer
5. O_Abandon
All of the information that is available at DP3 is also available for these DPs.
After the processing of this PIC in case of exiting to O_Exception via DP4 i.e.
Route_Select_failure, the following additional information is available.
Failure cause indicating the cause for interface related information.
After the processing of this PIC in case of exiting to O_Exception via DP5 i.e.
O_Called_Party_Busy, the following additional information is available.
Busy cause indicates the cause for interface related information.
Interactions with terminating BCSM :
At this PIC the interaction with the terminating half of the call model starts.
During this PIC, an indication to place a call is passed to the terminating
BCSM. This indication is received as a termination attempt by the
terminating BCSM in the T_Null and Authorize_Termination_Attempt PIC.

GENERAL DESCRIPTION

35

Chapter 3

When the origination party disconnects the call, a release event is sent to the
terminating portion of the BCSM.
If the terminating party is busy, O_Called_Party_Busy is received. by the
O_BCSM..
During Routing phase, O-BCSM gets a call progressing indication (CPG) from
terminating BCSM in case the originating access is a SS7 supported trunk
and call is outgoing from SSP.
During the alerting phase, O_BCSM gets Address Complete Message (ACM)
from terminating BCSM in case the originating access is a CCS7 trunk.
When the called party answers, the terminating BCSM shall indicate by
sending an answer (ANM) indication which maps to O_Answer DP.
When the called party does not answer within a specific time period, then No
Answer indication is sent from terminating BCSM which maps to
O_No_Answer DP in the originating BCSM. If the originating BCSM does not
get indication from the terminating BCSM of the no answer event, then this
DP shall be encountered after no answer timeout in the originating BCSM.
3.2.1.5.

O_Active
This is the fifth PIC in the originating BCSM.
Entry Event
Indication from the terminating BCSM that the call is accepted and
answered by terminating party. At this point, O_Answer DP is present.
Action
In this PIC, connection is established between the originating and
terminating portion of the call. The complete message accounting and
charging data is collected in this PIC. If needed, call supervision is also
provided.
Exit Event
A service/service feature request is received from the terminating party (e.g.
DTMF, hook flash). In this case, the O_Midcall DP is encountered. Since IN
CS1 is currently not supporting any service from O_Midcall DP, the SSP
continues with normal processing of this event (i.e. flash).
A "disconnect" indication from a subscriber line, Release (REL) message on
ISUP trunk or termination indication on conventional trunk can be received
by the originating BCSM resulting in encountering O_Disconnect DP. If
O_Disconnect DP is not armed, then it transits to O_Null and
Authorise_Origination_Attempt PIC.

36

C-DOT IN

SSP FUNCTIONS & BCSM

If a connection failure occurs, then model transits to O_Exception.

In this PIC same information is available as in PIC 4.
3.2.1.6.

O_Exception
This is the PIC number 6 in the originating BCSM.
Entry Event
An exception condition is encountered as mentioned in the above PICs
description.
Action
If relationship exists between the SSP and the SCP, then the SSP sends an
Error information to SCP closing the relationship and indicating that any
outstanding call handling instructions shall not run to completion.
If the SCP had earlier requested for some reports, then these reports will be
sent to the SCP by SSP
All the resources allocated for the purposes of call are released and made
available for other calls.
Exit Event
After taking the appropriate action in the PIC the model shall transit to
O_Null and O_Authorise_Attempt PIC.

3.2.2.

Terminating Basic Call State Model (T-BCSM)

This section describes the Points In Call (PIC's) and Detection Points (DPs)
which come under the purview of terminating portion of the call. Figure 3.2
depicts the terminating basic all state model (BCSM).
The terminating portion of the call comprises 5 PICs and 7 DPs. The PICs
are:
1.
2.
3.
4.
5.

T-Null and authorise termination attempt.

Select_facility and present call
T_Altering
T_Active
T_Exception.

The DPs are:

1. Termination_Attempt_Authorised
2. T_Called_Party_Busy

GENERAL DESCRIPTION

37

Chapter 3

T_ABANDON
11. T_EXCEPTION

7. T_NULL & AUTHORIZE TERMINATION_ATTEMPT

18
TERM._ATTEMPT_AUTHORIZED

13

12

8. SELECT_FACILITY & PRESENT_CALL

T_CALLED_PARTY_BUSY

9. T_ALERTING

14
T_NO_ANSWER

15

T_ANSWER

17

10. T_ACTIVE

T_DISCONNECT

16

T1136240-91/D06

T_MID_CALL

TRANSITION

DETECTION POINT (DP)

POINT IN CALL (PIC)

FIG. 3.2
TERMINATING BCSM FOR CS-1
\DESIGN\SSP-GD\SSPGD-TM

38

C-DOT IN

SSP FUNCTIONS & BCSM

3. T_No_Answer
4. T_Answer
5. T_Mid_Call
6. T_Disconnect
7. T_Abandon
The PIC's are described in the following paragraphs.
3.2.2.1.

T_Null and Authorise_Termination_Attempt

This is the first PIC in the terminating BCSM.
Entry Event
Disconnection and clearing of previous call, or default handling of exceptions
by the SSP/SCP completed.
Action
When a termination attempt is made on a subscriber line, conventional trunk
or ISUP trunk then in this PIC SSP verifies the authority to place the call on
the terminating end (e.g. restricted incoming access to line).
Exit Event
The call model transits this state in the case of following events:

Indication of incoming call received from originating BCSM and

authority to place the call on a specified terminating resource is
verified. The call is allowed to be completed.

Indication of incoming call is received from originating half BCSM but

the authority to place the call on specified terminating resource is
denied. This case shall then be treated as exception and the call
handled according to exception processing procedures defined.

A release event is received from the originating BCSM. In this case the
model remains in this PIC and releases all the resources.

The following information is sent by the O_BCSM to the T_BCSM and is

available at the end of this PIC:

Charge number

Called party number

Calling party number

Bearer capability

Carrier ID

GENERAL DESCRIPTION

39

Chapter 3

3.2.2.2.

Route index

Original called party ID

Redirecting party ID

Redirection information

Select_Facility and Present_Call

This is the second PIC in the terminating BCSM
Entry Event
Indication of incoming call received from the originating BCSM and authority
to place the call verified. At this point, Term_Attempt_Authorised DP is
present.
Action
A free resource in the specified resource group is selected. It is possible that
all resources in that group may be busy. A single resource is treated as a
group of size one.
SSP informs the terminating resources of the incoming call. In case of
subscriber line, ringing tone is applied.
Exit Event
Terminating party is alerted. In this case the model transits to T_Altering
PIC.
When all resources in a group are busy and the T_Busy DP is armed, then
T_BCSM does not give any busy indication to the O_BCSM and launches a
query to the SCP for further call processing. In case the T_Busy DP is not
armed, T_BCSM indicates to O_BCSM and transit to T_Exception PIC.
When the subscriber answers the call and the T_Answer DP is armed then
T_BCSM launches a query to the SCP for advice on further call processing, if
required. In case the T_Answer DP is not armed, the T_BCSM transits to
T_Active PIC directly.
The following information is available at the end of this PIC in addition to
the information coming from T_Null and Termination_Attempt_Authorised
PIC's :

40

Facility Group - The identity of the trunk group number of hunt group
ID on which the call is landing.

Facility Group Member - The identity of the trunk circuit ID or the

member within the hunt group.

C-DOT IN

SSP FUNCTIONS & BCSM

3.2.2.3.

T_Altering
This is the third PIC in the terminating BCSM
Entry Event
Terminating party is being alerted of the incoming call.
Action
An indication is sent to the originating BCSM that the terminating party is
being alerted and waiting for the terminating party to answer the call. The
ringing timer is started for purposes of detecting ringing period time_out.
Exit Event
When the subscriber answers the call and T_Answer DP is armed, then SSP
launches a query to SCP for further call processing logic. In case the
T_Answer DP is not armed, SSP shall transit to T_Active PIC directly.
When the subscriber does not answers within the specified period of time and
T_Noanswer DP is armed, then the terminating BCSM does not send this
indication to the originating BCSM and launches a query to the SCP for
advice on further call processing. In case T_Noanswer DP is not armed, then
the terminating BCSM gives this indication to the originating BCSM and
transits to the T_Exception PIC.
The same information is available at the exit point of this PIC as in the case
of Select_Facility and Present_Call PIC

3.2.2.4.

T_Active
This is the fourth PIC in the terminating BCSM
Entry Event
Call is accepted by the terminating party by going off-hook. At this point,
T_Active DP is present.
Action
An indication is sent to the originating BCSM that the terminating party has
accepted and answered the call. Connection is established between the
originating and the termination partly.
Exit Event
A service/service feature request is received from the terminating party in the
form of DTMF digits or hook switch flash. In this case, the T_Midcall DP is
encountered. Since IN CS1 is currently not supporting any service from
T_Midcall DP, SSP does normal processing of this event.

GENERAL DESCRIPTION

41

Chapter 3

When a disconnect indication is received from the terminating party (i.e. onhook) then a timer is started within which, if the terminating party again
goes off-hook, the call is not disconnected. If the terminating party does not
go off-hook again within the specified time period and T_Disconnect DP is
armed, then SSP launches a query to the SCP for advice on further call
processing. In case T_Disconnect DP is not armed, then terminating BCSM
transits to T_Null and Authorise_Termination_Attempt PIC and all the
resources associated with the call are released.
When a disconnect indication is received from the originating party via
originating BCSM and T_Disconnect DP is armed, then the SSP shall launch
a query to the SCP for further call processing. In case T_Disconnect DP is not
armed then the terminating BCSM transits to T_Null and
Authorise_Termination_Attempt PIC and all the resources associated with
the call are released.
If a connection failure occurs then the terminating BCSM transits to the
T_Exception PIC.
Same information as in the case of the T_Alerting PIC is available at the exit
point of this PIC.
3.2.2.5.

T_Exception
This is the PIC number 5 in the terminating BCSM.
Entry Event
An exception condition is encountered as mentioned in the entry event of the
T_Alerting PIC.
Action
If any relation exists between the SSP and the SCP, the SSP sends an Error
information flow to the SCP closing the relationship and indicating that any
outstanding call handling instructions will not run to completion.
If the SCP had earlier requested some reports, then these reports are sent.
All the resources allocated for the purposes of call are released and made
available for other calls.

42

C-DOT IN

Chapter 4.

SCP Architecture
4.1.

OVERVIEW
Within the IN architecture, SCP is a central online computer system which
communicates with one or more SSPs via the CCS7 network. It allocates resources
for performing application processing, CCS7 signalling message processing, node
management and fault management. The SCP contains all the service logic
programs to respond to queries from the SSPs.
SCP also supports the SCE, i.e. the Service Creation Environment in which new
services can be developed and tested before final deployment. The SCP needs a
database for its service logic programs. The SCE and the database can be a separate
physical entities or be present within the SCP platform.

4.2.
4.2.1.

SYSTEM ARCHITECTURE
System Overview
C-DOT SCP is developed on a continuously available hardware platform and
supporting software. The system features a CPU/memory architecture based
on the Hewlett Packard PA-RISC HP7100 microprocessor and a fault tolerant
system bus known as Golf bus.
All the controller boards are duplexed and communicate with each other
through the Golf bus. In addition, there are SCSI devices and I/O boards for
providing secondary storage, ethernet connectivity and CCS7 network
connectivity.
The software platform consists of SVR4 compliant FTX operating system and
an application platform.
The hardware and software architectures of the SCP are described in detail
in the following sections.

4.3.

HARDWARE ARCHITECTURE
C-DOT SCP is built around a fault tolerant computer system. The main operating
system is UNIX.

GENERAL DESCRIPTION

43

Chapter 4

The main controller unit is based on Hewlett-Packard PA-RISC HP7100 series

microprocessor. All the controller units are interconnected through a fault tolerant
Golf Bus. The major system components include

CPU boards with memory and cache

Basic I/O (BIO) boards

Peace Keeping I/O (PKIO) processor boards

The CPU/memory and PKIO boards are lockstepped in pair-and-spare architecture.

The BIO boards run partnered but not in lockstep. The primary board is active and
its partner is in standby mode. The BIO provides four dual initiator SCSI interfaces
and an Ethernet connection. The maintenance interface is on a small board called
the Remote Console Controller (ReCC) and contains the calendar card, serial ports
for console, RSN, and remote console.
Figure 4.1 depicts the SCP hardware architecture. Each hardware unit is described
in detail in the following sections.
4.3.1.

CPU/Memory Board
The CPU/Memory board consists of HP PA-RISC 7100 microprocessor with
separate instruction and data caches, and memory modules.
The CPU/Memory boards have globally accessible memory located on small
daughter boards, called memory modules. This new architecture improves
system performance by reducing system-bus traffic and decreasing memory
access time by 25% over conventional CPU/memory architectures.
Each CPU/memory board has one pair of self-checking PA-RISC HP7100
chips. Both boards have 256MB of onboard configurable memory.
SCP CPU/memory boards run lock-stepped in pair-and-partner fault tolerant
design. Thus, if one CPU/memory board fails, its partner continues
processing.

4.3.2.

PKIO Board
The K600 "Peace Keeping" I/O Processor (PKIO), manages I/O operations to
peripheral devices and I/O adapters. It provides the interface between the
system bus and two 8-bit I/O buses.
The PKIO board (K600) has a 48Mhz, 68030 Motorala microprocessor. The
other major components on the board are flash EEPROM and 4 Mbyte
DRAM. The EEPROM contains the PKIO firmware.

44

C-DOT IN

SCP ARCHITECTURE

Console
controller
Console CC1
controller
CC0

Maintenance & Diagnostics

Consoles
RSN

CPU/Memory
Slot 1

CPU/Memory
Slot 0

K600
Communication
I/O processors
Slot 4

K600
Communication
I/O processors
Slot 5

K460
SCSI/Ethernet
I/O controller
Slot 2

K460
SCSI/Ethernet
I/O controller
Slot 3
Fault Tolerant
System Bus

SCSI Disk
Drives and
Tape Drive

IOA Chassis

PK Terminator

X.21 Interface

E1 Interface

Figure 4.1
C-DOT SCP System Block Diagram (Logical Connectivity)

GENERAL DESCRIPTION

45

Chapter 4

4.3.3.

BIO Board
The BIO (Basic I/O) board, also called the SCSI/Ethernet Controller (K460),
provides a high speed interface between the system bus and the external I/O
devices like Ethernet and SCSI. BIO supports four wide, fast differential
SCSI buses, Ethernet and the four serial ports (RS-485) used for
communications with the disk/tape subsystem. The four SCSI management
serial ports provide a path to acquire disk and system status information
from the RS-485 bus handler, which is used by FTX maintenance and
diagnostics.
The BIO board supports connections to 10 or 100 Mbps Ethernet LANs. To
handle the 10Mbps connection, the I/O controller observes the IEEE 802.3
10Base-T standard and to handle the 100Mbps connection it observes the
100Base-TX standard.
The I/O Controller includes an internal transceiver and an UTP cable. The
UTP cable, which is 6 meters in length, connects the I/O controller directly to
an Ethernet hub. The cable connects to the I/O controller via a 41-pin female
connector. It connects to an Ethernet hub via a RJ-45 connector.
To ensure interoperability between the 10Base-T and 100Base-TX Ethernet
LANs, the I/O controller participates in a process that determines the optimal
line-speed and duplex setting at which the I/O controller can communicate
with other Ethernet stations. This process is known as "auto negotiation".

4.3.4.

Disk/Tape Subsystem
FTX supports disk and tape storage devices controlled by the differential
SCSI/Ethernet Controller (BIO). The PKIO Controller only supports
communication devices. Disk and tape devices are housed in the Disk/Tape
subsystem. Each SCSI bus coming from the I/O controller is typically
connected to a disk/tape subsystem enclosure and provides plug in slots for
SCSI disk and tape devices, redundant power controllers, RS485 bus, and
SCSI connectors for attaching to other (open) SCSI devices. The RS485 bus
reports unsolicited events such as "hot plugging" devices.

4.3.4.1.

Disk Drive
The disk drives are 3.5 inch models that combine high performance with high
reliability. Each disk drive occupies one slot in the disk/tape subsystem. Each
disk drives of the (max.) four has storage capacity of 2.1GB and rotational
speed of 7200 RPM.

46

C-DOT IN

SCP ARCHITECTURE

4.3.4.2.

Tape Drive
The SCP has one tape drive which combines rapid data transfer with high
capacity data storage in a 4-mm, 3.5inch Digital Audio Tape (DAT). Each
tape drive occupies three slots in the disk/tape subsystem. The disk/tape
doubles the storage capacity through the use of Digital Data Storage-Data
Compression (DDS-DC) on DDS-certified tapes. This superior storage
capability is based on a helical scan method that records data at a diagonal
rather than across the tape as with traditional tape drives.
The tape drive can transfer 360 to 430 KB of data per second, and can back
up 8GB of data in 2 hours. The average data search speed is of 30 seconds for
120-meter tape, and can achieve a tape speed of 15.5 mm per second.

4.3.5.

Golfbus
The Golfbus is 64 bits wide for inter-CPU communication, but only 32 bits of
the bus extend to the I/O slots. The peak bandwidth for the Golfbus is 128
Mbytes/sec for communication between CPUs and 77 Mbytes/sec for I/O.
The Golfbus and Golfbus interfaces perform two major functions:
i.

They supply a means to transfer information between Golfbus based

boards.

ii.

They provide fault detection and isolation for the Golfbus and the
Golfbus resident boards.

The Golfbus provides self-checking through three-way voting of control

signals and arbitration lines. This allows the system to be protected against a
single control signal or arbitration line failure.
4.3.6.

Remote Console Controller (ReCC) Board

The Remote Console Connector (ReCC) board serves as an interface between
the system bus logic boards and the devices that have no interconnection to
the Golfbus. In the Central Electronic Cabinet (CEC), these include:

Console

Calendar clock

Back-panel power supplies

Fault tolerant clock

Power subsystem

Blower modules

Cabinet lights

Filters

GENERAL DESCRIPTION

47

Chapter 4

The ReCC serves a number of critical functions :

Serves as an I/O board for low speed communications (RSN and

Console)

Serves as a central collection point for maintenance and diagnostics

Controls and monitors the main power supply for the system.

Like most other boards, the ReCC is a duplexed hardware design. All the
devices on the board are duplexed except the DUARTs and the calendar
clock. These devices are asynchronous, and there is no way to lock-step these
devices. As a direct consequence, a pair of ReCC boards cannot operate in
lockstep. Therefore the second ReCC operates in a non-traditional hot backup mode.
The Console controller has serial ports configured for asynchronous
communication. These ports are used by the system console and the second
(remote) console for displaying system messages and system commands.
Another console-controller port is used to collect system maintenance and
diagnostic information from the cabinet data collectors (CDCs).
The console controller is the only I/O board powered by its own housekeeping
power supply, which initiates the system power-on sequence.
4.3.7.

I/O Adapter (IOA) Chassis

4.3.7.1.

Chassis Terminator I/O Adapter

This I/O adapter provides power to the I/O bus terminators and detects and
reports I/O adapter chassis fan failures.

4.3.7.2.

Protocol Specific I/O Adapters

The SCP has the following protocol-specific I/O adapters installed :

X.21 I/O Adapter

T1/E1 and PRI-ISDN Communication I/O Adapter

X.21 I/O Adapter

The I/O adapter can be programmed to run the X.21/LAPB protocol. This
adapter supports one high speed synchronous line operating at 64Kbps. It is
equipped with a 15-pin D sub-miniature connector, conforming to the ITU-T
X.21(EIA-422A) standard.
T1/E1 and PRI-ISDN Communication I/O Adapter
This I/O adapter supports high speed X.25 LAPB network interface
communications over wide-area T1 or E1 circuits. It enables the SCP to run
applications that require faster communications speeds than those supported
48

C-DOT IN

SCP ARCHITECTURE

by the universal communications I/O adapters. The SCP can support up to

four communication I/O adapters.
The I/O adapter provides point to point communications of any multiple of
64Kbps, up to 1.544Mbps in T1 mode or 2.048Mbps in E1 mode.
4.3.8.

Cabinet Data Collector (CDC)

The Cabinet Data Collector (CDC) is a simplexed non-fault tolerant unit
which exists in the CEC. It resides on the back of the cooling chassis which is
located near the top of the cabinet.
The CDC performs the functions:

4.3.8.1.

Gathering and reporting of non mission-critical fault and status

information for the cabinet back to the ReCC. This data is made
available to the CPUs for further data processing.

Provides fan speed control and cabinet level thermal management.

Provides power and control signal for the Cabinet Fault Light located
in the ADU (Alarm Display Unit)

CDC Communication
The CDC communicates to the ReCC over a serial, half-duplexed RS-485 line.
The RS-485 network is a single initiator multi-drop network. The ReCC is the
initiator and the CDC is the drop.

4.3.8.2.

CDC Fan Speed Control

The CDC is responsible for monitoring and controlling the speed of the six fan
units in a fail-safe manner. The CDC generates 6 control signals for use by
each of the fan units. Under normal operating conditions (i.e., all fans present
and good, inlet air temperature of 29C or less), the CDC will drive these
lines high. Under such condition, the fans will run at approximately 70% of
the full rotational speed (2400 rpm). This is done for the purpose of reducing
acoustical noise to within acceptable limits and enhancing the fan's Mean
Time Between Failure (MTBF).
At inlet temperatures above 33C and under certain hardware fault
conditions, the CDC no longer drives these lines. The fans respond by
running at full speed.

4.3.8.3.

Fan Speed fault conditions

Under certain cooling hardware faults, the fans must be able to run at full
speed. The conditions are :

Missing CDC

Faulted or malfunctioning CDC

GENERAL DESCRIPTION

49

Chapter 4

4.3.8.4.

Un-powered CDC

One or more faulty fan units

One or more missing fan units

Ambient air temperature above 33C

Override mode switch has been pressed

Fail-Safe Operation
Since the CDC is not a duplexed piece of hardware, it operates in a fail-safe
mode. That is, if it is removed from the cabinet, or it has failed/malfunctioned
in any manner, the fans will react by running at full speed.
The CDC contains two LEDs, the Green LED is used to indicate that it is
working properly, and a Red LED which, when illuminated, is used to
indicate that the CDC is broken.

4.3.8.5.

Override Capability
The CDC is equipped with a switch which when activated will cause the fans
to operate at full speed, regardless of whether any faults or other events are
present or not. This is necessary to maintain sufficient cooling during field
service repair and upgrade operations. The switch will activate a timer that
will cause fans' full speed operation for a period of 4 hours. At the end of the 4
hours period the controller will automatically reset to the normal operation.
If the override switch is pressed again at anytime before the four hour time
limit is up, the fans will revert back to slow speed operation, but only if the
conditions warrant it.

4.3.9.

Power Supply Module

4.3.9.1.

DC Power Subsystem
The DC power subsystem, which consists of two DC power controllers, is
directly connected via power cables to a Central Office (CO) battery plant.
The DC power subsystem resides in the main cabinet. The DC power
subsystem filters the DC power and then outputs the power to the vertical
power bus in the cabinet.
The DC power subsystem and all the internal cabinet power supplies contain
circuitry that controls startup surge. Startup input current amounts must not
exceed the maximum operating current of 87 amps at -40V DC.
Power is distributed from the DC power controllers to the cabinet components
via a bus bar. The DC power controllers do not have battery backup, since
they receive continuous power from the CO battery plant. Each power
controller has one DC input and one DC output. The DC output is connected
to a common vertical power bus in the cabinet, which provides duplexed

50

C-DOT IN

SCP ARCHITECTURE

power distribution and is protected from power surge by a 100 amperes

circuit breaker.
4.3.9.2.

Backpanel Power Supply

To the right of the main chassis are the duplexed power supplies, labelled
PS0 and PS1. These units take power from the vertical power bus coming
from both the DC power subsystems and supply power to the main chassis
controllers. These units work in redundant mode

4.3.9.3.

IOA Chassis Power Supply

These two units are located above the I/O adapter chassis in the main
cabinet. Both of them take input from the vertical power bus coming from DC
power supplies at both sides and deliver power to the I/O boards in the I/O
adapter chassis.

4.3.9.4.

Disk/Tape Drive Power Supply units

These units are located in the lower and upper enclosures of disk/tape drive
units. They also take power from the vertical power bus and each unit
delivers power to the disk/tape drive units in the corresponding enclosure.
The number of disk/tape drive power supply units per enclosure may be one
or two depending on the number of disk/tape drive units equipped in that
enclosure.
The SCP packaging is shown in Fig. 4.2.

4.4.

SOFTWARE ARCHITECTURE
The software at SCP is distributed in the following subsystems :
Operating System
Operating system of the SCP is Fault Tolerant Unix (FTX). FTX takes care of
system re-configuration during fault conditions, generates appropriate alarms,
isolates the faulty units and reconfigures the system on the duplicated units.
Similarly, on recovery of the faulty units these are brought back into the system
and made available for application processing. During all this reconfiguration FTX
ensures that the system is continuously available for services.
Oracle Database
All the data required for IN services is located in the oracle database of the SCP.
Application programs have an interface to this database. The database contains the
data related to subscriber profile, system parameters and network specific
information needed for services.

GENERAL DESCRIPTION

51

Chapter 4

Application Platform
Following are the major components of the application platform:

Node Management

Common Application Services Layer (CASL)

Transaction Capabilities Application Part ( TCAP) Management

Signalling Connection and Control Part(SCCP) Management

Message Transfer Part (MTP) Management

Integrated Services Digital Network User Part (ISUP)

Load Control

CCS7 driver and I/O adapter

Administration Subsystem
This software subsystem takes care of the user interface and other administrative
operations. It has been described in detail in the document "C-DOT SCP
Administrative Interface".

52

C-DOT IN

SCP ARCHITECTURE

Main
Chassis

Fan 0

Fan 1

Fan 2

Fan 3

Fan 4

Fan 5

C C S S C C
C
P P S C o o
S m m
U U I I m m
/
/ / /
M M E E I I
e e t t O O
h
m m r h
r P P
o o n n r r
r r e e o o
y y t t c c
0

Disk/Tape
Drive Power
Supply Unit

P P
S S
0 1

IOA Chassis
Power
Supply

IOA Chassis
Power
Supply

C C
C C
0 1

IO Adapter
Chassis

E1 Interface
Card

0 1

2 3 4 5

..

9 14 15

Hard Disk/Tape Drive Unit

Hard Disk

E1 Interface
Card
X.21
Interface
Card

Tape Drive

D C Power Controller

D C Power Controller

Air Filter Unit

Fig. 4.2.
C-DOT SCP
(Card-Cage Equipage)

GENERAL DESCRIPTION

53

Chapter 5.

SMP Architecture
5.1.

OVERVIEW
The Service Management Point (SMP) contains SMF (Service Management
function) and SMAF (Service Management Access Function). SMP is an interface
between the SCP and the user for IN services related data management and
between the service provider and the SCP for introducing new services in the
network after testing and validation.

5.2.

HARDWARE AND SOFTWARE ARCHITECTURE

C-DOT SMP platform comprises a Windows NT server which is connected to the
SCP via Ethernet on one side and to the user interface terminals via dial up links
on the other. It contains an Oracle server on which the entire database of the SCP is
replicated. Any data changes that a user requests via the user interface terminal
containing the Oracle client comes first to the SMP. The SMP validates the change
and replicates it onto the SCP. At all times, the Oracle databases at the SCP and
the SMP are kept in synchronism.
While the SMP server would reside close to the SCP, the remote client (ROI)
terminals would reside at the SSP locations.
The remote user terminals are general purpose Pentium PCs on which the SCP
Administrative interface software is loaded. Man-machine interface is provided via
a menu-driven Graphical User Interface. These terminals are connected to the SMP
either locally via a LAN or remotely via modem. Proper password and security
procedures are provided at these terminals so that no unauthorised access is
possible.

54

C-DOT IN

SMP ARCHITECTURE

Location: Calcutta
Fig. 5.1
SMP IN C-DOT IN
C-DOT
SCP

Ethernet
Hub

LOI

SMP1

Router

SMP0

Billing
ROI

Modem
Pool

PSTN

Modem

!
ROI at
Bangalore

Modem

!
ROI at
Jaipur

Fig. 5.1

SMP in C-DOT IN

GENERAL DESCRIPTION

55

Chapter 6.

IN Services
6.1.

OVERVIEW
IN services have been divided into "sets" based upon the underlying network's
capability in terms of logic processing, access types and signalling protocols.
In C-DOT IN, initially, only Capability Set-1 (CS-1) services are being offered. It
would be appropriate for the reader to appreciate at this stage itself that the flavour
of a particular service and its nomenclature depends upon the service provider. In
this chapter the CS-1 or CS-1 like services offered by C-DOT are briefly described
with a focus on the utility of the service to the end user.
1.

Freephone (FPH)

2.

Virtual Private Network (VPN)

3.

Account Card Calling (ACC)

4.

Virtual Card Calling (VCC)

5.

Premium Rate (PRM)

6.

Televoting (VOT)

7.

Universal Access Number (UAN)

The access codes services are summarised in Table 6-1.

Table 6-1
IN Services : Access Codes
Service Name

56

Access*
Code

Freephone

1600

VCC

1602

ACC

1604

C-DOT IN

IN SERVICES

Service Name

Access*
Code

VPN (offnet)**

1601

PRM

0900

VOT (Calling party is not charged)

1603

VOT (Calling party is charged)

1902

UAN-Local

1901

UAN-Long Distance

0901

Note :
*

The SCP ID, e.g., 33 for Calcutta SCP is appended to the access code, if so
desired by the service provider.

**

Access code for on-net VPN service (1610) only for internal user.

Some terms associated with all the services are defined below.
Service Customer
A service customer is the entity (i.e., a person or an organisation) that subscribes to
the service and pays for it's subscription and usage. The customer can define the
service parameters at the time of subscription and control access at the time of
usage.
Service User
A service user is an end-user of the service, i.e. one who makes calls by dialling the
service key and other digits.
6.2.

FREEPHONE
Freephone service is one of the most popular IN service in the world. It allows a
subscriber accepting to receive a call to be charged for the whole or part of the cost
of the call.
Apart from reverse charging this services also supports features like:

Time Dependent Routing (TDR) - route calls to the office number during
business hours and to the residence during others.

Origin Dependent Routing (ODR) - all calls originating from a particular

geographical area are routed to the nearest customer service location.

GENERAL DESCRIPTION

57

Chapter 6

6.3.

Originating Call Screening (OCS) - disallow calls from a particular

geographical area.

Call Forwarding Conditional (CFC) - calls forwarded to the specified

locations in case of default directory number being busy or not responding.

Call Distribution (CD) - calls distributed on more than one directory numbers
based on the percentage defined.

VIRTUAL PRIVATE NETWORK (VPN)

The Virtual Private Network (VPN) service provides the VPN customer all the
features of a private network by using the Public Switched Telephone Network
(PSTN) resources.
It allows the VPN customers (with significant long distance traffic between
corporate sites) to configure and use switched carrier circuits as if they were
dedicated private lines. A VPN customer can define his own private numbering plan
and class of service restrictions across closed user groups. VPN service in this sense
can be compared with a Centrex or a PBX
The charging for a VPN call can be flexible. The charges are levied to a common
"charge number". In this way, a company's travelling salesman can make STD calls
while the charges are levied to the organisation's common charge number.
Some unique terms associated with the VPN service are defined below.
On-net Locations
These are authorised network access locations that are logically defined by the
customer to be part of the Virtual Private Network. These network accesses are all
subjected to the user defined call screening and dialling plan. On-net locations are
directory numbers located on the SSP itself. On-net directory numbers require
subscriber data creation and on-net group creation at the SSP apart from the
corresponding data at SCP.
Off-net Locations
Off-net locations are those locations that are not defined by the customer to be part
of the VPN. The data corresponding to the off-net directory numbers is neither
present at SSP or SCP. These directory numbers emulate on-net or virtual on-net
locations by dialling access code, group id of the VPN group and the authorisation
code of the subscriber they are trying to emulate.
Virtual On-net Locations
The VPN members for which data is created at the SCP only. These are not resident
on the SSP but are subject to VPN defined call treatment, e.g. call screening

58

C-DOT IN

IN SERVICES

VPN User Group

A group of on-net locations and virtual on-net locations defined by the customer as a
closed user group. Each user group can be assigned a different set of calling
privilege.
6.4.

VIRTUAL CARD CALLING (VCC)

This service is a part of the Alternate Billing Services class. It allows the users to
make calls from anywhere in the network and let the charges to be debited from a
prepaid card. For holding the card the VCC customer need not have a directory
number in the conventional sense.
Virtual Card Calling service is an access code based service. All VCC calls require
the dialling of the service key followed by the card number.
The card numbers are first defined in the SCP. VCC cards of appropriate
denominations and access barring levels are then printed by the service provider at
the time of service subscription on secure stationery.
The cards can also be purchased off-the-shelf by the customer from a reseller.
With each call, the charge is debited from the customer's card.

6.5.

ACCOUNT CARD CALLING (ACC)

This service is also an Alternate Billing Service and allows the users to make calls
from anywhere in the network and let the charges to be credited to an account.
Account Card Calling service is also an access code based service. The service user
dials the service key and the ACC account number followed by a Personal
Identification Number (PIN) when prompted for it. The PIN is modifiable by the
customer.
The credit limit, access barring level and initial PIN of the customer is decided at
the time of subscription.

6.6.

UNIVERSAL ACCESS NUMBER (UAN)

This service enables a person or an organisation to publish one local or national
number and have incoming calls routed to different destinations based on the
geographical location of the caller.
UAN is similar to Freephone except in the way charging is done. In UAN, the
calling party bears the expenses of the call as defined by network. Moreover UAN is
available in two modes-local UAN and National UAN.
Local UAN, dialled by 1901YYxxxx (where YY is the SCP ID), connects only to a
number in the local network while national UAN, dialled by 0901YYxxxx, is used to

GENERAL DESCRIPTION

59

Chapter 6

access a number anywhere in the national network. A directory number with STD
facility can only dial a National UAN number while the local UAN is accessible
from every directory number.
Detail billing records of UAN are not available at SCP Local exchanges provide the
detailed billing logs and call logs. UAN can be used in conjunction with ODR, TDR,
CFC and CD to make it more useful.
6.7.

PREMIUM RATE (PRM)

Premium Rate customers provide value added professional services by advertising a
premium rate number. The service users are charged a premium for calls made to
the premium rate number. The per call premium rate and the revenue sharing
arrangement between the customer and the service provider is agreed upon at the
time of service subscription. The premium rate is a multiplier over the normal call
charge.
This service can be used in conjunction with features like ODR & TDR. It is quite a
popular and useful service and is used for getting medical advice, stock market
quotations, astrological advice, etc.
Detailed records of all PRM calls are prepared at the SCP. These contain details
such as the date, time, destination (PRM) number and the user's number.

6.8.

TELEVOTING (VOT)
Televoting is a very powerful "mass calling" service used by organisations engaged
in psephology and other opinion poll related services. The power of this service lies
in the instant availability of the results of voting. The users call one or more
televoting number/s advertised by the customer. The last two digits of the televoting
number are the choice digits. The caller is acknowledged by an announcement.
The televoting period is pre-decided between the customer and the service provider
and is advertised before polling. At the end of the specified period, the network
provider hands over the poll results (televoting counters maintained at the SCP) to
the customer.
Televoting is available in two flavours. One in which for each call the called party is
charged and the second in which the calling party is charged for each call.
For picking out lucky callers etc. there is a provision for connecting every nth call to
a special number or announcement.

60

C-DOT IN

Chapter 7.

IN Call Information Flow

7.1.

OVERVIEW
The protocol defined at the SSP-SCP interface for IN service calls related message
communication is IN Application Part (INAP). The INAP messages are used by the
SSP to query the SCP for advice on further call processing after the call is held in
abeyance at the SSP, and the SCP for advising the SSP.
The INAP messages are exchanged via the querying, addressing and transport
capability of the protocols of the CCS7 protocol stack. Transaction Capabilities
Application Part (TCAP) protocol is used for managing the queries (transactions),
Signalling Connection Control Part (SCCP) for routing the messages between the
nodes, and Message Transfer Part (MTP) for reliable transport of the payload.
For a basic understanding of the protocol flow between the SSP and the SCP the
message flow that takes place during the handling of a successful freephone call and
an unsuccessful freephone call is illustrated below.

7.2.

SUCCESSFUL FREEPHONE LOCAL CALL

a) User dials the freephone number. The call is routed through the network to the
SSP.
b) Detection Point 3 (DP3) (Analysed Information) is hit upon the satisfaction of the
trigger criterion, i.e., reception of the service key digits (say, 160033).
c) SSP suspends call processing and sends the first INAP message InitialDp in a
query to the SCP and waits for a response from it.
d) SCP upon receiving the InitialDp message containing the Service Key, calling
party number, freephone number and other information, will invoke the
freephone service logic and look up the freephone customer number in its
database. Upon successful validation sends:

CallInformationRequest message requesting the SSP for the call related

statistics to be logged at the end of the call.

GENERAL DESCRIPTION

61

Chapter 7

RequestNotificationCharging message advising the SSP on how to charge

the call and when to send back the EventNotificationCharging message
containing the charging information.

e) It then sends the translated (and PSTN routable) directory number/s

corresponding to the freephone number in a Connect message.
f) SSP on receiving the Connect message, will route the call through the local
network to the directory number present in the message and apply the charge
rate defined in routing data.
Note: In case the destination directory number received is outside the local
network, the SSP routes the call towards the TAX. The Charge Band Number, in
this case, will be sent by the TAX to the SSP just as in the case of a long distance
call. The SSP will prepare billing report according to the Charge Band received by it
and the duration of the call.
g) After call completion, i.e. when the call has been cleared , the SSP sends the
following to the SCP:

EventNotificationCharging message for billing record preparation.

CallInformationReport message for call details logging.

The above information flow is summarised the Table below.

User Activity
Dials Service Key +
Freephone Customer
Number

Message Sent by
the SSP

Message Sent by
the SCP

InitialDP
CalInformationReq
uest
RequestNotification
Charging
Connect

Enters Conversation
Clears the Call

EventNotification
Charging
CallInformationRe
port

7.3.

UNSUCCESSFUL FREEPHONE LOCAL CALL

a) User dials an unallocated freephone number, i.e. it does not exist in the SCP's
database. The call is routed through the network to the SSP.

62

C-DOT IN

IN CALL INFORMATION FLOW

b) Detection Point 3 (DP3) (Analysed Information) is hit upon the satisfaction of the
trigger criterion, i.e. reception of the service key digits (say, 160033).
c) SSP suspends call processing and sends the first INAP message InitialDp in a
query to the SCP and waits for a response from it.
d) SCP upon receiving the InitialDp message containing the Service Key, calling
party number, freephone number and other information, will invoke the
freephone service logic and look up the freephone customer number in its
database.
e) Since the dialled number has not been allocated, SCP will not be able to get the
translated number. Hence the SCP will send:

ConnectToResource message instructing SSP to connect specialised

resource for providing announcement to the caller

PlayAnnouncement message with the identity of announcement ",

instructing SSP to play the appropriate ("This number does not exists")
announcement to the caller with the help of the specialised resource
function.

ReleaseCall message to clear the call.

The above information flow is summarised the Table below.

User Activity
Dials Service Key +
Unallocated Freephone
Customer Number

Message Sent by
the SSP

Message Sent by the

SCP

InitialDP
ConnectToResource
PlayAnnouncement
ReleaseCall

GENERAL DESCRIPTION

63

Chapter 8.

SSP Administration
8.1.

OVERVIEW
For administration and operations of SSP a rich set of MML commands and traffic
reports has been provided. A brief description of these is given in the following
sections.
For a complete description of SSP administrative interface refer to the "C-DOT IN:
SSP Administration" document

8.2.

SSP ADMINISTRATION COMMANDS

The MML commands for updating and displaying the SSP parameters are placed
under classes 46 (Update Commands) and 47 (Display Commands) in the CRP
administration menu. The update commands are summarised in Table 8-1, and
display commands in Table 8-2.
Table 8-1
IN Administration Update Commands (Class 46)
S.No.

64

Command Mnemonic

Command Name

1.

CRE-TGR-TYP

Create a trigger type.

2.

DEL-TGR-TYP

Delete a trigger type

3.

MOD-TGR-TYP

Modify the characteristics of a trigger type.

4.

CRE-IN-SRV

Create an IN service

5.

DEL-IN-SRV

Delete an IN service

6.

MOD-IN-SRV

Modify the characteristics of an IN service

7.

MOD-INTONE-MAP

Modify IN tone mapping

8.

MOD-ESC-LIST

Add/Delete escape codes in/from escape code list.

9.

CRE-IN-GRP

Create an IN group

10.

DEL-IN-GRP

Delete an IN group

C-DOT IN

SSP ADMINISTRATION
S.No.

Command Mnemonic

Command Name

11.

GRNT-IN-SRV

Grant IN service to subscriber

13.

REM-SUB-FRMGRP

Remove subscriber from group

14.

ADD-SUB-TOGRP

Add subscriber to a group

Table 8-2
IN Display Commands (Class 47)
S.No.

8.3.

Command Mnemonic

Command Name

1.

DISPL-TGR-TYP

Display the characteristics of a trigger type

2.

DISPL-IN-SRV

Display the characteristics of an IN Service

DISPL-INTONE-MAP

Display IN tone mapping

4.

DISPL-ESC-LIST

Display escape code list

5.

DISPL-IN-GRP

Display IN group

SSP TRAFFIC REPORTS

Modified DSS MAX Traffic Reports
For supporting SSP related traffic measurements, a few existing traffic reports of
C-DOT DSS MAX have been modified The modified traffic reports and the
modifications thereof are summarised in Table 8-3.
New Traffic Reports
The MOD-INSRV-OBS.command has been added This command is used to add or
delete an IN service from the observation list. All the services can also be deleted
from the list in one go.
The SCCP and TCAP protocol related measurements according to ITU-T
Recommendation Q.752 have also been added as part of CCS7 measurements.

GENERAL DESCRIPTION

65

Chapter 8

Table 8-3
Modified Traffic Related Commands
S.No.
1.

2.

3.

Command
START-TRF-RPT

STOP-TRF-RPT

DISPL-TRF-RPT

Parameter
RPT-TYP (Report type)

RPT-TYP (Report type)

RPT-ID (Report ID)

New Parameter Choices

Added

INSRV (IN Services)

INACCS (IN Access Codes)

INSRV (IN Services)

INACCS (IN Access Codes)

INSRV (IN Services)

INACCS (IN Access Codes)

Note :
The SCCP and TCAP related reports can be seen against RPT-IDs SCCP-REP and
TCAP-REP respectively in the DISPL-TRF-RPT command. But these reports come
under the purview of CCS7 administration and are described in detail in "C-DOT
CCS7 User Manual".
Measurements Available
IN service related measurements that are available in various IN service and access
code wise reports are listed in the Table 8-4 below.
Table 8-4
IN Services Related Measurements

Traffic Report
IN Services

66

Measurements

Service Key

No. of service invocations

No. of successful invocations

No. of service invocations barred due to

service filtering

C-DOT IN

SSP ADMINISTRATION

Table 8-4 (Contd.)

IN Services Related Measurements

Traffic Report
IN Access Code

Measurements

Access Code

Service key

Number of successful calls (Answered)

Calls failed due to

-Busy
-No answer
-Congestion
-Unallocated Destination
-Overload of SCP
-Any other reason

GENERAL DESCRIPTION

Traffic intensity (erlangs)

67

Chapter 9.

IN Subscriber Administration
9.1.

OVERVIEW
IN subscriber or customer is administered at the SMP via a Remote Operator
Interface (ROI) terminal, which provides a GUI based MML interface. A rich set of
MML commands and traffic reports has been provided for subscriber data creation,
modification and traffic and billing administration. In order to insulate the SCP
from unvalidated at the SMP. SMP then updates the SCP. Similarly, in order to
prevent unnecessary loading of the SCP which is the call processor, traffic and
billing data is periodically dumped from it on to the SMP. The post-processing then
takes place at the SMP. The ROI terminals are allowed to access this processed
traffic and billing data only. A brief description of these is given in the following
sections.

9.2.

SCP ADMINISTRATION COMMANDS

All the MML commands available at the SCP are distributed under six major heads
on the SCP Administration Interface (SAI) menu. These are :
Service Deployment: After the service logic program has been created and
verified, it is deployed at the SCP via the SAI. Only after performing service
deployment will the operator be able to create IN customers for that service. A list
of such commands is given in Table 9-1.
Service Provisioning: After service deployment, the commands available in this
menu are used to create IN customers' data, and modify their service parameters
later on, if required. The list of available commands is given in Table 9-2.
Traffic Monitoring : This menu contains the commands for traffic monitoring and
observation. A list of such commands is given in Table 9-3.
System Configuration: The commands in this menu are used for creating network
connectivity data and tuning some system wide parameters, i.e. parameters
common to all the services. A list of such commands is given in Table 9-4.

68

C-DOT IN

IN SUBSCRIBER ADMINISTRATION

Utilities : The commands in the menu are used for card related operations. Also
bulletin Board Service is also available in this menu. A list of such commands is
given in Table 95.
Post Processing : This menu contains the commands which are used for
processing of billing and detailed call logs. Before processing can begin, call logs
need to be present locally. This is achieved by fetching the call log files at ROI. The
list of commands is available in Table 9-6
Table 9-1
Service Deployment Command
S.No.
1.

Command
Service Deployment

Parameters
Service name, Service key, Access code,
minimum length of logical number,
maximum length of logical number.

Table 9-2
Service Provisioning Commands
S.No.
1.

Command
IN Subscription
(For specifying the list of services to which
an IN customer subscribes)

Parameters
IN Number, Charge Number, Services
Subscribed, Terminal Numbers.

2.

Freephone Service Subscription

IN Number, Freephone number, Default

Treatment, Routing Tree Root Node,
Detailed Billing, Origin Dependent
Routing, Time Dependence Routing,
Call Log, Call Forwarding on Busy/No
Answer, Originating Call Screening,
Call Distribution

3.

Virtual Private Network Service

Subscription

IN Number, Group ID, Numbering Plan

length, offnet calling, offnet access,
detailed billing, call log, Closed User
Group ID, Authorization code, PNP
number, Treatment, Off-net Calling
Privileges, Closed User Group.

4.

Virtual Card Calling

IN number, card category, Expiry Date,

Call logging, Detailed Billing, Card
Amount.

5.

Premium Rate Service Subscription

IN Number, premium Rate Number,

charge band, Default treatment Routing
Tree Root/Node, Detailed Billing, call
log, ODR, TDR, OCS, CFC, CD.

GENERAL DESCRIPTION

69

Chapter 9
S.No.

70

Command

Parameters

6.

Televoting Service Subscription

IN Number, Televoting Number,

Number of Choice, Start Time, Stop
Time, Party to Charge, Calls before
Connect, Default Treatment, Routing
Tree Root Node, Detailed Billing, Call
log, ODR, OCS, TDR, CFC, CD.

7.

Change Number Service Subscription

Previous Number, Area Code, New

Number.

8.

Universal Access Number Service

Subscription

IN Number, Universal Access Number,

UAN Type, Default Treatment, Routing
Tree Root Node, Authorization, OCS,
ODR, TDR, Call Log, CFC, CD.

9.

Account Card Calling Service

Subscription

IN Number, Card Number, Card

Category, PIN, Card Amount, Expiry
Date, Call Logging, Detailed Billing.

10.

Origin Dependent Routing (Under the

service subscription menu for a particular
service)

Freephone Number (or any other

service's IN number), RT Node name,
Originating Area, Destination.

11.

Time Dependent Routing (Under Service

subscription menu for a particular service).

Freephone (or any other service's IN

Number) Number, RT Node Name, Day
of Year, Day of Week, Start Time, Stop
Time, Destination.

12.

Call Forwarding on Busy/No. Answer

(Under service subscription for a particular
service).

Freephone (or any other service's IN

Number) Number, Default Treatment,
Busy Treatment, No Answer
Treatment.

13.

Originating Call Screening

(Under service subscription for a particular
service).

Freephone (or any other service's IN

number) Number, Screening Criteria,
Area Code.

14.

Authorization
(Under service subscription for a particular
service)

Authorization code.

15.

Call Distribution
(Under Service subscription for a particular
service)

Freephone (or any other services' IN

number) Number, RT Node name,
percentage of calls, destination.

C-DOT IN

IN SUBSCRIBER ADMINISTRATION

Table 9-3
Traffic Monitoring Commands
S.No.

Command

Parameters

1.

Subscriber Traffic Report

Service Name, Logical Number, Start

Date, Start Time, Stop Date, Stop Time,
Periodicity.

2.

Service Traffic Report

Service Name, All Report, From, To.

3.

Purge Traffic logs

Log, Service, Logical Number, Mode

4.

Televoting Counters

Televoting number

5.

Processor Occupancy

Range of date

Table 9-4
System Configuration Commands
S.No.

Command

Parameters

1.

System Wide Area Codes

List of Area Codes

2.

System Wide STD Codes

List of STD Codes.

3.

System Parameters

INITCHRG, CRGPRD, CRGUNIT, RNCUNIT,

RSPUNIT, CHGBAND, TARIND, TARFAC,
ENCCHUNK, AT Period, ROI-VER
ANNCUNIT, Tcon, Tcnt, Trelcall, Tctr, Tpa,
Tpc, Tcirq, Tfci, Tdfc, Trrb, Tetc, Tsci, Tac,
Tast, Tat, Tcan, Tci, Tscfssf, Tacttest, Tssf

4.

Password Modification

Old password, new password

5.

Subscriber Listing

Service name.

6.

Location Administration

Location Name, IN Number range, Site Id.

7.

Operator Administration

Operator Name, Password, Location, Type of

Operator, Available Modules, Access Allowed to

8.

Terminal Administration

Location, Terminal Name, Available Modules,

Access Allowed to.

9.

VCC Card Types

Category, Initial Amount

10.

Charge Band Administration

Charge Band, Type, Tariff Class, Periodicity,

Periodic Charge

11.

Premium Rate Charging

Administration

Network Charge Band, Information Charge

Band, Resultant Charge Band

12.

Transaction Logs

Location, Operator Name, Time Interval,

Command Name

GENERAL DESCRIPTION

71

Chapter 9

Table 9-5
System Configuration
S.No.

Command

Parameters

1.

PSN Listing

Type of PSN, Location, PSN Range

2.

Calling Card Utility

Card Type, PSN/Logical n Number, Location

3.

Message Board

Date, from, to Operator, at location, subject,

message text.

Table 9-6
System Configuration
S.No.

9.3.

Command

Parameters

1.

Billing

Date range, hour range, charge no./logical

no/PSN (for VCC), Service name, PNP No.,
detailed billing options, tariff class change.

2.

Call Log

Date range, hour range, logical no./group

ID/PSN, service name, PNP No., detailed logs
option.

3.

Service Revenue

Date range, hour range, service name, Tariff

class change

4.

Fetch and Purge

Date Range, Options to fetch or purge

5.

Logo Analysis

Rate Range, Hour Range, Logical No./Group

ID/ PSN, Service Name, PNP No., Report type.

SCP Traffic Reports

SCP traffic reports contain measurements on IN services, processor occupancy and
CCS7 protocols (SCCP, TCAP and MTP).
Note
The CCS7 protocol reports are viewed from the SCP console, whereas, IN services
and processor occupancy reports can be seen via the SAI.
The measurements available are listed in the Table 9-7below.

72

C-DOT IN

IN SUBSCRIBER ADMINISTRATION

Table 9-7
SCP Traffic Measurements
Report
MTP Report

SCCP Report

TCAP Report

GENERAL DESCRIPTION

Measurements

Link name

L3 unavailability duration

L3 congestion duration

No. of L3 octets transmitted

No. of L3 octets received

Level 2 availability duration

No. of MSUs discarded

No. of times and the duration for which a

destination became inaccessible

Point Code not available.

Network congestion

SSN not available

Unassigned user part

Syntax error

Unknown reason

SSN messages sent

SSN message received

No. of components sent

No. of components received

No. of local rejects

No. of return errors

73

Chapter 9
Report
Service Traffic Reports

Measurements

Service name

Monitoring started time

No of call attempts

No of successful calls

No. of calls forwarded

No. of calls failed due to- No Answer

- Busy
- Other

Subscriber Traffic Report

Logical number

Monitoring start time

No of Call attempts

No. of successful calls

Calls forwarded

Calls failed due to

- No answer
- Busy
- Other

Processor Occupancy Report

74

Logging time

Idle time (%)

C-DOT IN

System
Practices

COMMENTS

The following comments pertain to:

Document Name
CSP Section

Issue/Draft

,
No.

(Month)

(Year)

COMMENTS :

(Use a separate sheet if required)

Please mail your comments to:
Centre for Development of Telematics
Attn:

Mr. Y.K. Pandey

Director, Systems
39, Main Pusa Road
New Delhi 110 005
Tel.: +91-11-5740374
Fax: +91-11-5756378

Your Reference:
Name
:
Designation :
Company
:
Address
:
Tel. :
Fax :