GENERAL DESCRIPTION - cdothelpline.cdot.incdothelpline.cdot.in/helpline/documents/C-DOT_IN/INSSPGND.pdfTable of Contents Chapter 1. Introduction.....5

C-DOT IN

GENERAL DESCRIPTION

System Practices

Section No. 404-005-0677

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 C–DOT SYSTEM PRACTICE REFERS TO THE C–DOT 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 C–DOT, 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

GENERAL DESCRIPTION 5

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 man-machine commands and traffic reports of SSP and SCP respectively have been briefly described.

Chapter 1

6 C-DOT IN

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 customer’s and network provider’s 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

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 user-friendliness 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.

Chapter 1

8 C-DOT IN

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 on-the-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.

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.

Chapter 1

10 C-DOT IN

CCS7 NETWORK

USER

COMMUNICATION INTERFACE



PROGRAM INTERFACE

FIG. 1.1 IN ARCHITECTURE

INTELLIGENT PERIPHERALSERVICE SWITCHING POINTSERVICE CONTROL POINTSERVICE MANAGEMENT POINT

IP -SSP -SCP -SMP -

LEGEND :

IP

USER

X.25 OR ETHERNET

\DESIGN\SSP-GD\SSPGD-IN

SSP

USER USER

DATA BASE

DATA BASE

SCP

SMP

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.

Chapter 1

12 C-DOT IN

Fig. 1.2 Distributed Functional Entities

SMF

SCF

SCEF

SMAF

SDF

SRF

CCF CCF CCAF CCAF

SSF SSF

CCF

Signalling Circuit Interface

IN Real Time Interface

Management Interface

INTRODUCTION


The distribution of functional entities over the physical entities and their inter-connection is summarized in Tables 1–1 and 1–2 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

SCP-SSP-IP

INAP, TCAP, SCCP, & MTP ISUP, INAP, TCAP, SCCP, & MTP

SRF-SSF SSP-IP ISUP & MTP

14 C-DOT IN

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

SSP ARCHITECTURE


C-DOT DSS MAX BASIC ARCHITECTURE

BM 1

IOM

BM n

AM

CM

DISK TAPE VDU PRINTER

SUBSCRIBER LINES

ANALOG TRUNKS

DIGITAL TRUNKS

DIGITAL LINKSFROM RSUs

MDF

BM -CM -AM -

IOM -ADP -MDF -RSU -

BASE MODULECENTRAL MODULEADMINISTRATIVE MODULEINPUT OUTPUT MODULEALARM DISPLAY PANELMAIN DISTRIBUTION FRAMEREMOTE SWITCH UNIT

ADP

(I/O DEVICES)

LEGEND :

< 32n -

FIG. 2.1

\DESIGN\SSP-GD\SSPGD-SA

Chapter 2.

16 C-DOT IN

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 small-exchange 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 inter-module 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,

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 man- machine 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.

Chapter 2.

18 C-DOT IN

C-D

OT

DS

S M

AX

LA

YE

RE

D S

OF

TW

AR

E A

RC

HIT

EC

TU

RE

FIG

. 2.2

\DE

SIG

N\S

SP

-GD

\SS

PG

D-M

L

PE

RIP

HE

RA

L P

RO

CE

SS

OR

SU

BS

YS

TE

M

** T

ER

MIN

AL

HA

ND

LER

SO

FT

WA

RE

IS A

PA

RT

OF

TH

E

AN

D A

DM

INIS

TR

AT

ION

SO

FT

WA

RE

SU

BS

YS

TE

MS

* A

PP

LIC

AT

ION

SO

FT

WA

RE

CO

NS

IST

S O

F C

ALL

PR

OC

ES

SIN

G, M

AIN

TE

NA

NC

E,

**

TERMINAL HANDLERAPPLICATION SOFTWARE

*A

PP

LIC

AT

ION

SO

FT

WA

RE

DA

TA

BA

SE

MA

NA

GE

R

HA

RD

WA

RE

OPERATING SYSTEM

APPLICATION SOFTWARE

SSP ARCHITECTURE


OS SERVICES IN C-DOT DSS MAXFIGURE 2.3

\DESIGN\SSP-GD\SSPGD-OI

READ OS TABLES

TIME MANAGEMENT

. SET/CANCEL ALARM

. PAUSE/CANCEL PAUSE

. GET/SET TIME

. READ

. WRITE

PERIPHERAL I/O

CDOS

. WAIT ON SEMAPHORE

. WAIT ON EVENT FLAG

. SET/RESET EVENT FLAG

PROCESS CO-ORDINATION

DEBUGGING MONITOR. DEALLOCATE

. ALLOCATE

MEMORY MANAGEMENT

. CREATE

. START

. TERMINATE. TERMINATE

. START

. CREATE

PROCESS MANAGEMENT

. RECEIVE

. SEND

MESSAGE I/O

Chapter 2.

20 C-DOT IN

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 sub-system 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.

SSP ARCHITECTURE


GRRA

CMR

OTP TTP

SCP

PP PP

GLOBAL ROUTING

&

RESOURCE ALLOCATION

CALL MANAGER

TERMINATING

TERMINAL

PROCESS

ORIGINATING

TERMINAL

PROCESS

STATUS

CONTROL

PROCESS

PERIPHERAL PROCESSORS

ORIGINATING

LINE

TERMINATING

LINE

ETERNAL PROCESS

GPC IS NOT REQUIRED IN SBM SYSTEMS.

FIGURE 2.4PROCESSES IN CALL PROCESSING SUBSYSTEM

GPC

*

*

DYNAMIC PROCESS

GLOBAL PATHCONTROL

GRRA DIRECTLY COMMUNICATES WITH TTP.

*

\DESIGN\SSP-GD\SSPGD-CP

Chapter 2.

22 C-DOT IN

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

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.

24 C-DOT IN

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.

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.

Chapter 3

26 C-DOT IN

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 BCSM’s. 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 (PIC’s) and Detection Points (DP’s) which are identified between the PIC’s. 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 DP’s which come under the purview of originating portion of the call. Figure 3.1 shows the originating basic call state model.



The originating portion of the call comprises 6 PIC’s and 10 DP’s. The PIC’s 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 DP’s 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.

Chapter 3

28 C-DOT IN

FIG. 3.1ORIGINATING BCSM FOR CS-1

COLLECTED_INFO.

ANALYSED_INFO.

O_ANSWER

ORIG. ATTEMPT_AUTHORIZED

1. O_NULL & AUTHORIZE ORIGINATION_ATTEMPT

O_MID_CALL

O_DISCONNECT

9

8

POINT IN CALL (PIC)

TRANSITION

DETECTION POINT (DP)

5. O_ACTIVE

7

10 O_ABANDON

3. ANALYSE_INFO.

4. ROUTING & ALERTING

3

2. COLLECT_INFO.

2

1

\DESIGN\SSP-GD\SSPGD-OG

O_CALL_PARTY_BUSY

O_NO_ANSWER

6

T1136230-91/D05

6. O_EXCEPTION

ROUTE_SELECT_FAILURE

5

4



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.

Chapter 3

30 C-DOT IN

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.



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.

Chapter 3

32 C-DOT IN

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 criteria’s 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 :



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 and call type. At this point, Analysed_Information DP is present.

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.

Chapter 3

34 C-DOT IN

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



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 DP’s 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 DP’s.

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.

Chapter 3

36 C-DOT IN

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.



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 PIC’s 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 (DP’s) 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 PIC’s and 7 DP’s. The PIC’s are:

1. T-Null and authorise termination attempt. 2. Select_facility and present call 3. T_Altering 4. T_Active 5. T_Exception.

The DP’s are:

1. Termination_Attempt_Authorised 2. T_Called_Party_Busy

Chapter 3

38 C-DOT IN

FIG. 3.2TERMINATING BCSM FOR CS-1

\DESIGN\SSP-GD\SSPGD-TM

TRANSITION

DETECTION POINT (DP)

POINT IN CALL (PIC)

T1136240-91/D06

T_MID_CALL

T_DISCONNECT

T_ABANDON

16

17

18

14

T_NO_ANSWER

T_CALLED_PARTY_BUSY

T_ANSWER15

9. T_ALERTING

10. T_ACTIVE

TERM._ATTEMPT_AUTHORIZED 12

8. SELECT_FACILITY & PRESENT_CALL13

7. T_NULL & AUTHORIZE TERMINATION_ATTEMPT11. T_EXCEPTION



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

Chapter 3

40 C-DOT IN

♦ Route index

♦ Original called party ID

♦ Redirecting party ID

♦ Redirection information

3.2.2.2. 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 :

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



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.

Chapter 3

42 C-DOT IN

When a disconnect indication is received from the terminating party (i.e. on-hook) 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.


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. SYSTEM ARCHITECTURE

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

Chapter 4

44 C-DOT IN

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.

SCP ARCHITECTURE


Figure 4.1

Console controller

CC1 Console controller

CC0

Consoles

RSN

Maintenance & Diagnostics

CPU/Memory

Slot 0

K600 Communication I/O processors

Slot 4

K460 SCSI/Ethernet I/O controller

Slot 2

CPU/Memory

Slot 1

K600 Communication I/O processors

Slot 5

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

C-DOT SCP System Block Diagram (Logical Connectivity)

Chapter 4

46 C-DOT IN

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.

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

Chapter 4

48 C-DOT IN

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 back-up 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

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:

♦ 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)

4.3.8.1. 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 29°C 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 33°C 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

Chapter 4

50 C-DOT IN

♦ 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

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

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.

Chapter 4

52 C-DOT IN

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

SCP ARCHITECTURE


Fig. 4.2. C-DOT SCP

(Card-Cage Equipage)

D C Power Controller

D C Power Controller

Air Filter Unit

Hard Disk/Tape Drive Unit

IOA Chassis

Power Supply

IOA Chassis Power Supply

C P U /

M e m o r y

C P U /

M e m o r y

S C S I / E t h r n e t

S C S I / E t h r n e t

C o m m I O

P r o c

C o m m I O

P r o c

C C 0

C C 1

P S 0

P S 1

Fan 0

Fan 1

Fan 2

Fan 3

Fan 4

Fan 5

0 1 2 3 4 5 0 1 2 3 4 5 ….. 9 14 15

X.21 Interface

Card

E1 Interface Card

E1 Interface Card

Hard Disk Tape Drive

Main Chassis

Disk/Tape Drive Power Supply Unit

IO Adapter Chassis

54 C-DOT IN

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.

SMP ARCHITECTURE


Fig. 5.1 SMP IN C-DOT IN

! !

Fig. 5.1

SMP in C-DOT IN

Ethernet Hub

C-DOT SCP

Modem Pool

LOI

Location: Calcutta

SMP1

SMP0 Billing ROI

Modem

PSTN

Modem

ROI at Bangalore

ROI at Jaipur

Router

56 C-DOT IN

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 Access* Code

Freephone 1600

VCC 1602

ACC 1604

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.

Chapter 6

58 C-DOT IN

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

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

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

Chapter 6

60 C-DOT IN

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.


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.

Chapter 7

62 C-DOT IN

• 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 Message Sent by the SSP

Message Sent by the SCP

InitialDP

CalInformationRequest

RequestNotification Charging

Dials Service Key + Freephone Customer Number

Connect

Enters Conversation

EventNotification Charging

Clears the Call

CallInformationReport

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.

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 Message Sent by the SSP

Message Sent by the SCP

InitialDP

ConnectToResource

PlayAnnouncement

Dials Service Key + Unallocated Freephone Customer Number

ReleaseCall

64 C-DOT IN

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

SSP ADMINISTRATION



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)


1. DISPL-TGR-TYP Display the characteristics of a trigger type

2. DISPL-IN-SRV Display the characteristics of an IN Service

3 DISPL-INTONE-MAP Display IN tone mapping

4. DISPL-ESC-LIST Display escape code list

5. DISPL-IN-GRP Display IN group

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

Chapter 8

66 C-DOT IN

Table 8-3 Modified Traffic Related Commands

S.No. Command Parameter New Parameter Choices Added

1. START-TRF-RPT RPT-TYP (Report type) • INSRV (IN Services)

• INACCS (IN Access Codes)

2. STOP-TRF-RPT RPT-TYP (Report type) • INSRV (IN Services)


3. DISPL-TRF-RPT RPT-ID (Report ID) • INSRV (IN Services)


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 Measurements

IN Services • Service Key

• No. of service invocations

• No. of successful invocations

• No. of service invocations barred due to service filtering

SSP ADMINISTRATION


Table 8-4 (Contd.) IN Services Related Measurements

Traffic Report Measurements

IN Access Code • 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

• Traffic intensity (erlangs)

68 C-DOT IN

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.

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. Command Parameters

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

Table 9-2 Service Provisioning Commands


1. IN Subscription

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

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.

Chapter 9

70 C-DOT IN


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.



Table 9-3 Traffic Monitoring Commands


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


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

Chapter 9

72 C-DOT IN

Table 9-5

System Configuration


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


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.

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



Table 9-7 SCP Traffic Measurements

Report Measurements

MTP Report • 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

SCCP Report • Point Code not available.

• Network congestion

• SSN not available

• Unassigned user part

• Syntax error

• Unknown reason

• SSN messages sent

• SSN message received

TCAP Report • No. of components sent

• No. of components received

• No. of local rejects

• No. of return errors

Chapter 9

74 C-DOT IN

Report Measurements

Service Traffic Reports • 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 • Logging time

• Idle time (%)

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 :

Documents

GENERAL DESCRIPTION - cdothelpline.cdot.incdothelpline.cdot.in/helpline/documents/C-DOT_IN/INSSPGND.pdfTable of Contents Chapter 1. Introduction.....5