44473224-IN

INTELLIGENT NETWORK ACCESSMANAGEMENT

OPERATOR GUIDE

3BW36215ADAXPCAHA Ed. 01

Status RELEASED

Short title RIGOP

All rights reserved. Passing on and copying of this document, use andcommunication of its contents not permitted without written authorizationfrom Alcatel.

2 / 93 3BW36215ADAXPCAHA Ed.01

Contents

Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1 Introduction to the Intelligent Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.1 Why an Intelligent Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2 Examples of Intelligent Network Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.2.1 Modular Routing and Charging Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.2.2 Enterprise Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.2.3 Charge Card Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.2.4 Personal Mobility Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.2.5 Mass Call Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151.2.6 Customer-Defined Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.3 How Are IN Services Managed? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.4 Service Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.5 SSP-SCP, SCP-IP and SSP-IP Dialogue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.6 INAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.6.1 Typical INAP Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181.7 Role of the Service Switching Point (SSP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.7.1 Call Control Function (CCF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.7.2 Service Switching Function (SSF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

1.8 Terminated or Active Service Incompatibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Access to the Intelligent Network in the E10 (OCB283) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.1 Subscriber Leg and Circuit Leg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.2 Service Trigger Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.2.1 Trigger Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.3 Service Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.4 SCP-IP Dialogue (SRF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.4.1 Intelligent Peripheral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.4.2 IP Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.4.3 Local SRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.4.4 Relay SRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.5 Interworking Loops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.6 Tied Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382.7 Follow-On Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.8 Charging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.9 Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.10 Circuit Group Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412.11 Subscriber Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422.12 Managing the Signalling Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432.13 Observations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442.14 Call Screening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

2.14.1 Role of the Operator in Call Screening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452.14.2 Role of the Service Creator in Call Screening . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3 Loop Observation and Redimensioning Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4 Setting Up Access to an IN CS-1 Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.1 Principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.2 Declaring a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.2.1 Service Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.2.2 Service Identification Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.2.3 Addressing Data in the Signalling Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.2.4 Server Failure Management Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 544.2.5 Charging Management Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.2.6 SSP-SCP Dialogue Management Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.2.7 Post-Conditions of Triggering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

3BW36215ADAXPCAHA Ed. 01 3 / 93

Contents

4.3 Definition of Incompatibilities between Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.3.1 Incompatibilities with Terminated Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.3.2 Incompatibilities with Active Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.4 Definition of Trigger Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.4.1 Conditions for Using Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.4.2 Criterion 0: No Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.4.3 Criterion 1: Dialling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.4.4 Criterion 2: General Purpose Subscriber Category . . . . . . . . . . . . . . . . . . . . . . . . . 614.4.5 Criterion 3: General Purpose Subscriber Mark . . . . . . . . . . . . . . . . . . . . . . . . . . . . 614.4.6 Criterion 4: General Purpose Circuit Group Category . . . . . . . . . . . . . . . . . . . . . . 614.4.7 Criterion 5: Call Release Cause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624.4.8 Criterion 6: Connection Type Requested . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.4.9 Criterion 7: Called Party Address Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 634.4.10 Criterion 8: Special Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644.4.11 Criterion 9: Carriers Given in Current Preanalysis Allowed . . . . . . . . . . . . . . . . . . 644.4.12 Criterion 10: Carriers Given in Current Preanalysis Barred . . . . . . . . . . . . . . . . . . 654.4.13 Criterion 11: SCF Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654.4.14 Criterion 12: Correlation Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.4.15 Criterion 13: Intelligent Network Routing Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.4.16 Criterion 16: Carriers Given in Current Analysis Allowed . . . . . . . . . . . . . . . . . . . 664.4.17 Criterion 17: Carriers Given in Current Analysis Barred . . . . . . . . . . . . . . . . . . . . 66

4.5 Trigger Characteristics and Priority Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 685 Accessing an IN ER-1 Service in an IN CS-1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6 Multi-SCP Option Implementation Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

7 New Service Observation Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

8 Existing Service Observation Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

9 Fault Management Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

10 Intelligent Peripheral Management Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Appendix A : Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Appendix B : Meaning of CEIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91


Figures

FiguresFigure 1 : Overview of the physical entities of the IN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Figure 2 : IN service: freephone call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Figure 3 : IN service: universal personal number (UPN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Figure 4 : Typical IN service provision sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Figure 5 : Main internal functions of the SSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Figure 6 : Incoming and outgoing legs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Figure 7 : Typical detection points (originating side) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Figure 8 : The basic elements of service triggering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Figure 9 : Presentation of an external IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Figure 10 : Triggering services: sequence through files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51


Tables

TablesTable 1 : Criteria authorised for triggering an IN CS-1 service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Table 2 : Looped outgoing cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Table 3 : IN services: data organisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Table 4 : Service identification data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Table 5 : Service addressing data in the signalling network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Table 6 : Server failure management data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Table 7 : ABORT and OUVRT: standard failure causes and CEIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Table 8 : Charging management data (N 7 SS excluding TUP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Table 9 : SSP-SCP dialogue management data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Table 10 : Service triggering post-condition data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Table 11 : Authorised criteria by DP and access type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Table 12 : IDXNUM and NOSERV parameter values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Table 13 : LOCDEC parameter values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Table 14 : List of CEIs associated with the ISDN UP causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Table 15 : TMR parameter values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Table 16 : NTDE and PNUE parameter values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Table 17 : TSPA parameter values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Table 18 : TSPI parameter values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Table 19 : TSAA parameter values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Table 20 : TSAI parameter values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Table 21 : Values in a priority table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Table 22 : Meaning of CEIs and mapping with standard causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85


Preface

Preface

Purpose The intelligent network (IN) is a telecommunications network architecture in whichnew telecommunications services can be implemented rapidly. The architecture isbased on:

centralisation of service subscription data,

centralisation of the service logic in one or more servers.

Control messages and data are interchanged via a standard interface betweenthe server and the exchange.

In an intelligent network architecture, the operation of an IN service may makeuse of different physical entities.

The Alcatel 1000 E10 (OCB283) provides intelligent network access functions thatcomply with Intelligent Network Capability Set 1 (IN CS-1) from the ITU-T recom-mendations (Q.120x and Q.121x series).

This guide explains the key concepts of the intelligent network and describes howthe architecture is set up in the Alcatel 1000 E10 (OCB283). It then lists the ap-propriate procedures.

Audience The guide is aimed at operators responsible for using the intelligent network func-tions of the Alcatel 1000 E10 (OCB283) switching system.

It is also for service creators who want to know what functions are available onthe exchange with which their service is communicating.

Contents Chapter 1 describes the key concepts of the intelligent network.

Chapter 2 describes how these concepts are used in the Alcatel1000 E10 (OCB283).

Chapter 3 describes the interworking loop observation and red-imensioning procedure.


Preface

Chapter 4 describes how to access an IN service.

Chapter 5 describes how to access IN ER-1 services in an INCS-1 context.

Chapter 6 describes the multi-SCP function implementation pro-cedure.

Chapter 7 describes the new service observation procedure.

Chapter 8 describes the existing service observation procedure.

Chapter 9 describes the fault management procedure.

Chapter 10 describes the intelligent peripheral management pro-cedure.

Appendix A contains a list of abbreviations and their meanings infull.

Appendix B gives additional information on operating data.

Glossary defines the keywords used in this guide.

Index lists the main concepts and where they appear in theguide.

Related Documents Documents relevant to this guide are:

operation and maintenance sheets (FEX),

operator sheets (FOP),

operator guides (GOP),

the Directory of customer application data, (REDA).

The documentation on intelligent network services is part of the Alcatel 1400 in-telligent network group of documents.

Conventions The typing conventions used in this manual are:

text in italics: document titles, variable parameter values,

text in courier: commands typed by the operator,

text in bold: words or phrases to attract the attention of the reader.


1 Introduction to the Intelligent Network


This chapter outlines the general concepts of the intelligent network architecture.It provides an approach to how the intelligent network works in the Alcatel 1000E10 (OCB283) which is described in chapter 2.

The intelligent network (IN) is a telecommunications network architecture withwhich network operators can quickly respond to new telecommunications servicerequirements. The services provided by the intelligent network are called IN ser-vices in the rest of this document.

The intelligent network architecture offers great hardware flexibility which means,for example, that the provision of connection resources can be separate from thecontrol of those resources.

The usual physical entities of the IN are:

the SSP (service switching point) which provides access to the service,

the SCP (service control point) which contains the service logic and data,

the SMP (service management point) which provides the service operating andmanagement functions,

the IP (intelligent peripheral) which provides the resources for communicatingwith the service user.

The functions for installing a service can be distributed over several physical en-tities (see Figure 1).



Figure 1 : Overview of the physical entities of the IN



1.1 Why an Intelligent NetworkThe IN considerably reduces the time it takes to develop and deploy new services.Time is saved because:

the new services are independent of the basic call handling function (reduceddevelopment time),

the new service has little impact on the network elements in place (exchanges,servers).

When operating the services, the IN provides centralised management.

The IN therefore lets these services be set up quickly so that new customer require-ments can be immediately satisfied.



1.2 Examples of Intelligent Network ServicesThe services provided through an IN architecture benefit both residential and busi-ness customers. Although large families of services can be defined, a service isoften specific to a particular operator.

There are several categories of IN service:

modular routing and charging services (freephone calls, kiosk),

enterprise services (virtual private networks),

charge card services,

personal mobility services (universal personal number),

mass call services (telephone voting),

customer-defined services.



1.2.1 Modular Routing and Charging Services

The best known example of a modular routing and charging service is undoubtedlythe freephone service (see Figure 2). This service is enhanced with the addition ofa time-dependent and origin-dependent routing.

Figure 2 : IN service: freephone call

1.2.2 Enterprise Services

Enterprise services allow multi-site organisations to link sites and isolated mem-bers together via the public network.

Enterprise network services comprise:

the virtual private network (VPN) which links exchanges and individual sub-scribers,

the international virtual private network (IVPN).



The functionalities available can be:

private numbering plan,

conditional call transfer,

speed dialling.

The members of the virtual private network can use the same functionalities.

1.2.3 Charge Card Services

Charge card services allow users to make calls from a DTMF terminal withoutcoins or credit cards.

Example telecom operator phone cards.

1.2.4 Personal Mobility Services

The universal personal number (UPN) service automatically routes calls to anyfixed or mobile point in a network. With it, the user can move from one terminalto another to make and receive calls.



For an example of the UPN service, see Figure 3.

Figure 3 : IN service: universal personal number (UPN)

1.2.5 Mass Call Services

With mass call services, considerable surges of traffic on the public network canbe managed for limited periods. These are typically generated by competitionson the radio or television.

Examples of this type ofservice are

opinion polls,

telephone voting.

1.2.6 Customer-Defined Services

Customer-defined services allow customers to design services to suit their ownneeds. In practice, they often combine several IN service elements.

Examples ofcustomer-defined service

call screening,

preferential rate calls.



1.3 How Are IN Services Managed?Each call requiring the use of an IN service is directed through the switching net-work to an exchange that provides access to the service. In the IN architecture,this exchange is called a service switching point (SSP).

The SSP analyses the call and determines which server or service control point(SCP) is associated with the required service. The SSP collects the information itneeds to continue processing the service (for example, the caller’s identity). TheSSP then triggers the service by invoking the SCP.

On receipt of this request, the SCP selects the service logic according to the serviceidentifier supplied by the SSP.

When running the service logic, the SCP controls the SSP with commands trans-mitted via the INAP (intelligent network application protocol).

Example of managing aservice

a) The SSP identifies a freephone number. It asks the SCP to translate this specialnumber into a routing number.

b) The SCP carries out the translation, determines the charging parameters for thecall (the call is billed to the subscription associated with the freephone number)and controls the connection to the SSP.

During the call, the SCP and SSP can exchange information such as charging orend of call data in the form of INAP operations. The SCP can also invoke thevoice resources of an IP (intelligent peripheral) when handling the service.

The SCP controls the IP via the SSP.

For an example of an IN service provision sequence, see Figure 4.

Figure 4 : Typical IN service provision sequence



1.4 Service ScriptA service script is a program that describes the type and sequence of actionsthat the service can perform. Any service script is based on logical sequences ofindividual processes or SIBs (service independent building blocks).

An SIB is a re-usable, standard functional building block independent of any ser-vice and installation. Each SIB executes a single specific function (for exampleCharge, which applies a particular charge).

A service script has the following features:

it is run on the SCP,

it sequences the SIBs.

The data used to execute the service script is:

in the SSP for the user profile data,

in the SCP for the indexing data running the script (according to the results ofthe interactions with the user).

1.5 SSP-SCP, SCP-IP and SSP-IP DialogueSSP-SCP dialogue Dialogue between the SSP and the SCP is over the signalling network via the INAP

(intelligent network application protocol).

SCP-IP dialogue Dialogue between the SCP and IP is conducted by the operations of the INAP. TheSSP relays the dialogue.

For further details on the INAP operations associated with SCP-IP dialogue, seesection 2.4.

SSP-IP dialogue The signalling used for dialogue between the SSP and the IP depends on what theIP is considered to be:

When the IP is considered as another network element, dialogue between theSSP and the IP is by ISDN UP Nº 7 signalling. The IP is then identified in anetwork by its signalling point code. The INAP operations are transported inthe user to user field.

When the IP is considered as a digital subscriber, dialogue between the SSPand the IP is by digital subscriber signalling Nº1 (DSS1).

For more information on dialogue between the SSP and the IP, see section 2.4.



1.6 INAPWith the INAP, the SSP communicates with the SCP using standard messages. Theprotocol is based on the TCAP layer of the signalling system N 7 architecture.

The INAP provides the operations and procedures required to set up dialoguebetween:

the SCP and the SSP,

the SCP and the SRF.

These dialogue operations are concerned with:

triggering of the service,

management of the detection points (DP),

call control,

charging,

interactions with the user,

SSF-SCF dialogue management,

SSF operation.

1.6.1 Typical INAP OperationsTypical INAP operations INAP operations are based on the International Telecommunications Union (ITU)

recommendations (Recommendation Q.1218 in particular). A few examples arelisted below:

the InitialDP operation that the SSP sends to the SCP to start a service when thetrigger conditions are satisfied,

the Connect operation that the SCP sends to the SSP to direct the call to aspecific number,

the ApplyCharging operation that the SCP sends to the SSP to create or interacton charging,

the PlayAnnouncement operation that the SCP sends to the SRF to trigger arecorded announcement.



1.7 Role of the Service Switching Point (SSP)The service switching point (SSP) provides access to the IN services via its interfacewith the SCP.

The SSP performs internal functions needed to route the calls:

The call control function (CCF) used in basic calls as well as in IN calls. It isbased on common services such as translation, charging, observation, etc.

The service switching function (SSF) which comprises:

the trigger function,

the IN dialogue function.

The specialised resource function (SRF) which provides user-friendly inter-change between the SCP and the user. This can also be provided by anexternal unit, e.g. an IP.

For the main internal functions of the SSP, see Figure 5.

Figure 5 : Main internal functions of the SSP



1.7.1 Call Control Function (CCF)

The call control function needs to be able to communicate with external servers.By complying with ITU-T Recommendation Q.1214, the call control function al-lows the SSP to communicate with all servers on the market that comply with thestandard.

The call control function is based on two main principles:

dividing the call into two legs,

standardised call control modelling called the basic call state model (BCSM).

Leg The SCP access function is based on the leg concept.

A leg is an abstraction of the call-associated resources supplied to the servicecontrol function (SCF). A leg supervises a physical access resource (analogue sub-scriber line, digital subscriber line, circuit). It models the use of the SSP’s physicalresources (sending or receiving signals or messages over the physical access point,setting up or disconnecting paths in the switching network, etc.) and the processassociated with managing these resources.

A call consists of two legs:

the incoming leg which is on the call origin side,

the outgoing leg which is on the call destination side.

A service can be triggered on the incoming leg or on the outgoing leg.

For the incoming and outgoing legs, see Figure 6.

Basic call state model(BCSM)

The leg concept is based on the basic call state model (BCSM), which standardisesthe call phases from an SCP point of view. It contains the detection points (DP) ofthe call control process from which:

a service can be triggered,

a service can repeat a call.

There are two types of BCSM:

the originating BCSM (O-BCSM), which controls the behaviour of an incomingleg for a calling subscriber or an incoming circuit,

the terminating BCSM (T-BCSM), which controls the behaviour of an outgoingleg for a called subscriber or an outgoing circuit.



Figure 6 : Incoming and outgoing legs

Detection points (DP) The BCSM is characterised by detection points (DP) which are the phases of callcontrol in which an SCP can intervene.

The DPs relate to:

an event on the backward resource,

an event on the forward resource.

DPs can be trigger detection points (TDP) or event detection points (EDP).

1.7.2 Service Switching Function (SSF)

The SSF controls:

the conditions for triggering a service,

dialogue with the service control function (SCF),

distribution of operations from the SCF to the CCF or SRF.

Triggering a service The same call handling is initiated in the following situations:

basic call,

call involving an SCP.

The BCSM process goes through the finite state machine’s DPs. At each DP, theCCF invokes the SSF’s DP handling function. A server call can be triggered.



If the CCF and SSF require no SCP involvement, the call is a basic call.

In a call involving an SCP, the triggering of a service may be associated with thecalling access (from the calling subscriber or incoming circuit) or called access.Access to the SCP occurs at the call’s backward or forward access point.

The DPs determined by the CCF can be TDPs or EDPs.

Trigger detection points(TDP)

A TDP is a call control point to which the SSP can send information for the SCP.This information can be a request to suspend call control at the SSP. In this case,the SSP waits for a response from the SCP. It is then a request type TDP (TDP-R).

A service can be triggered on one or more TDP-Rs. The trigger is transmitted viathe INAP.

Event detection points(EDP)

An EDP is a call control point at which an SCP can ask to be called. The SCP setsthe EDPs.

There are two types of EDP:

The event detection point - request (EDP-R) reflects the suspension of call con-trol in the SSP. In this case, the SSP sends information to the SCP and the SSPawaits a response from the SCP.

The event detection point - notification (EDP-N) does not suspend call controlin the SSP. In this case, a notification tells the SCP that control of the call hasgone through that point.

EDPs are set by the service script using INAP dialogue.

For the detection points potentially involving an SCP during call control (on theoriginating side in the example), see Figure 7.



Figure 7 : Typical detection points (originating side)



1.8 Terminated or Active Service IncompatibilitiesA service may be incompatible with one or more existing services. Two servicesare incompatible if they cannot be activated simultaneously.

A service that is to be triggered may be incompatible with:

services that have been activated and are terminated,

services that are active.

When introducing a new service, it is important to define the incompatibility:

of the new service with the existing services (active or terminated),

of each existing service with the new service (active or terminated).

If there are terminated or active service incompatibilities, users must be notifiedfor the services that concern them.

Service incompatible withterminated services

Some services cannot be triggered after a service that has been activated andis now terminated. The terminated service incompatibility data lists the serviceswhich, if terminated, are incompatible with the triggering of the new service.

Service incompatible withactive services

Some services cannot be triggered if a particular service is active. The activeservice incompatibility data lists the services which, if active, are incompatiblewith the triggering of the new service.


2 Access to the Intelligent Network in the E10 (OCB283)

2 Access to the Intelligent Network in the E10(OCB283)

This chapter explains how access to the IN is implemented in the Alcatel 1000E10 (OCB283).

The position of the Alcatel 1000 E10 (OCB283) in the IN complies with ITU-T INCS-1 (intelligent network capability set 1) recommendations.

The Alcatel 1000 E10 (OCB283) provides standard functions for any serviceswitching point (SSP):

call control functions (CCF),

service switching functions (SSF).

This means it can communicate with any SCP that complies with these recommen-dations.

In addition, it provides a specialised resource function (SRF) for dialogue withinternal or external resources that do not have a compliant SRF.

Accessing the IN in the Alcatel 1000 E10 (OCB283) involves the following func-tionalities:

leg control,

trigger data,

SSP-SCP dialogue,

SSP-IP relation (SRF function),

interworking loops,

tied calls.



2.1 Subscriber Leg and Circuit LegIn the Alcatel 1000 E10 (OCB283), leg control incorporates the O-BCSM andT-BCSM models. For a description of these models, see section 1.7.1. Two vari-ants of the model are provided depending on whether the call is from a localsubscriber (subscriber leg) or from a circuit (circuit leg).

Subscriber and circuit leg control has the following characteristics:

Management of the server call triggering rules by DP processing based on thetrigger data. DP processing invokes the SSF-FSM function depending on whichservice is to be activated.

Management of the SSP/SCP relations by the SSF-FSM function. These rela-tions are managed according to the type of service triggered (SCP’s awaitinginstruction position or call control position).



2.2 Service Trigger DataTo trigger a service, the service switching point (SSP) needs:

trigger data,

service data.

For the basic elements of service triggering, see Figure 8.

Figure 8 : The basic elements of service triggering

2.2.1 Trigger Data

The trigger data contains:

a DP (detection point),

an access type,

the trigger criteria.

A priority number is given to each trigger. The priority number defines the servicetrigger priority in relation to the other services for a given access type and a givenDP.



Detection point (DP) A DP is a call control point at which the intervention of an SCP is possible.

In the Alcatel 1000 E10 (OCB283), different detection points are available:

For the originating basic call state model in the case of subscriber access (sub-scriber O-BCSM):

after analysis of the address information (Analysed_Information).

For the terminating basic call state model in the case of subscriber access(subscriber T-BCSM):

on indication of a call for the called party, ringing of the called party is notyet triggered (Terminating_Attempt_Authorised),

when the called party is busy, from the called party access point of view(T_Busy),

when the called party does not answer, from the called party access pointof view (T_No_Answer).

For the originating basic call state model in the case of circuit access (circuitO-BCSM):

The following DPs can be TDPs:

on the circuit seizure message (Originating_Attempt_Authorised),

when the routing information is found in the translation tables (Anal-ysed_Information),

when the network fails due, for example, to congestion (Route_se-lect_Failure),

when the called party access is busy from the calling party access pointof view (O_Called_Party_Busy),

when the called party access does not answer from the calling partyaccess point of view (O_No_Answer).

All these points are called request type trigger detection points (TDP-R). Theyoriginate triggering of the call to the SCP. The SSP then suspends the calland waits for instructions from the SCP.

The following DPs can be EDPs:

on receipt of the address information sent (Collected_Info),

after analysis of the address information (Analysed_Information),

on route selection failure or on receipt of a network congestion typeevent (Route_Select_Failure),

when the called party access answers (O_answer),

when the call is disconnected (O_disconnect),

when the call is abandoned before conversation begins (O_abandon),

when the called party access is busy (O_Called_Party_Busy),



when the called party access does not answer (O_No_Answer),

when the called party access goes on-hook for an analogue access orportability of the terminal for a digital access (O_Suspend),

when the called party access re-answers (O_Reanswer).

Access types Triggering of a service can be restricted to the type of access:

analogue,

ETSI type ISDN,

VN type ISDN,

circuit.

Trigger criteria IN CS-1 authorises service trigger criteria. For a description of how these criteriaare implemented on the Alcatel 1000 E10 (OCB283), see Table 1.

Multiple criteria can be used in combination.

Table 1 : Criteria authorised for triggering an IN CS-1 service

Criterion... type... from...

0 no criterion

serves to define an unconditional trigger (inthis case, the service is triggered on transi-tion to the DP unless there is a restriction onaccess type)

1 dialling number analysis

2 general purpose subscriber category characteristics assigned to the subscriber

3 general purpose subscriber mark characteristics assigned to the subscriber

4 general purpose circuit group cate-gory

characteristics assigned to the circuit group(incoming leg circuit)

5 call release cause (1) call release data

6 type of connection requested (1) call data

7 called party address format (1) call or translation data

8 special conditions BCSM data

9 carriers given by current preanalysisauthorised (1)

the carrier number at the preanalysis output

10 carriers given by current preanalysisnot authorised (1)

the carrier number at the preanalysis output

11 SCF identifier network signalling

12 correlation identifier network signalling



Criterion... type... from...

13 intelligent network routing code discriminations associated with the routingcode

16 carriers given by current analysis au-thorised (1)

carrier number at the analysis output

17 carriers given by current analysis notauthorised (1)

the carrier number at the analysis output

In Table 1, (1) means that the criterion is defined by a list of values.

The trigger criteria are given in section 4.4.



2.3 Service DataThe service data is:

service operating data,

service incompatibility data.

Service operating data The operating data is:

Service identification.

Nº 7 signalling network service address.

Server failure management data.

Charging management data.

SSP-SCP dialogue management data.

Data, called post-conditions, likely to be needed before triggering the service.

Service incompatibilitydata

The incompatibility data of the service to be triggered contains information on:

compatibility with the active services,

compatibility with the terminated services.



2.4 SCP-IP Dialogue (SRF)The specialised resource function (SRF) allows the SCP to control the interchangeswith the service user. It receives its instructions directly from an SCP or throughthe SSP.

Depending on the case, the SRF may be a local or relay function.

2.4.1 Intelligent Peripheral

An intelligent peripheral (IP) is a physical entity which handles the SRF. It providesflexibility for the information interchanges between a user and the network. TheIP enables the SRF to handle user interaction with an SCP.

Resources provided byan IP

The resources provided by an IP are:

transmission of synchronised or unsynchronised announcements and tones,

reception of digits from an analogue user or a digital user,

speech recognition and voice synthesis function,

voice mail,

storage and forwarding of faxes,

call centres,

teleconferencing.

Interconnection with an IP For the network connection, the external IP is directly linked to one or more SSPsand can be connected:

by Nº 7 signalling (in this case, it is seen as a network node),

by DSS1 signalling (in this case, it is seen as a digital subscriber).

The SCP-SSP-IP interconnection is handled by the SCP which asks the SSP to con-nect a user to a resource situated in an IP connected to the SSP that handles therequest.

Example of interconnection With a private phone card, the interaction between the IP, the user and the SCP isas follows:

the SCP tries to identify the user,

the SCP asks the IP to send an announcement to the user to ask him/her toenter their card number and personal code,

the user enters card number and personal code,

the IP receives the information and forwards it to the SCP, via the SRF.

2.4.2 IP Categories

There are two IP categories:

integrated IP,

external IP.



Integrated IP An integrated IP is installed and managed locally. It is based on Alcatel 1000 E10(OCB283) technology (hardware and software). It is fully integrated in the SSP.

The SSP, under the SCP’s control, connects the calling user to the integrated IP.

The local SRF is used to:

generate announcements of the fixed type (standard announcements),

receive keypad dialling (analogue or digital user),

generate local tones (ringing tone, dial tone, etc.).

External IP An external IP is a physical entity situated outside the SSP.

The services provided by the external IP are additional to those provided by theintegrated IP and relate to:

transmission of announcement sequences,

transmission of announcements with a variable part,

implementation of voice synthesis and recognition functions.

The IP logic contains all the variable and fixed announcements to make up therequired announcement.

For an external IP, see Figure 9.

Figure 9 : Presentation of an external IP

2.4.3 Local SRF

The local SRF controls:

establishment of a voice/speech channel to the end user,



transmission of tones (for ringback, dial tone, etc.),

transmission of recorded announcements (service unavailable, etc.),

collection of DTMF digits.

Local SRF with integratedIP

The local SRF with integrated IP works as follows:

a) Initialisation:

The SCP starts the SRF:

either by the ConnectToResource operation which, under the SCF’s con-trol, is used only to initialise the function without inserting any parametersfor routing to the IP,

or, under the SSF’s responsibility, by the ToneGeneration operation, with-out triggering the ConnectToResource operation.

b) The user-IP interaction phase:

The SCP begins user interaction with the PlayAnnouncement operation,which specifies the announcement or the tone to be sent to the user.

The SSP responds to the PlayAnnouncement operation from the SCP withthe SpecialisedResourceReport operation if the SCP requests.

The SCP uses the PromptAndCollectUserInformation operation to askthe IP both to send an announcement or tone to the user and to collect theinformation from the user.

The Cancel operation is for cancelling the PlayAnnouncement orPromptAndCollectUserInformation operations awaiting processingand stopping the current actions. This instruction takes priority over allothers.

c) Release:

In addition to the call being released by the user (hanging up), interchangesare disconnected by the SCP or IP.

The SRF is released:

when the DisconnectForwardConnection operation is received,

when the processing of an operation ends with DisconnectFromIPFor-bidden=false.

Use of a synchronised announcement in an integrated IP (MPNA) entails correctlysetting the time delay pending that announcement. Set this timer to at least 90seconds via the announcement control panel on the IN platform.

Local SRF with external IP Operation of the local SRF function with external IP works as follows:

a) Initialisation of the interchanges by the ConnectToResource operation.

b) Interchange procedure:



The PlayAnnouncement operation asks the SRF to send the caller a spe-cific announcement described in the operation parameters.

The PromptAndCollectUserInformation operation is the equivalent ofa PlayAnnouncement operation with the collection of digits.

Generally, the external IP supplies all the announcements for a single service.

c) Releasing of the interchanges:

The DisconnectForwardConnection operation explicitly disconnects a con-nection to a resource (SRF).

2.4.4 Relay SRF

The relay SRF is performed by the SSP. The SSP is used only to set up the call tothe external IP and relay the messages between the SCP and the IP.

The relay SRF works as follows:

a) Initialisation:

The SRF begins on receipt of a ConnectToResource containing the IP coor-dinates (IP routing address) equivalent to a directory number. The translationmechanism for the IP interface is:

definition of the IP as a national network number,

provision of preanalysis, analysis and a routing to the IP.

b) Procedure:

The SendSTUI operation sends a message to the external IP to control theuser interaction. The message is transmitted transparently.

The ReportUTSI operation receives a message from the external IP in-tended for the SCP. The message is transmitted transparently.

It is not possible to link PlayAnnouncement operations and run a SendSTUIoperation.

c) Releasing of the interchanges:

The interchanges are released by the SCP or the IP either on receipt of theDisconnectForwardConnection operation or when the processing of anoperation ends with DisconnectFromIPForbidden=false.



2.5 Interworking LoopsA loop is a physical link of a set of n PCM links connected at the SSP to n other PCMlinks. The loop traffic is handled on loop signalling link sets and loop telephonecircuit groups. The quantity of PCM links in the telephone circuit group dependson the traffic to be handled. The loop telephone circuit groups use ISDN UPsignalling.

The term “looped outgoing” is used to mean seizure of a circuit on a loop tele-phone circuit group.

Depending on how an IN service is specified, and whether it coexists with anotherservice (for example, triggering of an IN CS-1 service by a local subscriber), itmay be necessary to set up one or two loops.

The information needed for looped outgoing operations comprises:

DPs,

access types,

criteria triggering the service.

operations that make up the service script.

Table 2 lists situations in which the loops are used.

Note : If the service uses criterion 4 "General purpose circuit group category", the circuitgroup to which a standard category FRIi should be assigned is the circuit groupused in the loop and not the call’s incoming circuit group.

Table 2 : Looped outgoing cases

Case Originating access type Terminating ac-cess type

Additional conditions

Case 1subscriber

channel associated cir-cuit

TUP circuit

subscriber The called subscriber is marked by a CRIcategory (and so can trigger an IN CS-1service).

Case 2 non TUP Nº 7 circuit subscriber On switching to PIC Routing, an IN CS-1service is active or a TDP is set to O_No_An-swer.

Case 3 non TUP Nº 7 circuit all port types Triggering of IN CS-1 services followed byan IN ER-1 service on the same call. Inother words, on the AnalysedInformationDP, on detecting triggering of an IN ER-1service, an IN CS-1 service has alreadybeen triggered (and may be terminated).



Case Originating access type Terminating ac-cess type

Additional conditions

Case 4 non TUP Nº 7 circuit all port types Triggering of an IN ER-1 service followedby an IN CS-1 service on the same call.In other words, the address informationsupplied in the CREATE operation of theIN ER-1 service points to a type 21 rout-ing.

Case 5 non TUP Nº 7 circuit all port types two IN CS-1 services are sequenced on thesame call. In other words, at the Anal-ysedInformation DP, on detection of trigger-ing of a PILOT service, an EDP_R is set on aservice already active.

Case 6subscriber


TUP circuit

all port types the service to be triggered on BCSMo is anetwork type service:

either the service has to be triggered ona DP other than the AnalysedInforma-tion DP

or the service requires one of the follow-ing operations:

RequestReportBCSMEvent

EventReportBCSM

ApplyCharging

ApplyChargingReport

FurnishChargingInformation

CallInformationRequest

CallInformationReport

Case 7subscriber


TUP circuit

non TUP Nº 7 circuit the service to be triggered is an IN ER-1service



2.6 Tied CallsTied calls involve forwarding a call for a called party to a new destination. Thisfunction is similar to call forwarding, but is controlled by the SCP.

Tied calls depend on the characteristics of the called party who wants to be con-tactable elsewhere. In this, it is different from the follow-on call function which isa service associated with the calling party.

With tied calls, the called user can have a call forwarded to a new destination.Up to six calls can be tied.

Tied calls operate as follows:

they take effect on receipt of the Connect operation on the outgoing leg(T-BCSM),

they cause a new incoming call (O-BCSM) to be created.



2.7 Follow-On CallsThe follow-on call function enables the caller to make several consecutive callswithout having to repeat the initial call phase.

Follow-on calling is one of the basic functions offered by the IN interface. It en-ables the server to modify the normal call process (completed or uncompleted)

The follow-on call function involves maintaining dialogue with the server for theduration of the call. It is therefore available for any Nº 7 incoming circuit leg.

The role of the follow-oncall function

The follow-on call function enables a calling subscriber to make several consecu-tive calls ("individual calls"), without hanging up after each one. Each of the callsis to a different called party, who may be local or remote. For this, the server canaccept a new number dialled by the caller through a user interaction feature.

The term "individual call" is use to represent each of the calls made in turn toeach of the called parties.

The term "global call" is used to represent the call considered from the viewpointof the calling party and including all of the individual calls.

Follow-on call applications This type of function is typically provided for the following services (list not exhaus-tive):

Service used to set up calls from any telephone, but charged to another ac-count, normally that of the calling party.

Prepayment service. This service can be used to assign a prepaid account to anetwork user. The user can make the call from any telephone up to the prepaidcredit limit. The user can top up the account at any time.

Services involving forwarding to a mail service. If a call is not completed, it isrouted to a number stored in the server.

Follow-on call functionmechanism

The follow-on call mechanism is implemented on an originating leg. This mech-anism is characterised by the receipt of a CONNECT operation. The operationinvolves restarting the BCSM_O at the O_ANALYSE_INFORMATION PIC.

Follow-on calls involve:

termination of a call ("individual call"),

start of a new call ("new individual call"),

termination of the “global” call after the calling party hangs up or following arelease indication.

Relationship betweenfollow-on calls andtelephone resources

Originating resources:

Resources from which the telephone relation is set up (for example: callinguser, incoming circuit, etc.).

Terminating resources:

Resources called by the originating resources or by another entity, such as theSCF (for example, the called user, outgoing circuit, etc.).



The originating resource remains present throughout the setup and conversationphases of each individual call. The terminating resource changes with each newindividual call set up. Consequently, a follow-on call is involved if several ter-minating resources have been used and then released and just one originatingresource has been used.

Terminating resources are released in sequence: a new call begins when the previ-ous call ends. This should not be confused with a conference call situation whichinvolves just one originating resource and several terminating resources at thesame time.

2.8 ChargingCharging for a call which uses intelligent network services involves specific fea-tures, in particular:

The SCP can be involved in determining the charge for the call,

the call charge comprises the network charge and the service charge. Thenetwork charge covers the cost of transporting the call and the service chargecovers the cost of use of the resources activated by the service.

Charging-related service data is described in section 4.2.5.

For information on the principles and implementation of charging in the IN con-text, refer to the Charging management operator guide, TXGOP.

2.9 TranslationTranslation can be involved:

for triggering the service on the dialling criterion (refer to the Translation man-agement operator guide, TRGOP),

for the interface with the IP (refer to section 2.4.4).



2.10 Circuit Group ManagementIf the service is triggered on criterion 4, “standard circuit group category”, anFRIi category must be assigned to the incoming N 7 circuit group concerned (nonTUP).

There are 32 categories. They are general purpose, in other words, there is noservice statically assigned to them. They are used as IN service triggering criteria.

The circuit group’s IN category (FRI) is managed solely via circuit group manage-ment operator commands, FSCxx.

Category Meaning Default

FRIi (1≤i≤32) General purpose circuit group categoryfor access to IN CS-1 services

no

The category used to trigger a service may:

change from one SSP to another,

change from one operator to another,

be common to all the SSPs of a network.



2.11 Subscriber ManagementSubscriber management applies:

when a service is triggered on the subscriber category or mark criterion,

if there is a change to a subscriber category or mark,

if a subscriber category or mark is deleted.

The category or mark which triggers a service may:

change from one exchange to another,

change from one operator to another,

be common to all exchanges in the network.

CRIi subscriber categories The CRIi subscriber categories are:

32 in number,

general purpose (no service is statically assigned to them),

usable for a calling or called subscriber,

applicable to any analogue or ISDN subscriber.

CRIi categories are managed by ABOxx subscriber line management operatorcommands.

Various categories can be assigned to the same subscriber.

Category Meaning Default

CRIi (1≤i≤32) general purpose category for access toIN CS-1 services

no

MRIi subscriber marks The subscriber MRIi marks are:

32 in number,

general purpose (no service is statically assigned to them),

usable for a calling or called subscriber,

applicable to any analogue or ISDN subscriber.

Various marks can be assigned to the same subscriber.

MRIi subscriber marks can be assigned or deleted:

by the MRIMO operator command (see FOP MRIMO),

by remote control of services,

by the ManageTriggerData operation sent by the SCP.



For more information on remote control of services, refer to the Subscriber man-agement operator guide, ABGOP. For implementation of remote control of ser-vices, refer to FEX RICMDSER.

Mark Meaning Default

MRIi (1≤i≤32) general purpose mark for accessing INCS-1 services

no

2.12 Managing the Signalling NetworkManagement of the signalling network applies when the service is created andcan also apply:

if a service is modified,

if a service is deleted.

Management of the signalling network is required:

for the SSP-SCP interface,

for the external SSP-IP interface if the external IP is connected by the ISDN UP.

For SCP-SSP dialogue, management of the signalling network involves using thefollowing protocols:

MTP (message transfer part),

SCCP (signalling connection control part),

TCAP (transaction capabilities application part).

For SSP-IP dialogue, management of the signalling network involves using thefollowing protocols:

MTP for the signalling links,

ISDN UP for the speech circuits.



2.13 ObservationsObservations in the intelligent network context have various specific features, inparticular:

a class of counters is used to observe interchanges between the SSP and theSCP (class I),

temporary observations are applied to each leg,

there are non-completion causes specific to the IN.

For information on the use of observation functions in the IN context, refer to theLoad and traffic observation management operator guide, OBGOP.



2.14 Call ScreeningThe SCP incorporates automatic functions for detecting and controlling conges-tion. In the event of congestion, the SCP sends a CallGap operation to the SSP.

The SCP can also send a CallGap operation to stop call screening.

An observation counter is available for screening. For more information, refer tothe Load and traffic observation management operator guide, OBGOP.

2.14.1 Role of the Operator in Call Screening

The Alcatel 1000 E10 (OCB283) operator allows or rejects call screening. Thisoperation is applied when the service is declared (see section 4.2.6). The obser-vation options are described in chapter 8.

The operator must authorise call screening in agreement with the service creator.

2.14.2 Role of the Service Creator in Call Screening

The service creator needs to be aware of the call screening functions. These aredefined by the parameters of the CallGap operation.

The CallGap operation parameters are listed below.

Gap criteria (gapCriteria):

This parameter is mandatory. It defines the criterion to be satisfied for a callto be subject to screening.

Restrictions relative to ITU-T Recommendation Q.1218: only the following cri-teria are applied.

Gap on a service (gapOnService): call screening is applied when theServiceKey of the IN service invoked is the same as the ServiceKey specifiedin the gapCriteria parameter.

Call gapping on called address and service (calledAddressAndService):screening is applied when the ServiceKey and digits (one or more digits upto the complete number) of the called number match those specified in thegapCriteria parameter.

Call gapping on called address (calledAddressValue): screening is ap-plied when the ServiceKey of the IN service invoked by the called numbermatches that found on the basis of digits specified in the gapCriteria pa-rameter.

Functionally, this amounts to service screening.

In some agreements, the calledAddressValue criterion is notrecognised in the Alcatel 1000 E10 (OCB283).

Gap indicators (gapIndicators):



This parameter is mandatory. It specifies the screening characteristics in termsof implementation time and screening interval (only one call allowed duringthis interval).

Control type (controlType):

This parameter is optional. It indicates the reason for activating screening.

Restrictions relative to ITU-T Recommendation Q.1218:

only the SCPOverloaded value is accepted,

if the controlType parameter is omitted, the callGap operation is accepted.

Gap treatment (gapTreatment):

This parameter is optional. It indicates how calls that were stopped by thescreening mechanism must be treated in the SSP.

Using the informationToSend field, the SCP can ask the SSP to send upline(provided the SSP’s internal SRF function has sufficient capacity):

either inband information (inBandinfo) including the identity of the an-nouncement and the time of its broadcast.

or a tone which includes the identity of the tone and the time of itsbroadcast.

Restrictions relative to ITU-T Recommendation Q.1218:

receipt of the displayInformation field causes the callGap operation notto be executed,

if the GapTreatment parameter or informationToSend field is omitted,the information sent by default is the congestion announcement.

Using the releaseCause field, the SCP specifies the cause value to be usedwhen the call is released after screening.

The “both” field enables the informationToSend and then the releaseCausefields to be processed.

In some agreements, the releaseCause and both parameters arenot recognised in the Alcatel 1000 E10 (OCB283).

For more information about screening, see ITU-T Recommendation Q.1218.


3 Loop Observation and Redimensioning Procedure


This chapter explains how to observe and, if appropriate, redimension the loops.

Review on the installation of loops:

Depending on the technical specification of the service to be implemented, oneor two loops may be needed.

The number and size of the loops are defined by the manufacturer.

You must inform the manufacturer of the technical specifications of the IN serviceand whether it coexists with other services (IN CS-1 and IN ER-1).

The loops are installed by the manufacturer.

Procedure To observe and, if appropriate, redimension the loops:

a) Run permanent observations (class F counters) or temporary observations (seeFEX OBOFC and OBOTF) on the loop telephone circuit groups.

A call that uses a loop is counted twice in the traffic category counter(class T permanent observations).

b) Depending on the observation results and provided the exchange has suffi-cient capacity, you can redimension the loop circuit groups. The help of themanufacturer may be needed.

To redimension the loops, you may, for example:

add circuits to a circuit group,

remove circuits from a circuit group.

c) End.




4 Setting Up Access to an IN CS-1 Service


After reading this chapter, you will know:

how access to the IN CS-1 service is managed,

how to define access to an IN CS-1 service.

To provide access to an IN CS-1 service from the Alcatel 1000 E10 (OCB283),you must declare the service and then define its trigger conditions.

The sections in this chapter explain the steps in setting up access to a service andthen give the details of each step.



4.1 PrinciplesSetting up access to an IN CS-1 service entails:

a) declaring the service (see section 4.2),

b) defining incompatibilities between services (see section 4.3),

c) defining the criteria of a trigger (see section 4.4),

d) defining the characteristics of the trigger and managing the priorities (see sec-tion 4.5).

After these steps, an 8-minute delay must be allowed before triggering the service.This allows time for the Alcatel 1000 E10 (OCB283) to register the data.

Data organisation The data that defines access to a service is in the FISERV, FICPTF and FICPTB,FIDCLE and FITRIG files which belong to the XATR archive. Table 3 gives thecontent of these files.

Table 3 : IN services: data organisation

File Content

FISERV Service access data

FICPTB Incompatibilities with active services

FICPTF Incompatibilities with terminated services

FIDCLE Trigger criteria

FITRIG Trigger numbers in DP order, by access type and in descendingorder of priority



During the handling of a call, the above files are read to determine whether aservice needs to be triggered (see Figure 10).

Figure 10 : Triggering services: sequence through files



4.2 Declaring a ServiceDeclaring a service entails defining:

a service index,

service identification data,

addressing data in the signalling network,

server failure management data,

charging management data,

SSP-SCP dialogue management data,

service triggering post-conditions.

Some of these are mandatory, others are optional. By default, optional items areset to 0.

Procedure To declare a service:

a) Define the service index and data as indicated in the rest of section 4.2.

b) Enter the service data in the FISERV file (see FEX RIFISERV).

4.2.1 Service Index

The service index is a service’s unique identifier in the Alcatel 1000E10 (OCB283).

When declaring a new service, assign the service number any of the availablevalues. The value must be between 1 and 255 and must not match an existingservice index (see FEX RIFISERV).

4.2.2 Service Identification Data

The service identification data is used in the operations interchanged between thedifferent entities of the intelligent network. The data is mandatory (see Table 4).



Table 4 : Service identification data

Data Meaning Value

IDSR Identification of the service (ServiceKey) in the SCP. This is supplied by theservice creator in agreement with the operator. It is:

unique to the SCF,

attached to a service script,

an Initial_DP operation parameter.

0 to 231 -1

CLEF Number of the operator service key (ServiceKeyDC). This is used for charg-ing and observation. The observation counters are identified by the servicekey number.

Two services with the same service key cannot be distinguished at thecharging and observation levels, so:

Assign different service key numbers to the services you want to distin-guish from the charging and observation point of view.

Assign the same service key number to services that form a group ofservices.

0 to 255

4.2.3 Addressing Data in the Signalling Network

AFTAP is optional (0 by default). Other service addressing data in the signallingnetwork is mandatory (see Table 5).

Table 5 : Service addressing data in the signalling network

Data Meaning Values

NOASS Routing number in the signalling connection control part (SCCP). This isthe value of the ASS parameter in the ASSxx commands (see, for example,FOP ASSIN).

For more details on creating or modifying the routing in the SCCP, refer toFEX RSSSCS.

1 to 31

VPRO Number of the operation protocol version. It defines the functional stateof the application for INAP operations in the IN CS-1 function context.

In order to determine the value to use, refer to the Directory of customerapplication data (REDA).

1 to 16



Data Meaning Values

VPRS Number of the TCAP (transaction capabilities application part) protocolversion. It defines the application’s functional state.

1 to 16

AFTAP Indicates the use of the multi-SCP option for the service. This option is foraddressing a preanalysis-dependent routing in the SCCP.

If the multi-SCP option is not used, the routing in the SCCP defined bythe NOASS data is the one used.

If the multi-SCP option is used, the ATIDR post condition must be de-fined (see section 4.2.7).

For more detail on the multi-SCP option, see chapter 6.

0: single-SCPservice

1: multi-SCP ser-vice

4.2.4 Server Failure Management Data

Server failure management data is optional. The default setting is 0.

The internal failure codes (CEI) are internal to the E10 (OCB283) and used tomanage failures during call handling. You can use the CEI codes to define thebehaviour of the E10 (OCB283) in the event of a failure during the SSP-SCP dia-logue (see Table 6).

For mapping between CEIs and standard failure causes, use Table 7. The meaningof each CEI is given in Appendix B.

Table 6 : Server failure management data

Data Meaning Value

ABORT Behaviour of the SSP if:

there is no answer from the server when the service is active,

an internal error is detected by the SSP.

0 = continue the call

2 = CEI value for call re-lease with standard cause31 (normal, unspecified)

n = CEI value for callrelease with the standardcause given in Table 7

OUVRT Behaviour of the SSP if there is no answer from the server whenthe service is activated.

0 = continue the call

2 = CEI value for call re-lease with standard cause31 (normal, unspecified)

n = CEI value for callrelease with the standardcause given in Table 7

Table 7 relates the standard ISDN UP failure causes (ITU-T RecommendationQ.850) to the CEIs that can be used for the ABORT and OUVRT items. The valuesshown in the table are decimal.



Table 7 : ABORT and OUVRT: standard failure causes and CEIs

ISDN UPcause

CEI ISDN UPcause

CEI ISDN UPcause

CEI

01 39 34 08 79 129

03 40 38 09 87 74

16 01 41 04 88 216

17 34 42 06 90 130

18 160 47 66 91 243

19 141 50 131 95 212

20 123 53 132 97 139

21 70 55 133 99 140

22 103 57 135 102 138

25 73 58 136 111 81

27 67 63 54 127 211

28 15 65 45

29 44 69 134

31 02 70 242

4.2.5 Charging Management Data

Charging management data is optional (see Table 8). The default setting is 0.

The data relates only to incoming calls in Nº 7 signalling (except TUP).

For more details on charging management in the IN environment, refer to theCharging management operator guide, TXGOP.

Table 8 : Charging management data (N 7 SS excluding TUP)

Data Meaning Value

CDATAX Whether or not the service is allowed to use the SSP’s charging informa-tion.

0 = no

1 = yes

CMTAXR Whether or not the server is allowed to influence the network charge.

If it is, the server can change the network charging data (the content ofthe charging messages can be changed).

0 = no

1 = yes

RQTAXR Generation of an itemised billing ticket of the network type (standard for-mat)

0 = no

1 = yes.

RQTAXS Generation of an itemised billing ticket of the IN type (format differentfrom network format).

0 = no

1 = yes.



4.2.6 SSP-SCP Dialogue Management Data

SSP-SCP dialogue management data is optional (see table 9). The default settingis 0.

Table 9 : SSP-SCP dialogue management data

Data Meaning Value

PILOT Nature of service: Pilot, One shot or Assisting:

A Pilot service allows the server to set EDP-Rs in the call handlingprocess after triggering the service.

A One shot service does not allow the server to set EDP-Rs in the callhandling process after triggering the service. The server’s influence isrestricted to interchanging information with the user in the question/an-swer context and/or on transmission of a Connect operation on anal-ysis of the number.

In the context of the Stand Alone IP function, SSP may need to triggeran Assisting service. An Assisting service is incompatible with any otherIN service and does not allow the SCP to enable the EDP-Rs. For moreinformation on the Stand Alone IP function, refer to FEX RIASAIP.

0 = One shot

1 = Pilot

2 = Assisting

FIL Whether or not the SCP is allowed to screen calls using the CallGap op-eration.

The SCP uses the CallGap operation to ask the SSP to gap calls to theservice in question.

0 = no servicescreening

1 = screeningauthorised

STNEMI Whether or not an ST signal (end of pulsing) may be transmitted in theInitialDP operation.

0 = ST signalcan be sent

1 = ST signalcannot be sent

ETNS Whether or not the carrier number can be sent in the InitialDP operation.

Special case: at the DP O_Attempt_Authorized, the carrier number is notsent even if ETNS=0.

0 = carrier num-ber can be sent

1 = carrier num-ber cannot besent

CTNS Choice of carrier number to be sent in the InitialDP operation.

Meaningful if ETNS = 0

0 = carrier num-ber given bycurrent analy-sis (number usedfor routing thecall)

1 = carrier num-ber taken fromfirst preanalysis

2 = carrier num-ber given by thecurrent preanal-ysis



4.2.7 Post-Conditions of Triggering

The PSTCD data, which indicates the presence or absence of post conditions, ismandatory. Post conditions are optional and meaningful only if PSTCD=1 (seeTable 10).

Table 10 : Service triggering post-condition data

Data Meaning Value

PSTCD Presence or absence of service triggering post-conditions.

If PSTCD=1, specify the post-conditions below

0= no post-con-dition

1 = post-condi-tions

ATNCHF Awaiting digits 0 = no

1 = yes

NCHF Number of digits expected (significant if ATNCHF=1)

This field indicates the number of digits to be received before the serviceis triggered. If this number is greater than RDC or RCMA, the service willnever be triggered unless the end of dialling has been detected. You mustthen modify NCHF or modify the administration function.

0 = null

n = minimumnumber of dig-its expected (1 to20)

ATFNUM Awaiting end of dialling 0 = no

1 = yes

ATIDR Caller identification

If the caller’s identity is not available, depending on the ATIDR value:

1: the service is triggered with the "IDR unavailable" information.

2: the call is released (CEI = 56).

3: the service is not triggered.

0 = no

1, 2, 3 = yes



4.3 Definition of Incompatibilities between ServicesIn a leg, a service that satisfies the trigger conditions cannot be triggered if it isincompatible with another service triggered in the same leg.

The services triggered in the same leg and incompatible with the service to betriggered can be:

terminated,

active.

4.3.1 Incompatibilities with Terminated Services

When creating a new service:

for the new service, the list of incompatibilities with terminated services mustbe defined,

for each existing service, if necessary, the new service must be added to the listof incompatibilities with terminated services.

The incompatibilities with terminated services are in the FICPTF file. Each servicehas a record that can be accessed via the service index.

To modify the list of terminated services incompatible with a given service, referto FEX RIFICPTF.

4.3.2 Incompatibilities with Active Services

When creating a new service:

for the new service, the list of incompatibilities with the active services must bedefined,

for each existing service, if necessary, the new service must be added to the listof incompatibilities with the active services.

The incompatibilities with active services are recorded in the FICPTB file. Eachservice has a record that can accessed using the service index.

To modify the list of active services incompatible with a given service, refer to FEXRIFICPTB.



4.4 Definition of Trigger CriteriaDuring call handling, an IN service cannot be triggered unless the following con-ditions are met:

A trigger for this service exists for the standard call handling DP and for thetype of access concerned.

All the trigger criteria defined in the trigger are verified.

This section explains how to define the criteria of a trigger. Section 4.5 gives detailson trigger characteristics (DP, access type, priority).

Procedure To define the criteria of a trigger:

a) Ascertain the criteria used for triggering and the conditions for their use. Todo this, read the rest of section 4.4.

b) Enter the trigger criteria in the FIDCLE file (see FEX RIFIDCLE).

Note down the number of the record in which you are entering the triggercriteria. This is the NOTRIG trigger number. This number is used in the nextstep for specifying the trigger characteristics.

4.4.1 Conditions for Using Criteria

Table 11 lists the criteria that can be used according to the type of access and DPassociated with the trigger.

The Subscriber column in Table 11 includes analogue subscriber access, VN dig-ital subscriber access and ETSI digital subscriber access.

Table 11 : Authorised criteria by DP and access type

Authorised criteria by access typeDP

Subscriber Circuit

Autho_O_Attemp 4, 6 (2)

Analyzed_Information 1, 2, 3, (0) (3)

6, 7, 13 (0) (3)

9, 10, 16, 17 (4)

1, 4, 6, 7, 9 (1)

10, 11, 12 (1)

13, 16, 17 (1)

Route_select_Failure 0, 4, 5, 6 (2)

O_Called_Party_Busy 0, 4, 5, 6 (2)

O_No_Answer 0, 4, 5, 6 (2)

Term_Attemp_Autho 2, 3, 6, 8 (3) (4)

T_Busy 2, 3, 5, 6 (3) (4)

T_No_Answer 2, 3, 5, 6 (3) (4)



Key to Table 11:

(0) At least one of criteria 1, 2, 3 or 13 must be used.

(1) For TUP and channel associated signalling circuits:

criteria 4, 9, 10, 16 and 17 cannot be used,

there is neither service charging nor call supervision,

network charging is possible.

(2) Valid only for Nº 7 signalling circuits (excluding TUP).

(3) No service charging, no call supervision, network charging possible.

(4) Triggering is possible only if the subscriber characteristics include an INcategory (CRIi), an IN mark (MRIi) or, for criterion 8, entitlement to callingname identification presentation (DPND).

For more information on IN categories or marks, refer to the Subscriber man-agement operator guide, ABGOP.

4.4.2 Criterion 0: No Criteria

Criterion 0 is unconditional. The service can be triggered every time the DP ispassed if the current call’s access type matches the one defined in the trigger.

Criterion 0 cannot be associated with another criterion.

4.4.3 Criterion 1: Dialling

Criterion 1 is defined by the values of the IDXNUM and NOSERV parameters.During a call in which translation of the dialling culminates in a type 21 routing,an IN service can be triggered if the conditions specified in Table 12 are verified.

Table 12 : IDXNUM and NOSERV parameter values

If you set... then...

NOSERV=0 and IDXNUM=0 The criterion is verified in all cases (universal dialling trigger).

The IDS parameter of the type 21 routing identifies the service that canbe triggered.

NOSERV=0 and IDXNUM<>0 The criterion is verified if the value of the IDXNUM parameter matchesthe value of the IDS parameter of the type 21 routing.

The IDS parameter of the type 21 routing identifies the service that canbe triggered.

NOSERV<>0 and IDXNUM=0 The criterion is verified in all cases (universal dialling trigger).

The service index NOSERV identifies the service that can be triggered.

NOSERV<>0 and IDXNUM<>0 The criterion is verified if the value of the IDXNUM parameter matchesthe value of the IDS parameter of the type 21 routing.

The service index NOSERV identifies the service that can be triggered.



Administrationrequirements

If you use criterion 1:

a) Create a type 21 routing (see the Translation management operator guide,TRGOP).

b) Ensure that translation of the numbers that can trigger the service culminate inthis routing.

Associating criterion 1 withother criteria

If you associate criterion 1 with other criteria, set the value of the COMP parameter.

This parameter determines the behaviour of the system when criterion 1 is asso-ciated with one or more criteria (AND combinations) and when a criterion is notverified.

The COMP parameter can take the following values:

COMP = 0: the service is not triggered but exploration of the trigger tablecontinues.

COMP = 2: the call is released. The value 2 reflects the CEI (internal failurecode) used to code the cause of call release (see Table 22 in Appendix B). ThisCEI is the equivalent of standard cause n 31.

4.4.4 Criterion 2: General Purpose Subscriber Category

Criterion 2 is defined by the value of the CATBI parameter.

Criterion 2 is verified if the value i of the CATBI parameter defined in the triggermatches the general purpose subscriber category CRIi. This value is between 1and 32.

For more information on general purpose subscriber categories, refer to section2.11.


If you use criterion 2, assign the CRIi category to the CAT field of the subscribersfor which the service is to be triggered. Use a subscriber line create or modifycommand (see the Subscriber management operator guide, ABGOP).

4.4.5 Criterion 3: General Purpose Subscriber Mark

Criterion 3 is defined by the value of the MRQBI parameter.

Criterion 3 is verified if the value i of the MRQBI parameter defined in the triggermatches the subscriber’s general purpose MRIi mark. This value is between 1 and32.

For more information on general purpose subscriber marks, refer to section 2.11.


If you use criterion 3, assign the MRIi category to the MAR field of the subscribersfor whom the service is to be triggered (see the Subscriber management operatorguide, ABGOP).

4.4.6 Criterion 4: General Purpose Circuit Group Category

Criterion 4 is defined by the value of the CATBI parameter.



Criterion 4 is verified if the value i of the CATBI parameter defined in the triggermatches the circuit group’s general purpose category FRIi. This value is between1 and 32.

For more information on general purpose circuit group categories, refer to section2.10.


If you use criterion 4, assign the FRIi category to the CAT field of the circuit groupsfor which the service is to be triggered (see the Telephone environment manage-ment operator guide, ETGOP).

4.4.7 Criterion 5: Call Release Cause

Criterion 5 is defined by a list of LOCDEC and CEI (internal failure codes) param-eter pairs. Sixteen LOCDEC-CEI pairs can be defined for each trigger.

Criterion 5 is verified if the current call release data (LOCDEC and CEI) matchesone of the pairs in the list defined in the trigger.

The LOCDEC parameter specifies the location of the failure node in the network(call type). The values are derived from the ISDN UP or SSUTR2 signalling orassigned internally by the exchange (see Table 13).

Table 13 : LOCDEC parameter values

Value Code Meaning

0 U User

1 LPN Private network serving the local user

2 LN Public network serving the local user

3 TN Transit network

4 RLN Public network serving the remote user

5 RPN Private network serving the remote user

7 INTL International network

10 BI Network beyond interworking point

15 RNT National transit network

6, 8, 9, 11to 14, 16to 30

Reserved

31 ANY Any location

Table 14 lists the CEI for each ISDN UP standard cause. The meaning of eachCEI is shown in Table 22 in Appendix B.



Table 14 : List of CEIs associated with the ISDN UP causes

ISDN UPcause

Meaning Associated CEIs

17 User busy 34, 111, 143, 144, 156, 157,204

18 No user responding 31, 160, 161

19 No answer from user (user alerted) 141, 163

20 Subscriber absent 123, 213

27 Destination out of order 41, 67, 104, 158, 162, 217, 219

31 Normal, unspecified 32

No circuit/channel available

(with condition LOCDEC ≠3 and ≠4)

8, 13, 36, 71, 106, 113, 174,208, 210, 221

(with condition LOCDEC = 3) 127

34

(with condition LOCDEC = 4) 137

42 Switching equipment congestion 6, 7, 10, 14, 17, 18, 19, 33, 35,57, 83, 87, 116, 120, 121, 168,169, 170, 171, 172, 173

44 Requested circuit/channel not available 215

4.4.8 Criterion 6: Connection Type Requested

Criterion 6 is defined by a list of TMR parameters comprising up to three values(see Table 15).

Criterion 6 is verified if the current call’s connection type matches one of those inthe list.

Table 15 : TMR parameter values

FieldMeaning Value

TMR Speech 1

TMR 3.1 kHz audio 2

TMR 64 kbit/s 3

4.4.9 Criterion 7: Called Party Address Format

Criterion 7 is defined by a list of PNUE (numbering plan) and NTDE (nature ofcalled party address) pairs. This list comprises up to eight pairs (see Table 16).



Criterion 7 is verified if the “Numbering Plan - Nature of called party address”pair for the current call matches one of those in the list.

Table 16 : NTDE and PNUE parameter values

Field Value Field Value Meaning

NTDE 1 PNUE 1 Special service number and ISDN plan

NTDE 2 PNUE 1 National number and ISDN plan

NTDE 3 PNUE 1 International number and ISDN plan

NTDE 10 PNUE 1 Unknown nature and ISDN plan

NTDE 4 PNUE 5 VPN/Colysée number and Private plan

NTDE 5 PNUE 5 General VPN number and Private plan

NTDE 6 PNUE 5 Ordinary VPN number and Private plan

4.4.10 Criterion 8: Special Conditions

Criterion 8 is defined by the COSP parameter and only the value 1 is accepted.It reflects the CNIP service (calling name identification presentation).

Criterion 8 is verified for the value 1 if the called subscriber subscribes to the CNIPservice and if the call handling function does not have the calling party’s name.

For more information on the CNIP service that matches the DPND subscriber cat-egory, refer to the Subscriber management operator guide, ABGOP.

4.4.11 Criterion 9: Carriers Given in Current Preanalysis Allowed

Criterion 9 is defined by a list of TSPA parameters which each specify a four-digitcarrier number. The list contains a maximum of 32 carrier numbers or particularvalues (see Table 17).

To avoid conversions, enter the TSPA parameter values in hexadecimal code. So,to specify the carrier number 0123, enter hexadecimal value ’123’.

Criterion 9 is verified if the carrier number given by the current preanalysismatches one of the carrier numbers in the list. Table 17 shows how to use theparticular values.



Table 17 : TSPA parameter values

TSPA

(in hexadecimal)

Meaning

from ’0001’ to ’9999’ carrier number

’FFFF’ All carriers allowed

If this value is in the list, the criterion is verified if thecurrent preanalysis supplies a carrier number.

The value ’0FFF’ is also allowed for circuit access(compatibility with earlier levels)

’EEEE’ No carrier allowed

If this value is in the list, the criterion is verified if thecurrent preanalysis does not supply a carrier number.

4.4.12 Criterion 10: Carriers Given in Current Preanalysis Barred

Criterion 10 is defined by a list of TSPI parameters which each specify a four-digitcarrier number. The list contains a maximum of 32 carrier numbers or particularvalues (see Table 18).

To avoid conversions, enter the TSPI parameter values in hexadecimal code. So,to specify carrier number 0123, enter hexadecimal value ’123’.

Criterion 10 is verified if the carrier number given by the current preanalysismatches one of the carrier numbers in the list. Table 18 shows how to use theparticular values.

Table 18 : TSPI parameter values

TSPI

(in hexadecimal)

Meaning

from ’0001’ to ’9999’ Carrier number

’FFFF’ All carriers barred

If this value is in the list, the criterion is verified if thecurrent preanalysis does not supply a carrier number

’EEEE’ No carrier barred

If this value is in the list, the criterion is verified if thecurrent preanalysis supplies a carrier number

4.4.13 Criterion 11: SCF Identifier

Criterion 11 is verified if the ScfID parameter is received from the network sig-nalling (irrespective of its value).

Criterion 11 is linked to the Stand Alone IP function. For more information on thisfunction, refer to FEX RIASAIP.



4.4.14 Criterion 12: Correlation Identifier

Criterion 12 is verified if the CorrelationID parameter is received from the networksignalling (irrespective of its value).

Criterion 12 is linked to the Stand Alone IP function. For more information on thisfunction, refer to FEX RIASAIP.

4.4.15 Criterion 13: Intelligent Network Routing Code

Criterion 13 is defined by the INDBI parameter for which only the value 1 is al-lowed.

Criterion 13 is verified for the value 1 if the routing code has the general purposediscrimination DIx which corresponds to function n 1 in the Directory of customerapplication data (REDA). For more information on creating and modifying theanalysis data, refer to the Translation management operator guide, TRGOP.

4.4.16 Criterion 16: Carriers Given in Current Analysis Allowed

Criterion 16 is defined by a list of TSAA parameters which each specify a four-digitcarrier number. The list contains up to 32 carrier numbers or particular values (seeTable 19).

To avoid conversions, enter the TSAA parameter values in hexadecimal code. So,to specify carrier number 0123, enter hexadecimal value ’123’.

Criterion 16 is verified if the carrier number given by the current analysis matchesone of the carrier numbers in the list. Table 19 shows how to use the particularvalues.

Table 19 : TSAA parameter values

TSAA

(in hexadecimal)

Meaning

from ’0001’ to ’9999’ carrier number

’FFFF’ All carriers allowed

If this value is in the list, the criterion is verified if thecurrent analysis supplies a carrier number

’EEEE’ No carrier allowed

If this value is in the list, the criterion is verified if thecurrent analysis does not supply a carrier number

4.4.17 Criterion 17: Carriers Given in Current Analysis Barred

Criterion 17 is defined by a list of TSAI parameters which each specify a four-digitcarrier number. The list contains up to 32 carrier numbers or particular values(see Table 20).

To avoid conversions, enter the TSAI parameter values in hexadecimal code. So,to specify carrier number 0123, enter hexadecimal value ’123’.



Criterion 17 is verified if the carrier number given by the current analysis matchesone of the carrier numbers in the list. Table 20 shows how to use the particularvalues.

Table 20 : TSAI parameter values

TSAI

(in hexadecimal)

Meaning

from ’0001’ to ’9999’ Carrier number

’FFFF’ All carriers barred

If this value is in the list, the criterion is verified if thecurrent analysis does not supply a carrier number

’EEEE’ No carrier barred

If this value is in the list, the criterion is verified if thecurrent analysis supplies a carrier number



4.5 Trigger Characteristics and Priority ManagementThe trigger characteristics (DP, access type, priority) are in the FITRIG file. This filebelongs to the XATR archive. The priority assigned to a trigger ranges from 0 to63.

The FITRIG file is organised in priority tables which each match a "DP-access type"pair. Each table contains 64 records containing the trigger numbers (NOTRIG) indescending priority order. Priority 0 is the highest. Priority 63 is the lowest.

During call handling, the table for the current call’s access type and DP is scanned.If a trigger number is found, the call handling function checks the trigger condi-tions for the associated service.

Table 21 gives the meanings of the values in a priority table for a given DP andaccess type.

Table 21 : Values in a priority table

Value Meaning Table scanning mechanisms

0 No trigger number.

The record is available

Continue scanning the table

1 to 255 Record occupied by a NOTRIGtrigger number

The number of the record de-fines the priority of the trigger

Check the trigger conditions:

If the conditions are verified and there is no incompatibilitywith other services, the service is triggered. Where appro-priate, depending on the behaviour of the service that hasbeen triggered, scanning of the table may continue.

If the conditions are not verified, scanning of the table con-tinues.

1023 End of table mark Stop scanning the table

Procedure To identify the DP, the access type and priority associated with a trigger, enterthe trigger number in the appropriate record of the FITRIG file as explained inFEX RIFITRIG.

Note : To avoid time losses when call handling scans priority tables, assign an end-of-table mark (1023) to rank 0 of each DP-access type combination for which notrigger exists. This precaution is particularly useful when opening the IN CS-1operation.


5 Accessing an IN ER-1 Service in an IN CS-1 Context


This chapter explains how to use an IN ER-1 service in an Alcatel 1000 E10(OCB283) exchange that provides access to IN CS-1 services.

An IN ER-1 service is a service that uses the INAP-ALCATEL protocol specific to theAlcatel 1000 E10 (OCB283).

Characteristics of anIN ER-1 service

An IN ER-1 service has the following characteristics:

Irrespective of the service, the service number (NOSERV) is 256. This value isreserved for IN ER-1 services.

The service data is entered by the manufacturer and cannot be modified bythe operator.

Irrespective of the service, the trigger number (NOTRIG) is 256. This value isreserved for IN ER-1 services.

The trigger conditions are entered by the manufacturer and cannot be modifiedby the operator.

The trigger conditions for the service relate to analysis of the number dialled.They are verified if the analysis of the number leads to a type 15 routing.

The routing identifies the IN ER-1 service that is triggered.

If IN CS-1 services coexist with IN ER-1 services, the IN ER-1 service triggerpriority is set by the operator.

Coexistence of IN ER-1 andIN CS-1 services

If an IN ER-1 service and an IN CS-1 service can be triggered on the same call:

If an IN ER-1 service has been triggered, only an IN CS-1 service using thedialling criterion can then be triggered on the same call.

If an IN CS-1 service has been triggered, an IN ER-1 service can then betriggered on the same call.



IN ER-1 service triggerpriorities

To define the trigger priority of IN ER-1 services, refer to FEX RIFITRIG using thefollowing values:

DP (detection point) = Analyzed_Information,

access type = circuit,

NOTRIG = 256.


6 Multi-SCP Option Implementation Procedure


This chapter explains how to implement the multi-SCP option. This option is usedto select an SCP by preliminary analysis of the calling line identity or the initialcalled line identity if the call has been forwarded.

The multi-SCP option (AFTAP = 1, see section 4.2.3) can be used for several INCS-1 services, but the preanalysis file can be partitioned just once on a site.

A single preanalysis file is used for the multi-SCP option.



Procedure To use the multi-SCP option:

a) Refer to the REDA to obtain the number of the IDR (initial called party identity)preanalysis file from the PREAID data in FIPAM.

b) Refer to the table below.

To... execute the command...

PRECR (see FOP PRECR)

PREA = IDR preanalysis file n (PREAID)

PRE = PNXXXXXX

where:

create IDR preanalysis

P= Numbering plan (as a system value) of the IDR (1)

PREMO (see FOP PREMO-01)

PREA = IDR preanalysis file n (PREAID)

PRE = PNXXXXXX

where:

P= Numbering plan (as a system value) of the IDR (1)

N= Nature of address (as a system value) of the IDR (2)

XXXXXX= initial digits of the IDR (up to six digits)

modify IDR preanalysis

ASS = SCCP routing (see Table 5)

The following numbering plans are allowed:

1: ISDN plan,

5: private plan.

The following address types are allowed:

2: national number,

3: international number

Preanalysis of the IDRs to obtain an ASS may use all the “conventional” pre-analysis options (preanalysis of the called party identity), but without changingthe preanalysis file (see example below).

c) Set AFTAP = 1, PSTCD = 1 and ATIDR = 1, 2 or 3 in the FISERV file for theservice or services that use the multi-SCP function, by preanalysis of the IDR orof the initial called party identity. The values 1, 2 and 3 define the operationwhen IDR is unavailable (see section 4.2.7). If ATIDR=1, the routing number(ASS) in the FISERV file is the default routing number.

d) End.

Typical preanalysis of aninternational IDR

IDR received: I1 I2 ZABPQMCDU, ISDN plan, international type

PRECR:



PREA= IDR preanalysis file n (PREAID)

PRE= 13I 1 I 2

RCE= 5

CHA= 12

PRES= IDR preanalysis file n (PREAID)

PRECR:

PREA= IDR preanalysis file n (PREAID)

PRE= 12ZAB

ASS= SCCP routing to IN CS-1 server




7 New Service Observation Procedure


This chapter explains how to implement service observation.

Observing a new service involves checking that:

the service is triggered,

the observation counters are incremented,

there are no faults,

the new service is charged as specified.

This observation is equivalent to service acceptance testing. The procedure belowis one of several possible methods.

Procedure To observe a service during its initial activation:

a) Check that there are no fault messages.

If there are fault messages, check that they are explained by the manufacturer.

b) Check that the level 2 faults are active and the level 3 faults are disabled.

c) Trigger the service.

d) Check that no level 2 faults are generated.

If there are level 2 faults, see chapter 9.

e) Display the service load counters using the OCIN command (see FOP OCIN).

f) Release the service and check that no level 2 faults are generated.

If there are level 2 faults, see chapter 9.

g) Display the service observation counters (CTO or CHO counters).

h) Check the charging and observation results for the service.

i) End.



If there are no level 2 faults, set the level 3 fault screening function and trigger theservice again, then check for faults.


8 Existing Service Observation Procedure


This chapter explains how to observe an IN service during everyday use.

This observation option is used to check that:

the service is correctly used by the users,

the SSP does not generate any faults.

Procedure To observe an IN service during everyday use:

a) Use the permanent observation outputs (hourly or half-hourly counter classesC, F, I, R, T).

b) If necessary, display the peg counters and service load counters using the OCINcommand (see FOP OCIN).

c) If necessary, initiate observation of the results counters using the OCRLA com-mand (see FOP OCRLA).

d) If necessary, run the temporary observations:

To run an observation... use operation and maintenancesheet

of events on the O_BCSMOBOAB

OBOAP<x>

OBOFC

OBOFN

OBORV



To run an observation... use operation and maintenancesheet

of events on the T_BCSMOBOAB

OBOFC

OBORI

by countingOBOTD

OBODS<x>

OBOFD

e) Check that no faults are generated.

If faults are generated, see the Fault message dictionary, ANO283. Refer tothe type of fault (T) and the fault function (F).

Example: OFSGT T13F7

f) Depending on the observation analysis, arrange for a hardware reconfigura-tion of the SSP (increase in units, change of circuit assignments, etc.).

g) End.


9 Fault Management Procedure


This chapter describes IN-related faults and explains how to deal with them.

Procedure To deal with faults:

a) Check that there are no faults between the SCP and the SSP.

In particular, check that the following fault messages are not output:

INAP: OFINA T13F8,

SCCP/TCAP: OFSGT T13F7,

MTP: OFSTM T8F15.

b) Check that there are no faults between the SSP and the IP.

In particular check that no TUP type OFSUT T8F14 fault message is output.

c) Check that there are no faults between the SSP and the access points.

d) Check that there is no OFBOU fault.

e) If one of these faults exists, see the Fault message dictionary, ANO283. Referto the type of fault (T) and the function of the fault (F).

Example: OFSGT T13F7

If necessary, contact the manufacturer.

f) If there are faults inside the SSP, refer them to the manufacturer for possibleaction.

Identify the context in which the faults occur so that action will be easier.

g) End.




10 Intelligent Peripheral Management Procedure


This chapter explains how to manage intelligent peripherals (IP).

IP information:

The manufacturer is responsible for setting up an undefined type of IP on theSSP.

When the IP is installed, you must monitor the volume of calls to the IP.

You can make minor changes to the SSP’s IP data.

Procedure To manage IPs, you can:

Add an announcement associated with a service (new or otherwise) which usesan IP type already defined in the SSP data: attach an existing IP type to aservice.

Add a tone associated with a service (new or otherwise) which uses an IP typealready defined in the SSP data: attach an existing IP type to a service.

Add an external IP from a set of IPs of types known to the SSP.




Appendix A : Abbreviations


Abbreviation Meaning

ACC automatic congestion control

BCSM basic call state model

CCBS completion of calls to busy subscribers

CCF call control function

CEI internal failure code

CHO processed data periodic counter

CNIP calling name identification presentation

CS-1 capability set 1

CTO processed data peg counter

CUG closed user group

DP detection point

DSS1 digital subscriber signalling Nº 1

DTMF dual tone multifrequency

EDP event detection point

EDP-N event detection point - notification

EDP-R event detection point - request

ETSI European Telecommunications Standards Institute

FEX operating-maintenance sheet

FOP operator sheet

FSM finite state machine

GOP operator guide

IN intelligent network

IN CS-1 intelligent network capability set 1, based on the ITU-T standard

IN ER-1 INAP-ALCATEL protocol, specific to Alcatel 1000 E10 (OCB283)

INAP intelligent network application protocol

IP intelligent peripheral

ISDN integrated services digital network

ISDN UP ISDN user part

ITU-T International Telecommunications Union - Telecommunication Standardisation Sector

IVPN international virtual private network

MPNA Alcatel digital recorded announcement machine

MTP message transfer part

O-BCSM basic call state model-originating

PCM pulse code modulation

PIC point in call



Abbreviation Meaning

PLMN public land mobile network

PN personal number

PSTN public switched telephone network

REDA directory of customer application data

RGF frequency receiver and generator

ROC completion of calls to busy subscribers (CCBS)

SCC signalling congestion control

SCR selective circuit reservation

SCF service control function

SCP service control point

SDF service data function

SDP service data point

SIB service independent block

SMF service management function

SMP service management point

SRF specialised resource function

SS service subscriber

SU service user

SS Nº 7 signalling system Nº 7

SCCP signalling connection control part

SSF service switching function

SSF-FSM SSF finite state machine

SSP service switching point

SSUTR2 ISDN user part (version 2)

T-BCSM basic call state model - terminating

TCAP transaction capabilities application part

TDP trigger detection point

TDP-R trigger detection point - request

TUP telephone user part

UI user interaction

UPN universal personal number

VPN virtual private network


Appendix B : Meaning of CEIs

Appendix B : Meaning of CEIsCEIs (internal failure codes) are used by the call handling function to specify thecause of failure of a call. CEIs are a functional superset of the ISDN UP causes(ITU-T Recommendation Q.850).

Table 22 lists the CEIs and maps them with the ISDN UP standard causes.

Table 22 : Meaning of CEIs and mapping with standard causes

N CEI (internal failure code) N ISDN UP cause

001 Normal release 16 Normal release

002 Normal, unspecified 31 Normal, unspecified

004 Operating fault 41 Temporary failure

006 Exchange internal blocking - software 42 Switching equipment congestion

007 Switching network fault 42 Switching equipment congestion

008 Lack of circuits (local) 34 No circuit/channel available

009 Local congestion, software fault 38 Network out of order

010 Total screening or circuit group con-gested

42 Switching equipment congestion

013 No circuit available 34 No circuit/channel available

014 SP inaccessible 42 Switching equipment congestion

015 Address incomplete (timeout) 28 Invalid number format

017 No auxiliary resource (RGF, etc.) 42 Switching equipment congestion

018 Traffic regulation 42 Switching equipment congestion

019 Circuit group congestion (cause: direc-tionalisation)


031 No answer to call presentation 18 No user responding

032 Normal, unspecified (received remotely) 31 Normal, unspecified

033 Remote subscriber congestion 42 Switching equipment congestion

034 User busy (received remotely) 17 User busy

035 Switching equipment congestion 42 Switching equipment congestion

036 No circuit/channel available (remote) 34 No circuit/channel available

039 Unallocated number 1 Unallocated number

040 No routing to destination (code not used) 3 No route to destination

041 Destination out of order 27 Destination out of order

044 Service refused 29 Facility rejected

045 Bearer capabillity not implemented/net-work service not available or incompati-ble

65 Bearer capability not implemented/networkservice not available or incompatible

054 IN service interrupted (server call timeoutetc)

63 Service or option not available, unspecified




056 Normal call rejected (calling line identityrequired)

31 Normal, unspecified

057 Partial screening 42 Switching equipment congestion

066 Forward resource not available 47 Resource unavailable, unspecified

067 Local subscriber out of order 27 Destination out of order

070 Server call rejected 21 Call rejected

071 National network congestion 34 No circuit/channel available

073 Subscriber intercepted 25 Subscriber intercepted

074 User not member of CUG 87 User not member of CUG

081 Protocol error received from forward re-source (classes 110 and 111)

111 Protocol error, unspecified

083 Outgoing call control 42 Switching equipment congestion

087 Switching equipment (transit) congestion 42 Switching equipment congestion

103 Called party transferred 22 Number changed

104 Subscriber suspended 27 Destination out of order

106 Digital connection not allowed 34 No circuit/channel available

111 Subscriber or group busy, call forwarding 17 User busy

113 Call gapping leading to congestion 34 No circuit/channel available

116 Remote ISUP unavailable 42 Switching equipment congestion

120 Failure on ACC rejection 42 Switching equipment congestion

121 Failure on SCC rejection 42 Switching equipment congestion

123 Local subscriber absent 20 Subscriber absent

127 Circuit group congestion/no channelavailable (transit)

34 No circuit/channel available

129 Channel type not implemented 79 Service or option not implemented, unspecified

130 CUG does not exist 90 CUG does not exist

131 Facility rejected: requested facility notsubscribed

50 Requested facility not in subscription

132 Outgoing calls barred within CUG 53 Outgoing calls barred within CUG

133 Incoming calls barred within CUG 55 Incoming calls barred within CUG

134 Requested facility not implemented 69 Requested facility not implemented

135 Bearer capabillity not authorised 57 Bearer capability not authorised

136 Bearer capability not presently available 58 Bearer capability not presently available

137 Circuit group congestion/no channelavailable (received from far end)


138 Recovery on timer expiry. Await release 102 Recovery on timer expiry

139 Message type does not exist or not im-plemented

97 Message type does not exist or not imple-mented




140 Information element does not exist or notimplemented

99 Information element/parameter does not existor not implemented

141 No answer from user (user alerted) 19 No answer from user (user alerted)

143 Group congested 17 User busy

144 User busy (CCBS possible) 17 User busy

156 User busy (not in conversation phase) 17 User busy

157 User busy (local) 17 User busy

158 Permanent line condition 27 Destination out of order

160 No answer on call presentation 18 No user responding

161 No answer from ISDN user 18 No user responding

162 Called party not provisioned 27 Destination out of order

163 No answer, call waiting indication fromanalogue subscriber

19 No answer from user (user alerted)

168 Channel not free (local subscriber) 42 Switching equipment congestion

169 Channel not free (no path) 42 Switching equipment congestion

170 Total screening or circuit group conges-tion


171 Partial screening (circuit group conges-tion)


172 Circuit under test 42 Switching equipment congestion

173 Circuit blocked 42 Switching equipment congestion

174 Circuit not available 34 No circuit/channel available

204 Called party under test 17 User busy

208 Call gapping leading to total congestion 34 No circuit/channel available

210 Circuit group congestion in channel as-sociated signalling mode


211 Interworking, unspecified 127 Interworking, unspecified

212 Normal call rejected (calling line identityrequired)

95 Invalid message, unspecified

213 Subscriber absent (received from far end) 20 Subscriber absent

215 Requested circuit/channel not available 44 Required circuit/channel not available

216 Incompatible destination 88 Incompatible destination

217 Line out of service 27 Destination out of order

219 Local line out of order 27 Destination out of order

221 Failure on SCR rejection (selective circuitreservation)


242 Only one restricted digital informationcapability is available

70 Only the digital bearer service with restrictionis available




243 Choice of transit network not valid 91 Choice of transit network not valid

244 No routing to required carrier 2 No routing to the specified transit network


Glossary

Glossary

Note : For the meanings of the abbreviations, see Appendix A.

basic call Call set up between two users that does not use supplementary services.

basic call state model(BCSM)

A high level finite state machine which models the handling associated with thebasic call.

This model can relate to only a part of the call, for example in the case of anoriginating or terminating BCSM, or the complete switchpath for the required call,from the caller to the called party.

call control function (CCF) An application process which handles and controls calls/connections.

capability set (CS) A coherent and logical set of intelligent network capabilities that have been stan-dardised in a publication.

detection point (DP) Point in the basic call handling process in which an event relating to call handlingcan be reported to the service control function and in which a call handling com-mand can be generated.

event detection point(EDP)

Detection point activated for a given instance of a call.

IN service Service provided using the capabilities of the intelligent network.

intelligent peripheral (IP) A physical entity that performs the specialised resource function.

leg The representation in a basic call state model of a telecommunication channelleading to a certain addressable entity (for example, a channel leading to a user,to an intelligent peripheral unit, etc.).

point in call (PIC) A state in a basic call state model.

service control function(SCF)

Application of the service logic to the control of functional entities when supplyingintelligent network services.

service control point (SCP) A physical entity of the intelligent network that performs a service control function.

service logic (SL) A sequence of processes or functions serving to handle a specific service.

service subscriber (SS) An entity that has signed an agreement to receive services provided by serviceproviders.

service switching function(SSF)

A set of processes that provide the call path for interaction between a call controlfunction and a service control function.

service switching point(SSP)

A physical entity that performs the service switching function.

service user (SU) An entity external to the network which uses the services.

specialised resourcefunction (SRF)

A set of functions that provide control of and access to the resources used toprovide services.

trigger A set of data (detection point, access type, trigger criteria) that defines the condi-tions for triggering a service.

trigger detection point(TDP)

Detection point activated statically in the basic call process.


Glossary


Index

IndexA

Access typelist of . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29of a trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

B

BCSMdefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

C

Call screeningauthorisation of . . . . . . . . . . . . . . . . . . . . . . . . . . 56introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45role of the service creator . . . . . . . . . . . . . . . . . . 45service declaration . . . . . . . . . . . . . . . . . . . . . . . 45

CCFdefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

CEIcriterion 5 : using . . . . . . . . . . . . . . . . . . . . . . . . 62mapping with standard causes . . . . . . . . . . . . . 85meaning of . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85server failure management . . . . . . . . . . . . . . . . 54

Chargingin the IN context . . . . . . . . . . . . . . . . . . . . . . . . . . 40management data . . . . . . . . . . . . . . . . . . . . . . . . 55

Circuit group categoryCATBI parameter . . . . . . . . . . . . . . . . . . . . . . . . . 61introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Circuit group management- in the IN context . . . . . . . . . . . . . . . . . . . . . . . . 41

Criteria parametersCATBI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61CEI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62COMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61COSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64IDXNUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60INDBI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66LOCDEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62MRQBI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61NOSERV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60NTDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63PNUE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63TMR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63TSAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66TSAI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66TSPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64TSPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

D

Detection point, See DPDPdefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89EDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21list of . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28TDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

E

EDPdefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

F

FaultOFBOU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79OFINA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79OFSGT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79OFSTM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79OFSUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

FICPTBdescription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

FICPTFdescription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

FIDCLEdescription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

FISERVdescription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

FITRIGdescription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Follow-on callsintroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

I

IN architecturefunctions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10physical entities . . . . . . . . . . . . . . . . . . . . . . . 9, 10

IN ER-1accessing a service . . . . . . . . . . . . . . . . . . . . . . . 69interworking loops . . . . . . . . . . . . . . . . . . . . . . . . 36


Index

service priority . . . . . . . . . . . . . . . . . . . . . . . . . . . 70IN servicedata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31data organisation . . . . . . . . . . . . . . . . . . . . . . . . 50declaring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89freephone call . . . . . . . . . . . . . . . . . . . . . . . . . . . 13incompatibilities . . . . . . . . . . . . . . . . . . . . . . 24, 58introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16observing a new . . . . . . . . . . . . . . . . . . . . . . . . . 75principles of use . . . . . . . . . . . . . . . . . . . . . . . . . . 50script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17service index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52service types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12trigger criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . 59universal personal number . . . . . . . . . . . . . . . . 15

INAPINAP operations . . . . . . . . . . . . . . . . . . . . . . . . . . 18introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18SCP-IP dialogue . . . . . . . . . . . . . . . . . . . . . . . . . . 17SSP-IP dialogue . . . . . . . . . . . . . . . . . . . . . . . . . . 17SSP-SCP dialogue . . . . . . . . . . . . . . . . . . . . . . . . 17

INAP protocol, See INAPIntelligent peripheral, See IPInterworking loopintroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36looped outgoing cases . . . . . . . . . . . . . . . . . . . . 36observation and redimensioning . . . . . . . . . . . 47types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

IPdefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89external . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32in the IN architecture . . . . . . . . . . . . . . . . . . . . . 10integrated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89SCP-IP dialogue . . . . . . . . . . . . . . . . . . . . . . 17, 32SRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32SSP-IP dialogue . . . . . . . . . . . . . . . . . . . . . . . . . . 17

L

Legcircuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20subscriber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

M

multi-SCPAFTAP parameter . . . . . . . . . . . . . . . . . . . . . . . . . 54ATIDR parameter . . . . . . . . . . . . . . . . . . . . . . . . . 57implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 71

O

Observations- in the IN context . . . . . . . . . . . . . . . . . . . . . . . . 44of a new service . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Operationcharging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40circuit group management . . . . . . . . . . . . . . . . . 41observations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44signalling network management . . . . . . . . . . . . 43subscriber management . . . . . . . . . . . . . . . . . . . 42translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Operator guidecontents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7is this guide for you? . . . . . . . . . . . . . . . . . . . . . . . 7purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7related documentation . . . . . . . . . . . . . . . . . . . . . 8

S

SCFdefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

SCPdefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89in the IN architecture . . . . . . . . . . . . . . . . . . . . . 10SCP-IP dialogue . . . . . . . . . . . . . . . . . . . . . . 17, 32SSP-SCP dialogue . . . . . . . . . . . . . . . . . . . . . . . . 17

SDPin the IN architecture . . . . . . . . . . . . . . . . . . . . . 10

Service parameterABORT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54AFTAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54, 72ATFNUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57ATIDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57, 72ATNCHF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57CDATAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55CLEF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53CMTAXR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55CTNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56ETNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56FIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56IDSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53NCHF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57NOASS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53OUVRT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54PILOT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56PSTCD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57, 72RQTAXR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55RQTAXS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55STNEMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56VPRO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53VPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

Service switching point, See SSPSignalling network management- in the IN context . . . . . . . . . . . . . . . . . . . . . . . . 43


Index

SMPin the IN architecture . . . . . . . . . . . . . . . . . . . . . . 9

SRFdefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33local SRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33relay SRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

SSFdefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

SSPCCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20in the IN architecture . . . . . . . . . . . . . . . . . . . . . 10role of . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19SSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21SSP-IP dialogue . . . . . . . . . . . . . . . . . . . . . . . . . . 17SSP-SCP dialogue . . . . . . . . . . . . . . . . . . . . . . . . 17

Subscriber categoryCATBI parameter . . . . . . . . . . . . . . . . . . . . . . . . . 61introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Subscriber management- in the IN context . . . . . . . . . . . . . . . . . . . . . . . . 42

Subscriber markintroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42MRQBI parameter . . . . . . . . . . . . . . . . . . . . . . . . 61

T

TDPdefinition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Tied callsintroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Translationin the IN context . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Triggercharacteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27priority management . . . . . . . . . . . . . . . . . . . . . 68

Trigger criteriaconditions of use . . . . . . . . . . . . . . . . . . . . . . . . . 59criteria allowed . . . . . . . . . . . . . . . . . . . . . . . . . . 29criterion 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60criterion 01 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60criterion 02 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61criterion 03 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61criterion 04 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61criterion 05 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62criterion 06 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63criterion 07 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63criterion 08 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64criterion 09 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64criterion 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

criterion 11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65criterion 12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66criterion 13 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66criterion 16 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66criterion 17 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66definition of . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59list of . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Trigger prioritiesfor an IN ER-1 service . . . . . . . . . . . . . . . . . . . . . 70managing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68


Date post:	07-Oct-2014
Category:	Documents
Upload:	ndluong
View:	50 times
Download:	3 times