SINAP/SS7 Technical Overview -...

Part Number: R8055-16

January 2005

SINAP/SS7 Technical Overview

Stratus TechnologiesR8055-16

SINAP/SS7 Technical Overview

Notice

The information contained in this document is subject to change without notice.

UNLESS EXPRESSLY SET FORTH IN A WRITTEN AGREEMENT SIGNED BY AN AUTHORIZED REPRESENTATIVE OF STRATUS TECHNOLOGIES, STRATUS MAKES NO WARRANTY OR REPRESENTATION OF ANY KIND WITH RESPECT TO THE INFORMATION CONTAINED HEREIN, INCLUDING WARRANTY OF MERCHANTABILITY AND FITNESS FOR A PURPOSE. Stratus Technologies assumes no responsibility or obligation of any kind for any errors contained herein or in connection with the furnishing, performance, or use of this document.

Software described in Stratus documents (a) is the property of Stratus Technologies Bermuda, Ltd. or the third party, (b) is furnished only under license, and (c) may be copied or used only as expressly permitted under the terms of the license.

Stratus documentation describes all supported features of the user interfaces and the application programming interfaces (API) developed by Stratus. Any undocumented features of these interfaces are intended solely for use by Stratus personnel and are subject to change without warning.

This document is protected by copyright. All rights are reserved. No part of this document may be copied, reproduced, or translated, either mechanically or electronically, without the prior written consent of Stratus Technologies.

Stratus, the Stratus logo, ftServer, Continuum, Continuous Processing, StrataLINK, StrataNET, DNCP, SINAP, and FTX are registered trademarks of Stratus Technologies Bermuda, Ltd.

The Stratus Technologies logo, the ftServer logo, Stratus 24 x 7 with design, The World’s Most Reliable Servers, The World’s Most Reliable Server Technologies, ftGateway, ftMemory, ftMessaging, ftStorage, Selectable Availability, XA/R, SQL/2000, The Availability Company, RSN, and MultiStack are trademarks of Stratus Technologies Bermuda, Ltd.

Hewlett-Packard, HP, and HP-UX are registered trademarks of Hewlett-Packard Company. Sun, Solaris, Netra, and SunFire are trademarks or registered trademarks of Sun Microsystems, Inc. SPARC is a registered trademark of SPARC International, Inc. UNIX is a registered trademark of X/Open Company, Ltd., in the U.S.A. and other countries. The registered trademark Linux(R) is used pursuant to a sublicense from the Linux Mark Institute, the exclusive licensee of Linus Torvalds, owner of the mark on a world-wide basis. All other trademarks are the property of their respective owners.

Manual Name: SINAP/SS7 Technical Overview

Part Number: R8055Revision Number: 16 Updated for SINAP/SS7 Release Number: 14.2Publication Date: January 2005

Stratus Technologies, Inc.111 Powdermill RoadMaynard, Massachusetts 01754-3409

© 2005 Stratus Technologies Bermuda, Ltd. All rights reserved.

Contents

Preface xiThe Purpose of This Manual xiAudience xiRevision Information xiManual Organization xiNotation Conventions xiiRelated Manuals xiii

A Note on the Contents of Stratus Manuals xivAccessing Documentation xivCommenting on the Documentation xiv

Contacting the CAC xiv

1. Introduction to SINAP/SS7 1-1Background Information 1-1What is SINAP/SS7? 1-2

MultiStack 1-4Multivariant Feature 1-5Features, Benefits, and Uses of SINAP/SS7 1-6

2. SINAP/SS7 Architecture 2-1System Overview 2-1SS7 Stack Components 2-2

Message Transfer Part (MTP) 2-2Signaling Network Management 2-4Signaling Message Handling 2-6MTP Time-Controlled Changeover (TCCO) 2-7MTP Restart 2-9

Signaling Connection Control Part (SCCP) 2-12Global-Title Addressing 2-13Connection-Oriented Services 2-15XUDT and XUDTS Message Handling 2-16

Transaction Capabilities Applications Part (TCAP) 2-17Integrated Services Digital Network User Part (ISUP) 2-17

Basic Bearer Services 2-18

Contents v

Contents

Supplementary Services 2-18Defining ISDN User Part (ISUP) Functionality 2-18

SS7 Signaling Unit Types 2-20Error Detection and Correction 2-21SS7 Driver Subsystem 2-21SS7 Input/Output (I/O) Adapter Subsystem 2-21

Application Development and Deployment Components 2-22Client Applications 2-23

Common Application Services Layer (CASL) 2-24ISUP Services Support Library (ISSL) 2-26

Node Management and Built-In Test Components 2-26Node Management Subsystem 2-26Configuration and Operations 2-28Built-In Test Environment (BITE) 2-28

BITE Limitations 2-30BITE Monitor 2-30BITE Log Analysis Program 2-31

SINAP/SS7 Configuration Parameters 2-31

3. SINAP/SS7 Product Features 3-1Value-Added Features 3-1

MultiStack 3-2Using MultiStack 3-2

Standards Support for Older Versions 3-2Periodic Link Testing 3-2

Loopback Mode 3-3Enhanced Message Distribution 3-3

Enhanced Routing Capabilities 3-4Route Set Initialization 3-5Custom Application Distribution 3-5ISUP Services Feature 3-6Load Control 3-7Simple Network Management Protocol (SNMP) (supported in HP-UX only) 3-8

System Components 3-8Application Environment 3-9

Partial Global Title Translation 3-10Distributed Logical Point Code (DLPC) 3-10

Highlights of SS7 Standards Implementation 3-11Signaling Link Selection (SLS) Routing 3-12Random SLS Generation (ANSI) 3-12

Random Link Selection 3-12Eight-bit SLS Processing (ANSI) 3-12MTP User Flow Control 3-13

vi SINAP/SS7 Technical Overview R8055-16

Defining UPU Messages 3-13 Link Congestion Levels 3-14

Variant Differences 3-14Congestion States 3-14Automatic Congestion Control (ACC) 3-15Changing System Tables 3-15

Duplicate Concerned Point Codes (DUCPC) 3-15Network and Cluster Routing (ANSI and China) 3-16

Dynamic Route Provisioning (ANSI and China Variants) 3-17Transfer Restricted Message (TFR) 3-18RSC Message Handling 3-18Determining a Local Processor Outage Condition 3-19

System Administration Features 3-19SINAP/SS7 Logs 3-19Logging SINAP/SS7 Alarms and Error Messages 3-20

Operating System Error Log Files 3-20Measurements 3-22

Report Measurement Considerations 3-25System Debugger 3-25Automatic Configuration Re-creation 3-26Automated Start-up Procedures 3-26

Starting the SINAP/SS7 Systems With the start_sinap Script File 3-26Automatically Restarting SINAP/SS7 from the UNIX Initialization File 3-26Starting a Client Application 3-26

Accessing the User Interface 3-27Terminal Handler 3-28UNIX MML Command Line 3-30

Online Help Documentation (Man Pages) 3-30

4. Hardware and Software Requirements 4-1Disk Space 4-2Hardware Interfaces 4-3U91x Card Clocking 4-3

5. Standards Compliance 5-1Standards Support 5-1

ITU-T (CCITT) Recommendations 5-1ANSI Standards 5-1TTC Standards (Japan) 5-2NTT Standards (Japan) 5-2

Contents vii

Contents

China Specifications 5-2Advantages of the 1993 TCAP Standards 5-5

Index Index-1

viii SINAP/SS7 Technical Overview R8055-16

Figures

Figures ix

Figures

Figure 1-1. Prepackaged Solutions and Development Capabilities 1-2Figure 1-2. SINAP Overview 1-3Figure 1-3. Possible SINAP/SS7 Configurations 1-4Figure 2-1. Major SINAP/SS7 Components 2-1Figure 2-2. Message Transfer Part (MTP) Overview 2-3Figure 2-3. Signaling Network Management Overview 2-4Figure 2-4. Signaling Traffic Management Overview 2-5Figure 2-5. Signaling Message Handling Overview 2-6Figure 2-6. SINAP Architecture 2-13Figure 2-7. Application Development and Deployment Components 2-23Figure 2-8. SINAP Node Management 2-27Figure 2-9. BITE Trace Points 2-29Figure 3-1. SINAP/SNMP Process Model 3-10Figure 3-2. Measurements Commands Menu 3-23Figure 3-3. Report Measurements Menu 3-23Figure 3-4. Report Sample Screen 3-24Figure 3-5. SINAP/SS7 Menu Hierarchy 3-29

Tables

x SINAP/SS7 Technical Overview R8055-16

Tables

Table 1-1. Valid Stack Configurations 1-5Table 2-1. STM Processes 2-5Table 2-2. Valid ISUP Versions and Network Variants 2-19Table 2-3. SINAP/SS7 Configuration Limitations 2-32Table 3-1. Valid ISUP Versions and Network Variants 3-6Table 3-2. SINAP/SS7 Point Code Formulas 3-17Table 3-3. SINAP/SS7 Logs 3-19Table 3-4. SINAP Alarm Severity Messages 3-21Table 4-1. SINAP/SS7 Hardware and Software Requirements 4-1Table 4-2. Maximum Number of Communication Cards per System 4-2Table 4-3. SINAP Disk Space Requirements 4-2Table 5-1. Standards Supported by SINAP/SS7 5-3

Preface

The Purpose of This ManualThe SINAP/SS7 Technical Overview (R8055) describes the Stratus Intelligent Network Applications Platform (SINAP) SS7 product, which operates on the Stratus ft Linux®, HP-UX™ and Solaris operating systems. It describes how the SINAP/SS7 system operates and interfaces to the Signaling System 7 (SS7) network. For information about operating, reconfiguring, and maintaining the SINAP/SS7 system, refer to the SINAP/SS7 User’s Guide (R8051).

AudienceThis document is intended for customers and other personnel who want to gain a technical description of the SINAP/SS7 system. This document assumes the reader has a working knowledge of the SS7 protocol and the UNIX operating system and utilities. For additional information, see the SINAP/SS7 User’s Guide (R8051).

Revision InformationThis manual has been revised with miscellaneous corrections to existing text for the SINAP/SS7 14.2 release, and the enhancement of Partial GTT support for ANSI, China, and TTC variants.

Manual OrganizationThis manual is divided into the following chapters:

• Chapter 1 “Introduction to SINAP/SS7” explains what the SINAP/SS7 product is, its capabilities, and identifies the key features and benefits.

• Chapter 2 “SINAP/SS7 Architecture” provides a technical overview of the SINAP/SS7 architecture.

• Chapter 3 “SINAP/SS7 Product Features” describes the value-added SS7 features provided by the SINAP/SS7 system.

• Chapter 4 “Hardware and Software Requirements” details the operating systems, disk space, and hardware interfaces for SINAP/SS7 installation.

• Chapter 5 “Standards Compliance” details SINAP/SS7 compliance to applicable recommendations and standards.

Preface xi

Notation Conventions

Notation ConventionsThis manual uses the following notation conventions.

• Monospace represents text that would appear on your display screen (such as commands, functions, code fragments, names of files and directories, and user input). For example:

The alternative format for CHANGE-REMSSN is CHG-REMSSN.

• Monospace italic represents terms that are to be replaced by literal values. In the following example, the user must replace the monospace-italic term with a literal value. For example:

The nmtr program has the following syntax (where filename is the name of the file to be converted).

• Monospace bold represents user input in examples and figures that contain both user input and system output (which appears in monospace).

• For example:

• Italics introduces or defines new terms. For example:

The Terminal Handler accepts commands in Man-Machine Language (MML).

• Boldface emphasizes words in text. For example:

You must create a link set before you provision its member links.

• The dollar sign ($) and the number sign (#) are standard default prompt signs that have a specific meaning at the UNIX prompt.

• $ indicates you are logged in to a user account and are subject to certain access limitations.

• # indicates you are logged in to the system administrator account and have superuser access. Users of this account are referred to as root. The # prompt sign used in an example indicates that the command can only be issued by root.

MML as built is CREATE-CPC:Specify local subsystem number: LSSN=253LSSN=253Specify point codes for the remote node:(pc# or pc#1&pc#2... up to pc#10)RPC=3003LSSN=253,RPC=3003

xii SINAP/SS7 Technical Overview R8055-16

Related Manuals

N O T EThere is an implied pressing of the RETURN key at the end of each command and menu response that you enter.

• When the full path name of a command appears in an example (for example, /etc/fsck), you must enter the command exactly as it appears.

This manual uses the format conventions for documenting commands as shown in the following example.

Related ManualsRefer to the following Stratus manuals for related documentation:

• SINAP Products Glossary (R8010)

• SINAP/SS7 User’s Guide (R8051)

• SINAP/SS7 Programmer’s Guide (R8052)

• SINAP/SS7 ISDN User Part (ISUP) Guide (R8053)

Notation Meaning

argument_1 Required argument. You cannot issue the command without supplying a value for this argument. If an argument is required but has a default value, it is not labeled required because you do not have to include it.

argument_1... Required argument for which you can specify multiple values.

« » Set of arguments that are mutually exclusive; you can specify only one of these elements.

[argument_1] Optional argument.

[argument_1]... Optional argument for which you can specify multiple values.

« » Set of optional arguments that are mutually exclusive; you can specify only one of these elements.

Note: Dots, brackets, and braces are not literal characters; you should not type them. Any list or set of arguments can contain more than two elements. Brackets and braces are sometimes nested.

element_1 element_2

argument_1argument_2

Preface xiii

Contacting the CAC

• SINAP/SS7 Installation Guide (R8060)

• SINAP/SNMP MIB Guide (R8065)

• SINAP/SS7 Quick-Start Guide (R8070)

• U916 T1/E1 PCI Card Installation Guide (R761)

• U918 T1/E1 PCI Card Installation Guide (R760)

A Note on the Contents of Stratus ManualsStratus manuals document subroutines and commands of the user interface. Any other commands and subroutines contained in the operating system are intended solely for use by Stratus personnel and are subject to change without warning.

Accessing DocumentationSINAP product documentation is provided on CD-ROM. You can request a documentation CD-ROM in either of the following ways:

• Call the CAC (see ‘‘Contacting the CAC”).

• If your system is connected to the Remote Service Network (RSN), add a call using the Site Call System (SCS). See the scsac(1) man page for more information.

When requesting a documentation CD-ROM, please specify the product and platform documentation you desire, as there are several documentation CD-ROMs available.

Commenting on the Documentation

To provide corrections and suggestions for improving this documentation, send email to [email protected]. If it is possible, please include the title and part number from the Notice page and the page numbers.

This information will assist Stratus Publications in making any needed changes to the documentation. Your assistance is most appreciated.

Contacting the CACIf you need assistance, contact your local systems engineer, or telephone the Stratus Customer Assistance Center (CAC) that services your area. If you cannot reach the center that services your area, contact the CAC in the United States.

The table below lists the CAC telephone numbers, all of which are available 24 x 7. For the most current list of CAC telephone numbers, see the following Web site: http://www.stratus.com/support/cac.

xiv SINAP/SS7 Technical Overview R8055-16

Contacting the CAC

*For the countries of Belgium, Denmark, Luxembourg, The Netherlands, Norway, and Sweden,you can also use the following toll-free number to call after hours: 00800-000-99999. Your call will be directed to Phoenix Support Coordination.

N O T E S1. The plus sign (+) indicates that an international access code

is required. The access code for international calls varies from country to country; in the United States, it is 011.

Worldwide CAC Telephone Numbers

Customer Assistance Center (CAC) Telephone Numbers

North America, Central America, and South America

800-221-6588 (toll-free within USA or Canada)

800-828-8513 (toll-free within USA or Canada)

+1-978-461-7200 (Maynard, MA; for local and international direct)

+1-602-852-3200 (Phoenix, AZ; for local and international direct)

Australia 1800-025-046 (toll-free within Australia)

Belgium* +32 2-512-63-70 (Dutch language)

+32 2-512-77-06 (French language)

France +33 (0) 1-41-20-37-08

Germany +49 (0) 6196-472518

Hong Kong 800-900-938 (toll-free within Hong Kong)

Italy +39 02-467440-216

Japan 0120-725530

Mexico +52 55-5553-4792

The Netherlands* +31 (0) 346-582-112

New Zealand 0800-443-051 (toll-free within New Zealand)

People’s Republic of China

+86 139-010-39512 (Beijing)

+86 21-63877700 (Shanghai)

Singapore 1800-2727482 (toll-free within Singapore)

South Africa +27 11-2675-709

Spain +34 91-383-4294

United Kingdom +44 (0) 1784-246056

Preface xv

Contacting the CAC

2. When you call from within the same country as the CAC office, be sure to include any necessary long distance or STD call prefix. If you use an international telephone number within the same country, you must replace the country code with the necessary prefix. For example, within the United States, callers dial 1-800-221-6588.

3. The telephone numbers in the preceding list are for CACs operated by Stratus. If you receive service from a distributor of Stratus products, contact your distributor for instructions about obtaining assistance.

xvi SINAP/SS7 Technical Overview R8055-16

Chapter 1Introduction to SINAP/SS71-

This document provides a technical overview of the Stratus Intelligent Network Applications Platform (SINAP) SS7 product. It demonstrates how Stratus is uniquely positioned to be the vendor of choice for your telecommunications needs.

Background InformationCurrently, nearly all of the world’s largest telecommunications companies rely on fault-tolerant Stratus systems. Stratus markets its systems to:

• RBOCs (Regional Bell Operating Companies)

• Independent Telephone Companies

• PTTs (Postal, Telegraph, and Telephone agencies)

• Inter-Exchange Carriers

• Cable Companies

• Cellular Providers

Telecommunications firms choose Stratus’s powerful computing platforms to run critical, online applications requiring 24-hour processing. Stratus systems are ideally suited for:

• Intelligent Networks (IN)

• Advanced Intelligent Networks (AIN)

• SS7 Signaling Gateway Services

• Multimedia and Informations Services

• Operations and Business Systems

A SINAP node serves as a base for prepackaged IN applications and services (see Figure 1-1). With direct access to SS7 functions, development tools layered on top of a SINAP node allow users to create customized applications and deploy new network services in a relatively short time frame.

Introduction to SINAP/SS7 1-1

What is SINAP/SS7?

Figure 1-1. Prepackaged Solutions and Development Capabilities

What is SINAP/SS7?The SINAP/SS7 system is a network-services development and implementation platform. This platform is Stratus SS7 Intelligent Network middleware platform that supports the Stratus SS7 Gateway and other products in the SINAP family. With its SS7 capabilities and associated layered development tools, the SINAP/SS7 platform speeds the introduction of new services, simplifies development, cuts product life cycle costs, and expedites the conversion or migration to an SS7 infrastructure. The SINAP/SS7 platform’s versatility, including direct application access to integral SS7 stack functions, makes it an ideal platform for system integrators, value-added resellers, and third-party applications developers. It is the solution for today’s competitive marketplace where the demand for new services and features is rapidly changing.

You can configure a SINAP/SS7 node to function as:

• Service Control Point (SCP)

• Adjunct Processor (AP)

• Service Node (SN) in an SS7 network

Prepackaged Solutions

Short Message Service

Rules-Based Routing

Calling Card Validation

Enhanced N00

Development Capabilities

Icon Development

SIB Development

Service Creation EnvironmentService IndependentBuilding Blocks (SIBs)

SINAPStratus Intelligent Network Applications Platform

Intelligent Network

1-2 SINAP/SS7 Technical Overview R8055-16

What is SINAP/SS7?

Applications running on a SINAP/SS7 node can initiate queries to the SS7 network and respond to queries from the network. Figure 1-2 illustrates an overview of the SINAP/SS7 architecture.

Figure 1-2. SINAP Overview

Application

CASL/ISSL Interface

ISUP SCCP

TCAP

MTP 1-3

BITENodeManagement

SINAP

SS7 Network

T1/E1 V.35


What is SINAP/SS7?

MultiStackThe SINAP/SS7 product comes in two sizes, SINAP (unistack) and MultiStack. The SINAP option supports a single SS7 stack. The MultiStack option provides the ability to run up to four SINAP nodes on a single HP-UX, Solaris, or Stratus ft Linux operating system, where each node contains a single instance of the SINAP software and is configured as a separate point code in the same network or in different networks. Figure 1-3 illustrates possible configurations.

Figure 1-3. Possible SINAP/SS7 Configurations

Throughout this document, SINAP/SS7 refers to either the SINAP or MultiStack product, whichever is running on your system. SINAP node and SINAP stack refer to a single instance of the SINAP product running on your system. With MultiStack, you can have multiple SINAP stacks on your system; with the SINAP software, you can have only one SINAP stack. SINAP variant refers to the type of SS7 protocol (ANSI, ITU-T, TTC, NTT, or China) configured to run on a particular SINAP node.

Node 1PC=3001

Node 2PC=3002

Node 3PC=3003

Node 4PC=3004

Network

Configuration ADifferent point codes in the same network

Node 1PC=3003

Node 2PC=3003

Node 3PC=3003

Node 4PC=3003

Configuration BSeparate point codes in different networks

Legend

PC - Point Code

SINAP Module

SINAP Node

Network 1

Network 2

Network 3

Network 4


What is SINAP/SS7?

Multivariant FeatureThe multivariant feature enables the SINAP/SS7 system to extend the types of SS7 stack configurations you can run on a node by allowing you to separately configure the node’s network and Transaction Capabilities Application Part (TCAP) variants. Each SINAP/SS7 node has the following two variants associated with it:

• The network variant defines the SS7 protocol (ANSI, ITU-T, TTC, NTT, or China) to use for the node’s Message Transfer Part (MTP) and Signaling Connection Control Part (SCCP).

• The TCAP variant defines the protocol to use for the node’s TCAP.

Table 1-1 lists the valid combinations of network and TCAP variants, along with the type of SS7 stack configuration that each combination produces.

The SINAP/SS7 system provides SS7 connectivity with the option of using Stratus X.25 and Integrated Services Digital Network (ISDN) products to interface to:

• a service management system (SMS)

• an operations, administration, and management (OA&M) system

• a network management application

The SINAP/SS7 system provides the OA&M tools to create and administer the SS7 resources that allow the SINAP/SS7 system to function as an operational node. The SINAP/SS7 system also provides the specialized tools for developing and deploying IN and AIN network services.

Table 1-1. Valid Stack Configurations

SS7 Stack ConfigurationNetwork (MTP & SCCP) Variant

TCAP Variant

Standard ITU-T (CCITT) ITU-T ITU-T

Standard ANSI ANSI ANSI

Standard TTC TTC ITU-T

Standard NTTStandard NTT-IC

NTT ITU-T

Standard China China ITU-T

Hybrid ITU-T ITU-T ANSI

Hybrid ANSI ANSI ITU-T

Hybrid TTC TTC ANSI


What is SINAP/SS7?

Features, Benefits, and Uses of SINAP/SS7The SINAP/SS7 system operates on the HP-UX , Solaris, and ft Linux operating systems. The SINAP/SS7 system offers an application development platform for developing AIN or IN solutions that interoperate among multiple networks. It provides the following features and benefits:

• Prepackaged solutions, such as Enhanced N00 and Calling Card Verification, that comply with industry standards

• Support for national and international standards for SS7:

— International Telecommunications Union (ITU-T) formerly known as the International Telegraph & Telephone Consultative Committee (CCITT)

— American National Standards Institute (ANSI)

— Telecommunications Technology Committee (TTC) of Japan

— Nippon Telephone and Telegraph (NTT) of Japan

— National Telephone Network of China

• Support for the physical interfaces V.35, RS-232, RS-422, and T1/E1

• A complete SS7 protocol stack with many enhancements to simplify the creation of network services

• An application programming interface (API) to the Common Application Services layer (CASL) that contains functions for developing applications that interface to SS7 at the following layers:

— Message Transfer Part (MTP)

— Signaling Connection Control Part (SCCP)

— Transaction Capabilities Application Part (TCAP)

• An API to the ISUP Services Support Library (ISSL) that contains functions for developing applications that interface to SS7 at the ISDN User Part (ISUP) layer

• Support for application development toolkits and platforms to simplify creating network services, such as:

— SINAP/IN

— NavisAccess

— International Telecommunications Union Standards (ITU-T) Service Independent Building Blocks (SIB)


What is SINAP/SS7?

• Support for third-party applications providing a variety of network services, such as:

— Short Message and Single Number Services

— Network Management

— Signaling Message Conversion Services

— X.400 Message Handling

— Voice Response

• Support for country specific implementations of ISUP services and the support of ISUP message sets based on ISUP standards for specific countries.

• A node management feature to centralize application and node management on a single system

• A Built-In Test Environment (BITE) network simulation tool to test, monitor, and debug applications without affecting normal SINAP operation

• Enhanced message distribution to provide a mechanism for defining the criteria that routes incoming message signaling units (MSUs) to their custom application destinations

• A load control utility that enables client applications to maintain maximum throughput during periods of extreme work congestion

The SINAP/SS7 system provides a software-based environment that enables you to rapidly create and deploy new IN or AIN network services. By off loading the network services functionality from the network switch to the SINAP/SS7 platform, you can easily extend the functionality of your applications without modifying or developing new network-switch programs.

Typical SINAP/SS7 applications provide the following types of services:

• Enhanced 800 and 900 number translation services

• Generic number translation services

• Local Number Portability (LNP) services

• Signaling Gateway services

• Home Location Register (HLR) services

• Service Location Register (SLR) services

• Alternate Billing Services (ABS) for calling and credit cards

• Network services for Private Virtual Networks (PVN)

• Network services for Personal Communications Networks (PCN)

• Televoting

• Automatic Call Distribution and routing services for load balancing


What is SINAP/SS7?

• 911 Network Services


Chapter 2SINAP/SS7 Architecture2-

System Overview System functionality can be divided into three major component areas:

1. SS7 stack components

2. Application development and deployment components

3. Node management and built-in test components

Figure 2-1 provides a high-level view of the major components, but does not depict all subsystems.

Figure 2-1. Major SINAP/SS7 Components

C lientA pplication

C A SLFunctionLibrary

C lientA pplication

C A SLFunctionLibrary

. . .

O fflineB ITE U tilities

TC A P

SC C PM gm t.

M TPM gm t.

SS7 I/O Subsystem

N O D E M anagem ent

C om m on A pplicationService Layer

(C A SL)

. . . SS7 L inks

SIN A P In frastructureLegend:

In terprocess com m unications (IPC )

S S7 com m un ications

B ITE signa ling link in tercept

SystemO perator

SystemO perator

A ppl.D ebug

C lientA pplication

ISSLFunctionLibrary

ISU P Services Support L ibrary(ISSL)

ISU PM gm t.

B ITE

SINAP/SS7 Architecture 2-1

SS7 Stack Components

The first three sections that follow describe the subsystems associated with each major component area. The last section describes the limitations for basic SINAP/SS7 configuration parameters.

SS7 Stack ComponentsSS7 stack components provide a complete SS7 stack implementing a particular set of standards: ITU-T (CCITT), ANSI, TTC and NTT (Japan), or China. The subsystems of the SS7 stack include:

• Message Transfer Part (MTP) subsystem

• Signaling Connection Control Part (SCCP) subsystem

• Transaction Capabilities Application Part (TCAP) subsystem

• Integrated Services Digital Network (ISDN) User Part (ISUP) subsystem

• SS7 signaling Unit Types

• Error Detection and Correction

• SS7 driver subsystem

• SS7 input/output (I/O) subsystem

Message Transfer Part (MTP)The MTP provides message transfer services for the SINAP/SS7 platform. The MTP is responsible for the reliable delivery of information in the signaling network, including fault detection and correction. It also performs flow control, diverting traffic from congested or unavailable destinations. Figure 2-2 provides an MTP overview.



Figure 2-2. Message Transfer Part (MTP) Overview

The MTP is composed of three levels:

1. Level 1 is the Signaling Data Link. It is the SS7 layer providing services analogous to the Open Systems Interconnection (OSI) physical layer (layer 1). The signaling data link is a bidirectional transmission path consisting of two data channels transmitting in opposite directions simultaneously at the same data rate. The signaling data link can be digital or analog. The SINAP/SS7 system uses a digital signaling data link composed of digital transmission channels and their terminating equipment (that is, time slot access equipment with an interface to signaling terminals).

2. Level 2 is the Signaling Link. It corresponds to the OSI data link layer (layer 2). Using the signaling data link to provide transfer functions, the signaling link ensures the reliable transfer of signaling messages between two directly connected signaling points. SS7 transfers signaling messages over the signaling link in variable length units called signaling units.

3. Level 3 is the Signaling Network. It corresponds to the lower functions of the OSI network layer (layer 3). The functions at this MTP level provide reliable transfer of messages between signaling points (nodes) and signaling transfer points (STPs) of the signaling network. MTP level 3 provides fault detection and network management and recovery procedures. If recovery is impossible (for example, if the signaling network or signaling points fail), these functions reconfigure the signaling network.

The signaling network functions provided by MTP Level 3 are divided into two basic categories:

Message Transfer Part (MTP)

MTP Level 1 (Signaling Data Link)

MTP Level 2 (Signaling Link)

MTP Level 3 (Signaling Network)

Signaling Network Management

Signaling Message Handling



• Signaling Network Management

• Signaling Message Handling

Signaling Network ManagementSignaling network management (SNM) maintains signaling service and restores normal signaling conditions if there are interruptions in the network. It also reduces traffic caused by congestion and controls the message flow so none are lost or duplicated. The SNM functions fall into three categories, shown in Figure 2-3, that are primarily provided by SINAP processes.

Figure 2-3. Signaling Network Management Overview

• Signaling Link Management (SLM) functions control the locally connected signaling links. If a signaling link fails, SLM takes steps to restore the link’s signaling capabilities.

• Signaling Route Management (SRM) functions maintain an up-to-date status of routes. Upon receiving a transfer status message about a destination from an STP, SRM initiates the necessary events to maintain and update route information. SRM also uses flow control procedures to convey congestion information to a signaling point and ensures that rerouting procedures do not overlap for the same destination.

• Signaling Traffic Management (STM) functions perform two procedures. First, they divert signaling traffic to or from a link or route if the link or route availability changes. Second, they stop signaling traffic to unavailable destinations or limit the traffic to congested destinations.

Signaling Network Management (SNM)

Signaling Link Management (SLM)

Signaling Route Management (SRM)

Signaling Traffic Management (STM)

MTP Level 3



Figure 2-4 shows the processes contained in the STM.

Figure 2-4. Signaling Traffic Management Overview

Table 2-1 lists the processes contained in the STM.

Table 2-1. STM Processes

Process Description

Signaling route control process

Maintains the routing data tables and acts as a central database manager. This process also provides the necessary routing data to other STM processes.

Changeover process Reroutes signaling link traffic when a signaling link becomes unavailable. If the link is carrying traffic, the changeover process diverts the traffic to the alternative signaling link as quickly as possible. This process also prevents message loss, duplication, and mis-sequencing.

Changeback process Reroutes diverted signaling traffic back to the original signaling link once that link becomes available again. This process works in conjunction with the changeover process.

Forced rerouting control process

Enables restoration of the signaling capability between two signaling points towards a particular destination if there is a route failure. This process restores signaling capability to minimize the consequences of a failure.

Controlled rerouting process

Restores the optimal signaling route and minimizes message mis-sequencing when a previously unavailable route becomes available.

Signaling Traffic Management (STM)

Signaling Routing Control Process

Changeover Process

Changeback Process

SNM

Forced Rerouting Control Process

Controlled Rerouting Process

Link Availability Control Process

Link Set Control Process



Signaling Message HandlingThe signaling message handling (SMH) functions direct each MSU to the correct signaling link or user part. Signaling message handling consists of message routing, discrimination, and distribution, as shown in Figure 2-5. Typically, more than one signaling link can route a message to a particular destination point code (DPC). To keep the loads as balanced as possible among signaling links, signaling message functions use the signaling link selection (SLS) field to select the link over which to send the MSU.

Figure 2-5. Signaling Message Handling Overview

SMH functions are divided into three categories:

• Message distribution functions handle inbound messages. The inbound signaling message handling process receives messages from the driver and distributes them to the other processes. These messages are MSUs from signaling points and from other applications in the network.

• Message discrimination functions determine if an inbound message is for the receiving signaling point by comparing the destination point code of the received message with its own point code.

Link availability control process

Handles the changes in a link’s availability and coordinates the events during traffic management activities.

Link set control process Manages signaling links in a signaling link set. This process includes the signaling link activation, restoration, deactivation, and link set activation processes.

Table 2-1. STM Processes(Continued)

Process Description

Signaling Message Handling (SMH)

Message Distribution Functions

Message Discrimination Functions

Message Routing Functions

MTP Level 3



• Message routing functions determine the best route over which to send an outbound message.

Handling SNM Messages with Nonzero SLCsThe ITU-T, China, and ANSI network variants support handling SNM messages with nonzero SLCs.

• The 1988 ITU-T Recommendations for MTP require that all MTP Level 3 SNM messages use a signaling link code (SLC) of zero.

• The 1993 ITU-T Recommendations for MTP contains the ability to use a nonzero SLC value for any SNM message that is not related to a signaling link, such as an SRM message.

In the ITU-T and China network variants, to activate this feature on a particular SINAP/SS7 node, you must define an environment variable on that node before starting the SINAP/SS7 system. You need not assign a value to the variable. The SINAP/SS7 system simply verifies that the variable exists.

If the variable is not defined, the SINAP/SS7 system discards any incoming SNM messages whose SLC is not zero. If the variable is defined, the SINAP/SS7 system allows incoming SNM messages to have an SLC value other than zero. In the ANSI network variant, the SINAP/SS7 system automatically implements this feature. There is no need to define an environment variable.

MTP Time-Controlled Changeover (TCCO)The SINAP/SS7 system includes both ANSI (1992) and ITU-T (1993) time-controlled changeover (TCCO) enhancements that support the handling of a long-term or short-term remote processor outage or a changeover order received from the remote end during the MTP Level 3 T1 timer period.

N O T ELocal processor outage is not supported (only remote).

Overview of MTP TCCO ProcessingTCCO procedures are initiated and MTP T1 timer is started whenever any of the following three conditions occur:

• When the SINAP/SS7 system receives a remote processor outage (PO) on a link at the remote end and the exchange of changeover messages is not possible or desirable (because it might cause a link failure)

• No signaling path exists between the two ends of the unavailable link so that the exchange of changeover messages is impossible

• A signaling link currently carrying traffic has been marked inhibited (either locally or remotely)



In all three conditions, the level 3 changeover control (TCOC) function receives the message signaling link unavailable from the link availability control (TLAC) function. When TCOC receives this message, the SINAP/SS7 system initiates changeover (or time-controlled changeover) activities.

The remote processor outage may be a short-term or long-term PO.

A Short-Term Processor Outage is a PO that terminates before the MTP T1 timer expires. If the SINAP/SS7 system receives a Changeover order (COO) for the unavailable link from the remote end during the T1 timer period, the system initiates normal changeover procedures, completes TCCO procedures, and sends a changeover acknowledgment (COA) to the remote end.

A Long-Term Processor Outage occurs when the MTP Level 3 TCCO T1 timer expires. To avoid sending old messages when the remote PO state terminates, the SINAP/SS7 system discards MTP level 2 messages in the retransmission buffer and synchronizes sequence numbers.

N O T EThe SINAP/SS7 system implements the flushing of old messages and the synchronization of MTP Level 2 sequence numbers by failing the link when T1 expires (a long-term PO condition). This action puts the link out of service, flushes old messages, synchronizes sequence numbers, and starts the initial alignment procedure.

If a changeover order is received for the unavailable link after timer T1 expires, the concerned signaling point responds with an emergency changeover acknowledgment (ECA).

Implementing the TCCO FeatureTo enable the TCCO functionality based on the 1992 edition of the ANSI standards for MTP, or the 1993 edition of the ITU-T recommendations for MTP, you must define the appropriate TCCO environment variable before you start the SINAP/SS7 software.

N O T E S1. If you do not define this variable, the system defaults to

TCCO procedures based on the previous standard (1990 edition of the ANSI standards for MTP, or the 1988 edition of the ITU-T recommendations for MTP).

2. To implement TCCO features automatically each time you start/restart the SINAP/SS7 system, add the variable to the $SINAP_HOME/Bin/sinap_env [csh or sh] file. The Node Management Node parent (nmnp) process validates



the existence of the variable and stores the value in shared memory in the static tables.

MTP RestartThe MTP restart process enables the MTP at a signaling point that has just become available to bring sufficient signaling links into the available state to handle expected traffic and to stabilize its routing before user traffic is restarted to the signaling point. The MTP restart process helps prevent routing problems that can occur after the system resumes sending user traffic following a failure due to invalid routing information or too many parallel activities, such as link activation or changeback.

N O T E S1. A signaling point becomes unavailable when all connected

links are unavailable. The signaling point becomes available when at least one link connected to the signaling point becomes available.

2. MTP restart is supported by the CCITT, ANSI, and China network variants and adheres to the 1993 ITU-T recommendations for MTP and the 1992 ANSI standards for MTP. The TTC and NTT network variants do not support MTP restart functionality.

Because this feature requires links to other nodes in the SS7 network, MTP restart functionality does not apply to the operation of a single node. If for any reason (such as testing or performing local loopback procedures) you operate a single SINAP node, you should not enable the MTP restart feature.

The MTP restart procedure can be applied when a SINAP node is the restarting signaling point or when a node adjacent to the SINAP node is the restarting signaling point. The SINAP/SS7 system implements only the full restart functionality and does not include the capability to perform a partial restart.

MTP Restart Processing OverviewIf the MTP restart environment variable is set, the SINAP/SS7 system performs MTP restart (also called signaling point restart control [TPRC]) whenever you activate the SINAP/SS7 system on a node. The MTP restart procedure can be applied when a SINAP node is the restarting signaling point or when a node adjacent to the SINAP node is the restarting signaling point. The process provides time for the node’s links and routes to come into service before the node begins sending user traffic over them. Throughout MTP restart, the node activates and unblocks its links using normal SLM procedures. This ensures a smooth flow of traffic through the network.

During MTP restart, the node does not pass user traffic between its applications and the applications running on other nodes. Instead, the node exchanges network-status information with its adjacent nodes using the following types of messages:



• Signaling link test management (SLTM)

• Signaling link test acknowledgment (SLTA)

• Traffic restart allowed (TRA)

• Transfer prohibited (TFP)

• Transfer restricted(TFR)

• Transfer allowed (TFA)

• Transfer restart waiting (TRW) (ANSI only)

These messages indicate the availability of the links and routes between the nodes. Once MTP restart ends, the MTP informs each of its user parts (that is, applications) that they can begin passing user traffic.

Several timers define time limits for MTP restart activities. The timers and values differ between the network variants and are described in the following sections. To change these timer values, see the SINAP/SS7 User’s Guide (R8051).

ANSI and ITU-T DifferencesThe ANSI MTP restart functionality is very similar to the ITU-T MTP restart functionality in the CCITT (ITU-T) network variant. The main differences between the ANSI and ITU-T implementation are as follows:

• The ANSI MTP restart feature has a larger set of timers and a larger set of protocols concerning messages received, timer expiration, and timer stoppage

• The ANSI restart procedure contains the TRW message

Implementing the MTP Restart FeatureTo enable the MTP Restart functionality based on standards defined in the 1992 edition of the ANSI standards for MTP, or the 1993 edition of the ITU-T recommendations for MTP, you must define the appropriate MTP Restart environment variable before you start the SINAP/SS7 software.

N O T EIf you do not define this variable, the MTP Restart functionality is not implemented and processing is based on the previous standard (1990 edition of the ANSI standards for MTP, or the 1988 edition of the ITU-T recommendations for MTP).

MTP Time-Controlled Diversion (TCD)In the ITU-T, TTC, and China network variants, the TCD functionality is implemented but it is transparent to the user. That is, there is no environment variables to set. TCD is implemented automatically.



Time-controlled diversion is applied when the signaling point at the far end of the link made available is currently inaccessible from the signaling point initiating the changeback order. TCD is also performed when the concerned signaling point is accessible, but there is no signaling route to it using the same outgoing signaling link(s) or one of the same signaling links from which traffic will be diverted.

TCD is primarily used at the end of MTP restart when an adjacent signaling point becomes available. The intent of TCD is to delay changeback to avoid missequencing of messages to destination points after a remote point code has restarted. Traffic diversion can be performed at the discretion of the signaling point initiating changeback as follows:

• On a destination basis for each traffic flow

• On an alternative signaling link basis for all destinations previously diverted on the alternative signaling link

• Simultaneously for a number of alternative signaling links or for all alternative signaling links

A signaling point can also apply the TCD procedure for changeback between different link sets instead of using the sequence control procedure to avoid possible message missequencing or problems with multiple, parallel changebacks.

When changeback is initiated after MTP restart, the adjacent signaling point stops traffic to the point that is restarting and diverts traffic to alternative links for an interval defined by timer T3. After that interval, the adjacent signaling point starts traffic on the links made available. The time delay minimizes the probability of out-of-sequence message delivery to the destination point(s).

Implementing the TCD Feature

To enable the TCD functionality based on standards defined in the 1992 edition of the ANSI standards for MTP, you must define the appropriate TCD environment variable before you start the SINAP/SS7 software. However, if the MTP Restart feature is enabled on the node (via environment variable MTP_ANSI92_RESTART), the TCD procedure is automatically activated and you should not enable TCD via the environment variable.



N O T E S1. If you do not define this variable, the MTP TCD

functionality is not implemented and processing is based on the previous standards (1990 edition of the ANSI standards for MTP).

2. To implement MTP TCD automatically each time you start/restart the SINAP/SS7 system, add the variable to the $SINAP_HOME/Bin/sinap_env [csh or sh] file.

Signaling Connection Control Part (SCCP)The SCCP provides data transfer services, expanded addressing capabilities, and flow control. An SCCP protocol stack component provides these services and an SCCP management subsystem manages them.

The SCCP provides connectionless and connection-oriented services that transfer unit data, but provides no acknowledgments or rerouting procedures. SCCP management maintains network performance by rerouting or throttling traffic if the node fails or becomes congested.

The SCCP performs these functions:

• The SCCP Routing and Connectionless Control functions route messages between the MTP and SCCP users.

SCCP inbound routing functions receive messages from other network nodes via the MTP and route them to the SCCP inbound control functions.

SCCP outbound routing functions receive messages from SCCP users via the SCCP outbound connectionless control functions. The SCCP outbound routing function sends these messages to the MTP where they are transferred to other nodes in the network.

• SCCP Management notifies client applications of network management messages, such as subsystem allowed (SSA) or DPC inaccessible. If concerned point codes (CPCs) are defined for the application, SCCP management sends management messages to the network on behalf of the application.

Figure 2-6 shows how the SCCP is split between the API level (CASL) and the kernel level (SS7 driver) within the SINAP architecture.



Figure 2-6. SINAP Architecture

Global-Title Addressing The SINAP/SS7 system supports SCCP routing, based on a global title, which enables SINAP/SS7 application processes to access the global title element of an SCCP called- or calling-party address. To use global title addressing capabilities, you must define a variable to bypass global-title translation (GTT) before starting the SINAP/SS7 system. If you do not define this variable, GTT is implemented.

N O T E S1. In global title addressing, an environment variable is

defined to bypass GTT. The SINAP/SS7 system does not perform global title address translation—the application must perform the translation.

2. The SINAP/SS7 system allows both hexadecimal and numeric values (A-F and 0-9) to be used in Global Title strings when the environment variable HEX_GLOBAL_TITLE is defined.

TCAP

LoadDistribution

SCCP

MTP (3)

MTP (2)

Inbound

MTP (2)

MTP (3)

TCAP

SCCP

O utbound

Inbound and OutboundProtoco l S tack Mapping

LegendBoundaries Between Major SINAP Components

Comm on Application Service Layer (CASL)

SS7 Driver

SS7 I/O Adapter

CASLSubroutines

CASLSubroutines

CASLSubroutines

CASLSubroutines

CASLSubroutines

SINAP Applications

Client

ApplicationBITE Node

Mgm tMTPMgmt

SCCPMgmt

API

Kernel

UCOMMARTICG.703

ISUPM gmt

C lientApplication

C ASL/ISSL Subroutines

ISUP Service SupportLibrary (ISSL)



Global-Title Translation (GTT) The SINAP/SS7 system offers support for the global-title translation (GTT) functionality defined in the following standards and recommendations:

• 1993 edition of ITU-T Recommendations Q.713 and Q.714

• 1992 edition of ANSI Standards T1.112.3 and T1.112.4

• 1994 edition of TTC Recommendations JT-Q.713 and JT-Q.714

A global title (GT) is a type of address, such as a series of dialed digits, that does not itself contain the addressing information necessary to route a message signaling unit (MSU) to its destination. Instead, SCCP must perform global-title translation, a process that translates the global title into addressing information that can then be used to route the MSU to its destination.

For SCCP to perform GTT, you must provide information on the way each global title is to be translated by creating global-title entries. Each global title entry describes a particular global title and specifies how it should be translated. You can specify the global title to be translated into a destination point code (DPC), a subsystem number (SSN), a new global title, or any combination thereof. The global-title entry is stored in a segment of shared memory known as the GTT table.

N O T EThe GTT table is simply a storage area for global-title entries.

SCCP performs GTT when the address indicator of the SCCP called-party address of an inbound or outbound MSU is set to indicate route on GT.

To configure a SINAP/SS7 node to implement GTT functionality, issue the MML command CREATE-GTT to define a global-title entry for each global title that you plan to use or that the SINAP/SS7 system might encounter. The global-title entry must describe the global title and indicate how it should be translated. You can define a maximum of 4000 global title entries.

N O T EYou must configure each node to activate GTT. The SINAP software does not automatically implement this feature.

SCCP Backup RoutingThis feature provides the ability to route GT-related MSUs to an alternate or “backup” SCCP. This feature is being made generally available. This feature is only available for the ITU-T (CCITT) variant and not available for ANSI, China, TTC, or NTT variants.

This feature provides the capability of having a “backup” (or “secondary”) SCCP if the “primary” SCCP is unavailable. This is for the scope of GTT only. If the “primary” SCCP is unavailable, the SINAP node will divert the relevant MSUs to the “secondary” SCCP. If neither SCCP is available the SINAP node will return a NOTICE indication.



N O T ERemote systems must keep the SINAP node informed about their status via existing messages (SSA/SSP) for this feature to work.

SCCP Outbound Routing in Accordance with the Status of the Backup SCCPThis feature allows the user to specify a “backup” DPC and/or SSN for GTT. If the outgoing MSUs have an associated GT, the SINAP node will check the status of the primary SCCP as denoted by the DPC and SSN fields in the GTT MML or as determined after the GTT.

The SINAP system then checks to see if the SCCP primary is operational. If not, and the DPC2 and/or SSN2 fields have been set, the SINAP node will route the MSUs to the backup SCCP. If neither SCCP primary or backup is operational, the SINAP node returns a NOTICE indication.

For more information on creating global title entries, see the SINAP/SS7 User’s Guide (R8051).

For more information on implementing GTT in an application, see the SINAP/SS7 Programmer’s Guide (R8052).

Connection-Oriented ServicesA SINAP/SS7 connection-oriented feature (COF) provides SCCP class-2 and class-3 connection-oriented services.

• Class 2 provides basic connection-oriented services.

• Class 3 provides connection-oriented services with flow control.

Currently, you can implement connection-oriented services only in SINAP/SS7 configurations that use the ITU-T or China variant for the network protocol and possibly (although not necessarily) for the TCAP protocol. The ANSI and TTC variants do not support the use of connection-oriented services.

Connection-oriented services allow an application to establish and maintain connections, or logical communication paths, with other applications in order to exchange data. The SCCP Connection-Oriented Control (SCOC) process performs management functions required to provide connection-oriented services such as establishing connections, assigning connection IDs, maintaining information on all active connections, and releasing connections.

To activate connection-oriented services on each SINAP/SS7 node, you must define specific environment variables at the operating system command level before you start the SINAP/SS7 system on the node.

For more information on connection-oriented services, see the SINAP/SS7 Programmer’s Guide (R8052).



XUDT and XUDTS Message HandlingThe SINAP/SS7 system supports the following two primitives used in connectionless protocol classes 0 and 1. These enhancements conform to the functional descriptions of XUDT and XUDTS messages contained in the 1993 ITU-T recommendations Q.711 to Q.716.

• Extended Unitdata (XUDT) Message is used to carry segmented message data for connectionless protocol classes 0 and 1. The message sends data with or without optional parameters.

• Extended Unitdata Service (XUDTS) Message is sent to the originating SCCP application when an XUDT message with optional parameters cannot be delivered to its intended destination because of an error. An XUDTS message is sent only when the return on error option is set in the XUDT message.

Applications can exchange XUDT messages if they register with CASL at the SCCP XUDT or TCAP XUDT boundary. However, applications can use the existing Application Programming Interface (API) to exchange unitdata (UDT) messages even if they are registered at the SCCP XUDT or TCAP XUDT boundary.

N O T ECurrently these SCCP enhancements are available only in the CCITT (ITU-T) and China network variants. The TTC and ANSI variants will not use this functionality until they are upgraded to comply with more recent revisions of their respective standards.

XUDT/XUDTS Processing OverviewThe XUDT functionality consists of segmenting messages of up to 2048 bytes in length into multiple XUDT message signaling unit (MSU) segments up to a maximum of 16. The maximum segment size (which includes the length of the data and address parameter fields in the MSU) depends on the network variant being used.

• For the CCITT (ITU-T) variant, the maximum segment size is 254 bytes.

• For the China variant, the maximum segment size is 251 bytes.

All XUDT MSUs that are segments of the same message are assigned the same unique identification number or local reference number (LRN). Each time an LRN is released, it cannot be reused on a node-wide basis for a minimum period of time defined by the SCCP freeze timer SCTX. The message reassembly process must receive all segments and reassemble the entire message within the reassembly time period specified in the SCCP reassembly timer SCTY. If message reassembly does not occur within the specified time period, the SINAP/SS7 system discards the message and might send an XUDTS message to the originating application process.



If the XUDT MSU had return message on error specified in its Protocol Class field, the system generates an XUDTS message and sends it to the originating SCCP application to indicate that the XUDT MSU was not delivered because an error occurred.

The XUDTS message consists of the first segment of the XUDT message. The SINAP/SS7 system handles the transmission and receipt of XUDTS messages in the same way it handles UDTS messages.

Transaction Capabilities Applications Part (TCAP)In an advanced intelligent network (AIN), communication between applications is governed by a message protocol, which is a set of rules defining how messages are to be exchanged between applications. Every message protocol is registered with a standards organization and the rules defining that protocol are published in that organization’s standards recommendations. For example, two Integrated Services Digital Network (ISDN) applications communicate by following the ISDN signaling standards defined in ITU-T Recommendation Q.763.

Typically, an application that provides services in an AIN (such as an application for translating 1-800 telephone numbers) is designed to operate with a particular message protocol. However, all the switches in the network might not support that protocol. To enable the application to support applications running on those switches, the 1993 TCAP standards allow an application to have one or more subapplications, each supporting a different variant of the application’s message protocol.

To communicate with the application providing services in the AIN, an application running on a switch accesses the subapplication that supports its message protocol. The switch application identifies the subapplication by means of a dialogue portion included in the MSU. The dialogue portion contains an application-context name that identifies the ASE of the message protocol being used by the subapplication. The dialogue portion can also contain optional user information for the dialogue, such as a password or initialization information.

The subapplication handles information from the switch application and converts that information to the format required by the main AIN application, and vice versa. For example, an ISDN application accessed by applications running on three different types of switches might have three subapplications. Each subapplication is accessed by the particular switch application that uses that variant of the AIN application’s message protocol.

When you specify the ASE of the sub application with which you want your application to communicate, you are specifying the application context under which you want the dialogue to execute. Throughout this chapter, a dialogue that is initiated under a specific application context is referred to as an application-context dialogue.

Integrated Services Digital Network User Part (ISUP)The ISUP of the SS7 protocol provides the signaling functions to support basic bearer services, as well as supplementary services, for switched voice and data applications in an ISDN environment.



Basic Bearer Services Basic bearer services provide control of circuit-switched network connections between subscriber lines and exchanges (that is, call setup, call teardown).

Supplementary Services Supplementary services include support for services such as call forwarding, calling number identification, and future services. ISUP uses the transport services provided by MTP.

Defining ISDN User Part (ISUP) FunctionalityThe ITU-T, NTT, China, and ANSI network variants support the ISUP signaling functions required to support circuit switched services for voice and nonvoice connections to an ISDN.

The SINAP/SS7 system provides ISUP services functions by defining an environment variable described in the following section. For a more detailed description, see the SINAP/SS7 ISDN User Part (ISUP) Guide (R8053).

ISUP Services FeatureThe SINAP/SS7 system provides base implementations of ISUP services that conform to the following standards:

• 1993 edition of ITU-T (CCITT) Recommendations Q.761 through Q.764

• 1992 edition of the ANSI Standard T1.113,

• 1992 edition of the Japan Nippon Telephone & Telegraph (NTT), SS7 ISUP specifications (NTT-Q762-a, NTT-Q763-a, and NTT-Q764-a, Edition 1-1).

The SINAP/SS7 ISUP services feature uses the pass-along method of end-to-end signaling described in ITU-T Recommendation Q.761, Section 5.3, and in ANSI Standard T1.113.3.

The SINAP/SS7 system also provides country-specific versions of ISUP services that adhere to one of the base ISUP services standards with modifications to accommodate individual country standards.

N O T EThe ISUP services feature provides only the signaling capabilities documented in these base standards and country-specific standards that the SINAP/SS7 system supports. It does not provide any call-control or circuit-management capabilities; however, you can develop applications that implement these capabilities.

The ISUP services feature contains the following components:

• ISUP Services Support Library (ISSL)—The API that provides the functions and data structures for developing ISUP applications. The location of the DLL library,



libissl.sl, is $SINAP_HOME/Library, where $SINAP_Home is the root directory for your installation, or $SINAP_MASTER/Library. To use the ISUP services feature, an application must register with the SINAP node at the ISUP boundary and follow specific registration criteria.

• $SINAP_HOME/Include directory—Contains additional ISUP files, including issl.h and issl_sit.h.

• ISUP environment variables that enable or disable specific ISUP features.

• Sample programs—Show how to use the ISUP service functions in applications to enable them to send and receive ISUP messages.

• ISUP services timers—Define time-out values for performing various tasks.

• The BITE subsystem and sy utility—Enable you to log and display ISUP messages.

Activating the ISUP Services Feature By default, the ISUP services feature is turned off. To activate the ISUP services feature, define the following environment variable, representing the version of ISUP Services configured for the SINAP node, before starting the SINAP/SS7 system.

ISUP_FEATURE=<VERSION NAME>

The SINAP/SS7 system supports the base implementations and country-specific versions of ISUP services shown in Table 2-2.

Table 2-2. Valid ISUP Versions and Network Variants

Valid ISUP Services Version Network Variant

ANSI ANSI

CHINA China

NTTNTT_IC

NTT



N O T EThe ISUP version must agree with the network variant defined for the SINAP node.

Environment variables define and activate operating characteristics on the SINAP node. The SINAP environment file ($SINAP_HOME/Bin/sinap_env.[csh or sh]) contains all SINAP/SS7 environment variables. Although most of the environment variables are disabled (commented-out), some are activated (uncommented) during installation/configuration of the SINAP/SS7 product.

To activate other environment variables, you must edit the SINAP environment file by uncommenting the appropriate environment variable and setting the variable to the correct value, if applicable. Note that for many of the environment variables, you do not need to assign values. The description associated with each environment variable in the SINAP environment file provide the valid setting(s), if required, for the variable.

SS7 Signaling Unit TypesAn SS7 network uses three types of signaling units, each distinguished by the value of its length indicator field:

• The MSU carries signaling information data between the application and network management layers of signaling nodes. An MSU contains a signaling information field (SIF) that must have a length less than or equal to 272 octets (bytes).

ACIF_G500BELGIUMBRAZILCCITTFRANCE1GERMANYITALYITU97MEXICONETHERLANDSQ767SPAINSWEDENTAIWANUK

CCITT

Table 2-2. Valid ISUP Versions and Network Variants (Continued)




• The Link Status Signaling Unit (LSSU) carries link status and processor information between signaling nodes.

• The Fill-In Signaling Unit (FISU) fills the idle period of the link.

Error Detection and CorrectionSINAP’s signaling link uses the basic method of error detection and recovery. The basic method is a noncompelled, positive/negative acknowledgment, retransmission, error correction system. With this method, unacknowledged messages are resent during gaps in message traffic. The sending end retains the message until it receives a positive acknowledgment from the destination. This method only corrects errors in the MSUs. It detects, but does not correct errors, in the FISUs and LSSUs.

The signaling link functions monitor two types of signaling link error rates:

• Signal unit error rate, based on a signal unit error count

• Alignment error rate, a linear counter operating during alignment-proving periods

SS7 Driver Subsystem The SS7 driver subsystem provides MTP Level 3 functions for high-performance SS7 activities within a SINAP node. The driver acts as a liaison between the higher layer functions such as the client application, TCAP, SCCP, and MTP Level 3, and the lower layer functions, such as MTP Level 2. Portions of the SCCP and MTP are embedded in the driver (see Figure 2-6).

The SS7 driver subsystem (an SVR4 STREAMS driver) consists of a collection of functions providing an interface between the SS7 driver I/O adapter and the CASL. The interface is included in the kernel. The driver also contains an extension, called load distribution, to the SCCP message distribution function. Load distribution spreads incoming message packets across duplicated or cloned application processes to take advantage of the Stratus multiprocessor architecture.

SS7 Input/Output (I/O) Adapter SubsystemThe SS7 I/O adapter subsystem (firmware) provides real-time response to the MTP level 2 functions, providing reliable transfer of signaling messages. The SS7 I/O adapter subsystem implements all the MTP Level 2 protocol and part of the MTP Level 3 protocol. (See Figure 2-6.) This subsystem is implemented as firmware that is loaded onto SINAP/SS7 I/O adapters at start-up.

Three types of I/O adapters are supported:

• Peripheral Component Interconnect (PCI)

• Universal Communications (UCOMM)

• T1/E1 (G.703)


Application Development and Deployment Components

See Chapter 4, “Hardware and Software Requirements,” for more information.

Application Development and Deployment ComponentsApplication development and deployment components include two SINAP/SS7 APIs (as detailed in Figure 2-7):

• Common Application Services Layer (CASL)—Provides a robust and easy-to-use set of tools designed to simplify creation of applications that provide services within an SS7 network. The CASL also serves as the API between user-developed applications and the SINAP/SS7 system.

• ISUP Service Support Library (ISSL)—Contains all functions and data structures required to develop ISUP services applications.

N O T EAll SINAP/SS7 processes use dynamically linked libraries (DLLs). The sample programs are compiled using these DLLs. An archive library is also provided.

Typical SINAP/SS7 applications provide the following types of network services:

• Generic telephone number translation services

• Enhanced 800 and 900 telephone translation services

• Home location register (HLR) and service location register (SLR) services

• Line identification database (LIDB) and database lookup services

• Alternative billing services (ABS) for credit and calling cards

• Private virtual network (PVN) services

• Televoting

• Automatic call distribution and routing services for load balancing



Figure 2-7. Application Development and Deployment Components

Client ApplicationsA SINAP/SS7 client application consists of one or more processes, each considered a client-application process. There are two main processes:

• A control process typically handles the application’s management functions (for example, SS7 network management, sending and receiving SCCP management messages, interprocess communications, and the initialization and termination of data processes). A client application can have only one control process.

• A data process typically handles SS7 traffic (for example, reading inbound MSUs from the queue and responding with outbound MSUs). A client application can have up to 16 separate data processes, each a separate instance (or clone) of that application. Activating multiple data processes enables the application to provide better throughput during periods of heavy activity.

The SINAP/SS7 API offers the flexibility to customize application design. For example, an application can consist of a single process that performs both control and data processing. Or,

BITE Functions

Client Application

ControlProcess (1)

DataProcess (1-16)

Common Application ServicesLayer (CASL)

Management Functions

SS7 Functions

ISUP Encoding and Decoding Functions

IPC Functions

Load Control Functions

Conversion Functions

ISUP Services Support Library(ISSL)

ISUP Service Support Functions

Connection-Oriented Services Functions



it can consist of multiple processes, one of which performs control processing and others that perform data processing. An application registers with the SINAP/SS7 system in a manner that determines whether it is a control process, a data process, or both.

Common Application Services Layer (CASL)The CASL includes a library containing all functions, primitives, and data structures for creating network services applications. The CASL’s open and flexible architecture allows the creation of specialized application programming logic. For example, the CASL allows application processing to be divided into control and data processes. Each process handles different types of transactions for the application. The control process handles all the application’s management functions, and the data process handles all the application’s data processing. In addition, a data process can be cloned up to 16 times. For data-intensive services, such as database lookup, cloning increases application throughput during periods of intense activity.

The CASL is a library of C-language functions and subroutines linked to user-developed programs (client applications) running in the SINAP/SS7 environment. The boundary between client applications and the top-level functions of CASL is called the API. A client application uses CASL functions to interface with the SS7 network at the MTP, SCCP, or TCAP layer. In addition, SINAP management and support processes use CASL functions. Both SINAP management and client application processes logically reside on top of the CASL.

The API provides access to the SINAP/SS7 platform that, in turn, provides access to the SS7 suite of protocols running on the operating system. The API provides the tools to develop client applications to run on the SINAP system and interface with SS7. A SINAP/SS7 application is a C-language program that includes calls to appropriate CASL functions.

CASL FunctionsThe CASL library contains many types of function calls. This section divides the functions into groups and describes the types of actions performed by these function calls.

• SINAP/SS7 Management Functions that perform various types of management functions for the client application are:

— Registration and Termination

— Command and Reply

— Event Reporting

— Health Check

• SS7 Functions that communicate with the SS7 network are:

— SS7 Message Handling (MTP and SCCP)

— TCAP Component Handling and Dialog/Transaction Processing



• Interprocess Communications (IPC) Functions communicate internally between SINAP/SS7 client applications and SINAP/SS7 subsystems.

The CASL provides interprocess communications using STREAMS message queuing. When a client application registers with the SINAP/SS7 system, the SINAP/SS7 system creates a STREAMS message queue for that application. When the application terminates, the SINAP/SS7 system deallocates its STREAMS message queue.

IPC can occur between two SINAP/SS7 client applications, between a client application and a SINAP subsystem, or between two SINAP/SS7 subsystems. In addition, the CASL automatically performs transparent IPC communications by sending messages to SINAP/SS7 subsystems, such as Node Management.

IPC Functions are:

— IPC Key Processing

— MML Command Handling

— IPC Message Handling

— Deferred IPC Message Handling

The two basic functions for performing IPC include:

• Retrieve a message from the STREAMS message queue. IPC messages sent to a client application via the STREAMS facilities are placed on the application’s STREAMS message queue where they remain until the application retrieves them using this function.

• Send a message to the STREAMS message queue for another process. When an application calls this function, the CASL determines whether the application is authorized to send a message to the specified destination. If so, the message is copied to the destination queue using the STREAMS facilities. If the message cannot be sent, the CASL returns an error.

The SINAP/SS7 system also provides a deferred message utility allowing an application to send a message that is delayed a specified amount of time before delivery to the destination STREAMS message queue. This mechanism is useful for time-out handling, scheduling functions over a given time period (every n second or minutes), or providing a delay between message sending and delivery.

• Connection-Oriented Services Function that enables applications that use connection-oriented services to establish and maintain connections with other applications for the purpose of exchanging data is:

— Connection-oriented processing


Node Management and Built-In Test Components

• Load Control Functions that maintain an application’s throughput during severe network congestion are:

— Load control management

— Load control processing

• BITE Functions that monitor and debug client applications are:

— Monitor

— Intercept

— Debug

In addition to the preceding functions, the CASL library contains two additional functions that are useful for converting character strings to and from U32 word format.

• ca_ascii_u32( )

• ca_u32_ascii( )

ISUP Services Support Library (ISSL)The ISUP Services Support Library (ISSL) is an Applications Program Interface (API) for developing applications that use ISUP services. The ISSL library provides all ISUP configuration, message-handling, and circuit-handling functions, data structures, and timers necessary to develop ISUP services applications.

Node Management and Built-In Test ComponentsThe node management and built-in test components include:

• Node Management subsystem

• Configuration and Operation

• Built-In Test Environment (BITE)

Node Management SubsystemThe Node Management subsystem provides tools for managing the SINAP/SS7 node, the signaling resources, and the client applications for the SINAP/SS7 node as shown in Figure 2-8. The Node Management subsystem also monitors and manages the SINAP/SS7 processes and attempts to restart any processes that terminate abnormally.



Figure 2-8. SINAP Node Management

The Node Management subsystem consists of the following processes:

• The Node Management parent process is the first process activated in the SINAP/SS7 environment. After performing all necessary node initialization procedures, the parent process creates all Node Management child processes.

• The Terminal handler process runs for each system operator (sysopr) terminal that is active in the system.

• The SS7 network interface process provides a direct interface between Node Management and the SS7 driver.

• The disk I/O server process performs disk I/O for all activities requiring disk file access.

• The client management process accepts registration requests from a client application or a SINAP Management process, to enable sending and receiving IPC messages.

• The command management process accepts commands from one of many terminal handler processes, a client application, or the BITE subsystem.

• The trouble management process collects alarm and event messages from client applications and all the node processes. After receiving a message, this process:

Node ManagementParent Process

Terminal Handler Process

SS7 Network Interface Process

Disk I/O Server Process

Client Management Process

Command Management Process

Trouble Management Process

Measurement Collection Process

Deferred Message Process

Interprocess Communication (IPC) Handler Process

Ch

ild P

roce

sses



— interprets the message

— records it in the Alarm History log file

— initiates appropriate functions to handle the alarm or event.

Depending on the severity of the alarm or event, the trouble management process displays an alarm on the system operator’s terminal.

• The measurement collection process collects statistics from MTP, SCCP, and TCAP network traffic for SINAP/SS7 client applications and processes. This process runs automatically while the SINAP/SS7 system is active. It can issue reports on statistical measurements for a specific time period, such as a day, week, or longer. The command, FILE=, saves the report to a designated file (see also measurement reporting).

• The Interprocess Communication (IPC) handler process handles IPC messages between registered SINAP/SS7 processes.

• The deferred message process allows a client application to request that messages be sent at a specified time.

Configuration and Operations The SINAP/SS7 system’s easy-to-use OA&M (Operation, Administration, & Management) component aids in the configuration of the resources necessary for the SINAP/SS7 system to function as an SS7 node (for example, links, link sets, and route sets). OA&M functions are implemented as Telcordia standards-based man machine language (MML) commands that can be accessed through two separate user interfaces.

• The terminal handler interface is a menu-driven interface that provides the complete set of MML commands available for configuring the SINAP/SS7 software.

• The send_cm command enables MML commands to be issued from the UNIX prompt.

Built-In Test Environment (BITE)The BITE subsystem provides built-in and external test and monitoring facilities to help you detect problem areas, monitor the traffic on various links, and simulate network operation. BITE traces the data at the link level. The trace point is located in the STREAMS driver at the point the data is received from level 2. All data traveling between level 2 and level 3 is captured. Each message being traced is copied, and the copy is sent to BITE for logging. Because FISU and LSSU do not travel between level 2 and level 3, the trace does not show any FISUs or LSSUs . BITE traces data moving between the driver and the client application. This includes both IPC and SS7 data (MSUs). Whenever the client application issues a read or write, the data is copied to a buffer and sent to BITE.



Figure 2-9 shows the BITE trace points.

Figure 2-9. BITE Trace Points

BITE provides the following capabilities for troubleshooting network problems:

• The BITE Monitor facility enables you to monitor applications, processes, SINAP Stacks, SS7 links, and IPC paths. During a monitor session, information is collected and written to a BITE log file, which you can then analyze using the BITE Log Analysis program. You use the MML commands START-MON and STOP-MON, respectively, to initiate and terminate a BITE monitor process. These commands can be entered directly using the MML command format, or issued using the menu selection mode to access the BITE Commands menu from the SINAP System Main Menu.

• The BITE Log Analysis program processes information logged by BITE. This program provides several commands for finding, displaying, and selecting particular records in a log file, and for printing the results.

In summary, use BITE to determine two things:

1. Is the application receiving and responding to the inquiries?

2. Is the driver sending them out?

C lie n t A p p lic a t io n

c a _ g e t_ tcc a _ p u t_ tc

c a _ g e t_ m s uc a _ p u t_ m s u

c a _ g e t_ m s gc a _ p u t_ m s g

D r iv e r

M a k e a c o p yo f th e M S U

fo r B IT E

M a k e a c o p yo f th e IP Cm e s s a g efo r B IT E

IO A S u b s y s te m L e v e l 2

B IT EL o g g in gP ro c e s s

S S 7 D a ta

IP C D a ta

L N K D a ta



BITE LimitationsYou should be aware of the following restrictions when using the BITE Monitor and Log Analysis programs:

• A maximum of eight monitors can exist at any one time.

• A maximum of eight entities can be specified in a single BITE command.

• The processes BI, LF and BI, ID cannot be monitored.

• The Node Manager (NM) and Terminal Handler (TH) processes cannot be monitored for input if DISPLAY is ON.

• The log file name is checked against file names used in active monitors.

• Only the Node Manager and Terminal Handler processes can turn on the DISPLAY option.

• BITE operates on the node that is currently active in the SINAP/SS7 login window.

You can configure the BITE subsystem to best suit your needs. The BITE defaults are:

• Default log size is set at 200K bytes. Maximum is 1,000K bytes.

• Log file is always created in the directory: $SINAP_HOME/Logs/bite.

• [Node], [Module] names. If omitted, indicates local node and module.

• [Instance] number. If omitted, indicates all instances at the time of the command.

BITE Monitor The BITE monitor facility provides an in-depth look at the system’s status. This means you can check an application’s status at the SS7 level. For example, suppose you confirm that your SINAP/SS7 configuration is functioning, but MSUs are not being processed. You can use BITE to further investigate the problem and to determine whether the application is receiving and responding to inquiries and whether the SS7 driver is sending information.

You initiate a BITE monitor process by issuing the MML command, START-MON, specifying the entities to be monitored and the types of operations for which you want to collect information (read, write, or both). The monitor process keeps track of the specified entities in order to collect the specified information, which it writes to a BITE log. To terminate the monitoring session, you issue the MML STOP-MON command.

N O T EYou can use BITE Log Analysis commands to display and extract records and obtain summary information from the BITE log that contains all the record data collected during the monitoring session.


SINAP/SS7 Configuration Parameters

BITE Log Analysis ProgramThe BITE Log Analysis program contains command options that allow you to display and analyze information in a BITE log. You can start this program by issuing commands directly using the MML command line formats, or by using the menu selection mode.

The records contained in a BITE log appear in the order in which they were received during the monitoring session. These records are in I_Block format, with SS7 M_Block structures embedded in the I_Block structure. BITE monitor logs can contain interprocess communication (IPC), SS7, and link (LNK) messages.

If the log contains IPC messages, see the SINAP/SS7 iblock.h include file to decode the message type. You can then use the appropriate .h file to decode the message structure.

If the log contains SS7 or LNK messages, use the SINAP/SS7 mblock.h include file to determine the message type and structure. You may also need to refer to the appropriate ITU-T or ANSI recommendations to decode messages. However, the BITE Log Analysis program performs most of this decoding for you.

SINAP/SS7 Configuration ParametersThe basic role of the SINAP/SS7 system is to serve as a transmission end point. Specifically, it serves as an SSP or SCP (but not an STP). The system has the following operational parameters:

• The SCCP provides connectionless and connection-oriented services that support the following protocol operations:

— Class 0 (unsequenced) and Class 1 (sequenced) for connectionless services

— Class 2 (basic) and Class 3 (flow control) for connection-oriented services (ITU-T only)

• SCCP supports the following OPC and DPC address formats:

— For ITU-T, SCCP supports international 14-bit addresses.

— For TTC, and NTT, SCCP supports international 16-bit addresses.

— For ANSI and China, SCCP supports 24-bit national addresses.



Table 2-3 shows the limitations for basic SINAP/SS7 configuration parameters.

Table 2-3. SINAP/SS7 Configuration Limitations (Page 1 of 9)

Item Limitation or Support

Maximum number of signaling links 128 per SINAP module. The total for all nodes must not exceed 128.

Note: You can only configure 128 links on the Continuum Series 400 systems equipped with PA-8500 or PA-8600 processors or on an ftServer.

Maximum IOA cards per Continuum Series 400 & Series 400 CO systems with: PA-8000 processor:

PA-8500 and PA-8600 processors:

U403 = 8 cards (4 Links per card) U420 = 4 cards (8 Links per card)

U403 = 8 cards (4 Links per card) U420 = 8 cards (8 Links per card) U916 = 8 cards (32 Links per card)

Maximum IOA cards per Netra 20/T4†or SunFire V480 system

U915 or U916 = 3 cards (32 Links per card)

Maximum IOA cards per ftServer T30 system

U918 = 4 cards (32 Links per card)

Link operating speeds supported:CCITT/ANSI/China

TTC/NTT

4.8, 9.6, 19.2, 38.4, 56, 64 kbit/sIf you are creating an ARTIC synchronous link, you must specify a link speed of 0 if you connect to a modem or other device that provides external clocking.

Supports baud rates of 4800, 48,000, or 64,000.

Maximum number of link sets 16 per node (a module with 4 nodes can have a maximum of 64)

Maximum number of links per link sets 16

Maximum number of routes per route set:CCITT/TTC/NTT/ChinaANSI

8 4

Maximum number of route sets 2048 per node (a module with 4 nodes can have a maximum of 8192)

Maximum number of load-shared routes 2



Load sharing for route sets supported:CCITT TTC NTTANSI China

YesYesYesNoYes

Maximum number of destination point codes (DPCs)

2048 per node (a module with 4 nodes can have a maximum of 8192)

Maximum number of DPCs reachable by one link set


Maximum number of concerned point codes (CPCs)

64 per local SSN (Up to 512 can be accommodated with a special patch. Contact the CAC for more information.)Note: The TTC and NTT network variants support CPCs only if the environment variable TTC_WITH_NSTATE is defined.

Maximum number of duplicate concerned point codes (DUCPCs):CCITT/ANSI/China

TTC/NTT

1 per local SSN

Not supported

Distributed logical point codes (DLPCs) supported:CCITT/ANSI/China

TTC/NTT

Yes, if DLPC is configured on the SINAP node (via /etc/config_sinap script)

Not supported

Maximum number of logical point codes (LPCs) allowed for registered processesCCITT/ANSI/China

TTC/NTT

16 per node in addition to own signaling point code (only if DLPC feature is configured on the node via /etc/config_sinap script)

Not supported

Application failure detection with notification to backup DLPC application supported:CCITT/ANSI/China

TTC/NTT

Yes (only if DLPC feature is configured on the node via /etc/config_sinap script)Not supported





Maximum number of applications registered with SINAP


Maximum number of processes registered with the SINAP node that can run concurrently

255 per node

Instances per application 16 instances per application

drda_daemon processes 1 per node (a module with 4 nodes can have a maximum of 4)

Maximum number of links per combined link set (CLS)ANSI

CCITT/TTC/NTT/China

32 links (2 link sets) per CLS)

Not supported

Combined link sets supported:ANSI

CCITT/TTC/NTT/China

Yes - 4 per node (a module with 4 nodes can have a maximum of 16)

Not supported

Signaling Connection Control Part (SCCP) message modes supported:

CCITTTTCNTTANSI China

Note: Connectionless: Class 0 (unsequenced) and Class 1 (sequenced), Connection-oriented: Class 2 and Class 3

Class 0, 1, 2, 3Class 0, 1Class 0, 1Class 0, 1Class 0, 1, 2, 3

XUDT and XUDTS message handling supported:CCITTTTCNTTANSIChina

YesNoNoNoYes





SCCP addresses supported for destination point code (DPC) and originating point code (OPC):CCITT TTC NTTANSI China

14-bit point code format16-bit point code format16-bit point code format24-bit point code format 24-bit point code format

Global title translation (GTT) supported:CCITT TTC NTTANSI China

YesYesYesYesYes

Partial GTT supported:CCITT/TTC/ NTT / ANSI / China Yes, if the environment variable

PARTIAL_GTT is defined.

SCCP backup routing for GTT only supported:CCITT

TTCNTTANSIChina

Yes, if the environment variable GTT_WITH_BACKUP_DPC_SSN=1 is defined.

NoNoNoNo

Global title (GT) addressing supported:CCITT TTCNTTANSI China

YesYesYesYesYes

Connection-oriented features (COF) supported:CCITTTTCNTTANSIChina

YesNoNoNoYes





Number of link-congestion levels supported:CCITT and China

ANSI, TTC, and NTT

Three optional congestion levels:• International one congestion onset and

one congestion abatement

• National multiple states with congestion priority option

• National multiple congestion states without congestion priority

(Default is international one congestion onset and one congestion abatement if no environment variable is set to define link congestion levels)

National multiple congestion states with congestion priority automatically implemented

ISUP service features supported:CCITT, NTT, China, and ANSI

TTC

Yes, if ISUP_FEATURE environment variable is defined (see SINAP/SS7 ISDN User Part (ISUP) Guide (R8053)).No

MTP signaling point restart supported:CCITT and China

TTCNTT

ANSI

Yes, if MTP_WHITE_BOOK_RESTART environment variable is defined. Default is CCITT 1988 network processing.

NoNo

Yes, if MTP_ANSI92_RESTART environment variable is defined. Default is ANSI 1990 network processing with no restart processing.

MTP user part unavailable (UPU) messages and user flow control (UFC) supported:CCITTTTCNTTANSIChina

YesNoNoYesYes





Fictitious originating point code (FOPC) supported:CCITTTTCNTTANSIChina

NoNoNoYesNo

Signaling network messages (SNM) with non-zero SLCs supported:CCITT/China

TTCNTT

ANSI

Yes (MTP_WHITE_BOOK_SLC environment variable must be defined)

NoNo

Yes (no need to set an environment variable)

MTP time-controlled changeover (TCCO) supported:CCITT/China

TTC/NTT

ANSI

Yes, CCITT 1988 TCCO is the default. To implement CCITT 1993 TCCO processing, define the environment variable MTP_WHITE_BOOK_TCCO.

Yes (automatically implemented)

Yes, ANSI 1990 TCCO is the default. (Implemented automatically if MTP restart is enabled; otherwise, you must set the environment variable MTP_ANSI92_TCCO)

Time-controlled diversion (TCD) supported:CCITT/TTC/NTT/China

ANSI

Yes (Implemented automatically; no environment variable must be set)

Yes (Implemented automatically if MTP restart is enabled; otherwise, you must set the environment variable MTP_ANSI92_TCD)





Remote processor outage control (POC) supported:CCITTTTCNTTANSIChina

YesNoNoYesYes

Local processor outage control (POC) supported:CCITTTTCNTTANSIChina

NoNoNoNoNo

Preventive cyclic retransmission (PCR) supported:CCITTTTCNTTANSIChina

NoNoNoNoNo

International network indicator supported:CCITTTTC NTTANSI China

YesYesYesNoYes

Loopback detection supported:CCITT

TTCNTTANSIChina

Yes, if the environment variable LOOPBACK_DISPLAY is set.

NoNoNoNo





Transfer-restricted message handling supported:CCITT

TTCNTT

ANSI

China

Yes, if the environment variable MTP_WHITE_BOOK_TFR is defined.

NoNo

Yes, implemented automatically (according to 1992 ANSI Standards); no environment variable needs to be set. To configure the node according to the1988 ANSI standards, set the environment variable MTP_ANSI88_RSR_RST.

No

Even distribution of messages by routing solely on SLS and DPC supported:CCITT and China

TTC, NTT, and ANSI

Yes, if the MTP_SLS4_LOAD_SHARE environment variable is defined before starting or restarting the SINAP/SS7 system.

No

Selection of 5-bit or 8-bit Signaling Link Selection (SLS) processing schemes for all incoming and outgoing traffic supported:CCITT/TTC/NTT/China

ANSI

No

Yes (Specified using the CHANGE_SLSTYPE command; default is 5-bit processing)

Custom Application Distribution (CAD) supported:CCITTTTCNTTANSIChina

YesNoNoYesNo





Maximum number of ServiceKey values per application (CAD):ANSI/CCITTTTC/NTT/China

64 No

Maximum number of ServiceKeys supported for a specific SSN/OPC criteria (CAD):ANSI/CCITTTTC/NTT/China

256No

Maximum number of fall back applications supported for a specific SSN/OPC criteria (CAD):ANSI/CCITTTTC/NTT/China

1 (Value specified for ServiceKey must be 0)No

Maximum number of SSNs per application (Enhanced Distribution and CAD):ANSI/CCITTTTC/NTT/China

32No

Maximum number of OPCs per application (Enhanced Distribution and CAD):ANSI/CCITTTTC/NTT/China

128No

† Note that Sun Microsystems refers to this model as either “Netra 20 Server” or “Netra T4”, but it is referred as “Netra 20/T4” in SINAP documentation to avoid the confusion.




Chapter 3SINAP/SS7 Product Features3-

This section describes the features and benefits that distinguish the SINAP/SS7 system from other SS7 implementations. The features are divided into the following sections:

• Value-added features

• Highlights of SS7 standards implementation

• System administration features

• Online help documentation

Value-Added FeaturesThe value-added features include:

• The MultiStack product

• Standards support for for older versions

• Periodic link testing

• Enhanced message distribution and routing capabilities

• Route Set Initialization

• Custom Application Distribution

• Country-Specific ISUP Versions

• Load control

• Simple Network Management Protocol (SNMP)

• Distributed Logical Point Code (DLPC)

• Partial Global Title Translation (GTT)

The following sections describe the value-added features in more detail.

SINAP/SS7 Product Features 3-1

Value-Added Features

MultiStackMultiStack is the part of the SINAP product enabling you to run up to four SINAP stacks (SINAP nodes) on a single operating system (a SINAP module). Each stack can connect to a different network and support a different SS7 protocol standard, such as ITU-T, ANSI, TTC, NTT, or China. (Refer to Figure 1-3 of this document for a sample configuration.)

Using MultiStackThe MultiStack product requires a license file that defines the number of SINAP nodes your site is licensed to run. When you configure SINAP nodes for your module, the license file is checked for the number of nodes allowed.

When you configure a SINAP node, you must define a unique login account and home directory for the node. The SINAP software creates a symbolic link between the node’s home directory and the /sinap_master directory in which the SINAP software is installed. When you activate a node, the system starts a separate set of SINAP processes for that node. These processes execute in the node’s home directory. (For example, if you configure four nodes, there will be four separate sets of SINAP processes, each executing in the home directory of that node’s login account.)

You use a separate SINAP login window to manage each node. When you log in to a SINAP node, you specify the login name assigned to that node. For example, if you have configured three SINAP nodes with user names of sinap0, sinap1, and sinap2, and you want to log in to the second SINAP node, you simply log in as sinap1.

Programmers can use the SINAP InterProcess Communications (IPC) mechanism to develop applications that provide gateway functionality for the SINAP module.

N O T EMultiStack does not itself provide gateway functionality (that is, a single application that services multiple nodes simultaneously). However, you can achieve similar results by developing separate applications, each servicing a particular SINAP node, that use IPC to communicate with one another.

Standards Support for Older VersionsExisting SINAP/SS7 client applications adhering to older versions of standards will run without modification. However, they must be recompiled to run with newer releases of the SINAP/SS7 software. (See Chapter 5, “Standards Compliance,” for more detailed information.)

Periodic Link TestingPeriodic link testing enables you to configure the SINAP/SS7 system to automatically send test messages over a specific SINAP/SS7 link (see Note 2 below). The link’s remote endpoint is



expected to respond by sending a signaling link test acknowledgment (SLTA) message to the SINAP/SS7 system. If the SINAP/SS7 system receives the SLTA message within a specified amount of time, the link passes. Otherwise, the link fails and the SINAP/SS7 system restarts it. This feature is useful for troubleshooting link problems. (See the SINAP/SS7 User’s Guide (R8051) for additional information.)

N O T E S1. Periodic link testing does not disrupt normal SS7 traffic

over a link, nor does it replace the link alignment testing that the SINAP/SS7 system performs automatically when a link is initialized.

2. ITU-T, ANSI, and China variants send signaling link test (SLT) messages while the TTC and NTT variants send signaling route test (SRT) messages.

Loopback ModeFor any E1 trunk in loopback mode, the MTP3 alignment will fail (SLTM/SLTA failure). All messages received are then sent back on the link. This causes the SLT to fail since an SLTM is echoed back from the remote and no SLTA is returned. When the SINAP node determines that a link is in loopback mode, the sysopr DISPLAY-LINK screen can indicate this with a flag by setting an environment variable. This feature is available in the ITU-T variant. (See the SINAP/SS7 User’s Guide (R8051) for additional information.)

Enhanced Message DistributionThe SINAP software allows incoming MSUs to route to a client application based on the message-distribution information defined for the application. This feature enables a client application to:

• accept input directed to several client applications

• accept input from a specific originating point code (OPC) or a set of OPCs

• use the same subsystem number (SSN) as another client application

For each incoming MSU, the SINAP software checks the SSN in the “called-party” field and the OPC in the Routing Label field to see if they match the message distribution information defined for a client application. If a match is found, the SINAP/SS7 system routes the MSU to that client application. If no match is found, the discrimination criteria fails and the SINAP/SS7 system discards the MSU. The following two environmental variables specify how the SINAP/SS7 system handles discarded MSUs:

• UDTS_NO_OPC generates a UDTS message when the SINAP/SS7 system receives an MSU whose OPC is not valid for the destination application.



• DISCARDS_PER_ALARM=n generates an alarm after discarding n number of MSUs. If this variable is not defined, the SINAP/SS7 system generates an alarm after discarding five MSUs.

The SINAP/SS7 system supports dynamic updates to a client application’s message distribution configuration. If a user changes the selection criteria (SSNs or OPCs defined), or adds a new client application, the distribution selection information takes effect without interruption of service.

Enhanced Routing CapabilitiesThe SINAP/SS7 system provides several enhanced routing capabilities for TCAP messages, such as:

• Routing on Global Titles

The SINAP/SS7 system routes incoming and outgoing TCAP messages based on the global title (GT) element of the SCCP called- and calling-party addresses. This means that:

— An outgoing TCAP message can specify a called-party address containing both a GT and an SSN of 0. The message is sent to the client application regardless of the status of the destination.

— An outgoing TCAP message can specify a called-party address containing a global title and a DPC (with or without SSN). If the environment variable

GTT_WITH_BACKUP_DPC_SSN is defined, a routing indicator of RouteOnGTT will cause backup routing to occur (route the message to the point code specified by

a backup DPC2) if DPC2 is specified and the point code specified by DPC is not accessible.

— An incoming TCAP message whose called-party address contains a GT is passed to the client application. The SINAP/SS7 system performs syntax checking on the GT and rejects the message if the syntax is incorrect. However, it provides no global title translation.

— Global Title Translation (GTT). SCCP performs GTT when the address indicator of the SCCP called-party address of an inbound or outbound MSU is set to indicate route on GT.

• Routing on a Fictitious Originating Point Code (FOPC)—ANSI Variant Only

Using an FOPC enables the SINAP/SS7 system to set the MTP routing label’s OPC field to an OPC that is different from the calling-party’s OPC. The FOPC defines the OPC that the SINAP/SS7 system uses in place of the calling-party’s OPC in the MTP routing label. This functionality is typically used in handover processing. Using the FOPC, the SINAP/SS7 system can set the MTP routing label’s OPC field to any OPC, including the local node’s own signaling point (OSP).



The following MML commands allow creation, display, and deletion of an FOPC in the ANSI network variant of the SINAP/SS7 system.

• CREATE-FOPC defines the FOPC for the SINAP/SS7 system to use

• DISPLAY-FOPC displays an existing FOPC

• DELETE-FOPC deletes an existing FOPC

Route Set InitializationThe SINAP/SS7 software allows a newly created and configured route-set to be initialized in the PROHIBITED state instead of the ALLOWED state by defining an environment variable (RST_CONFIG_INIT_PROHIBIT).This feature is implemented only in the ITU-T network variant.

This feature applies only if the new route-set being created and configured is for a remote signaling point in the network and not for an adjacent point code (a signaling point that is connected directly through a linkset to the SINAP node).

For an adjacent signaling point (including adjacent STPs), the route-set status should be ALLOWED. There is no need to make the route-set status for the adjacent signaling point PROHIBITED.

The interaction of this feature with respect to MTP restart is as follows:

If the SINAP node is performing MTP restart, the new route-sets configured during the MTP restart are set to the ALLOWED state. And it is the responsibility of the adjacent STPs to send the appropriate TFP/TFR/TFA messages to the SINAP node during the MTP restart procedure.

If you use send_cm or sysopr to create and configure a new route-set to a nonadjacent signaling point when the SINAP node is not performing MTP restart, then the route-set state is set to PROHIBITED.

In addition, the SINAP node sends out Signaling Route Set Test (RST) messages to the adjacent STPs for prohibited destination(s) for which the new route-set(s) were configured. Then, RSTs are sent out every timer T10 seconds until the STPs send Transfer Allowed (TFA) messages to the SINAP node.

Custom Application Distribution The SINAP/SS7 system supports a custom application distribution (CAD) feature that enables a SINAP node to distribute TCAP message traffic to specific applications based on the value of selected, protocol-specific, message parameters. The CAD feature is an extension of the capabilities provided by enhanced message distribution. This includes the capability to filter and distribute message traffic based on OPCs and SSNs.



CAD currently provides a protocol-specific implementation based on the European Telecommunications Standards Institute (ETSI) Capability Set 1 (CS-1) Intelligent Network Application Protocol (INAP) standards. (ETSI CS-1 INAP is derived from the ITU-T CS-1 INAP standards which can also be supported by this feature.)

In the ETSI INAP CAD implementation, multiple applications can be registered with the SINAP/SS7 system for the same SSN and OPC criteria. In addition, each application can specify up to 64 ServiceKey values, which serves to uniquely identify the application among those registered for that SSN or OPC. The INAP ServiceKey parameter is defined to identify the specific service being requested, and is included in the InitialDP invoke operation used to initiate a dialogue between an IN switch and an SCP. The InitialDP invoke operation is always received in a TC_BEGIN TCAP package. The ETSI INAP CAD implementation decodes the invoke component and extracts the ServiceKey value in order to determine which application should receive the TCAP message. Special processing of the AssistRequestInstructions operation is also provided to allow this message to be correlated to an existing service instance.

ISUP Services FeatureThe SINAP/SS7 system supports base implementations of ISUP Services for ITU-T (CCITT), ANSI, NTT, and China, and country-specific versions of ISUP services that adhere to one of the base implementations, with modifications to conform to individual country standards for ISUP. An environment variable activates a specific version of the ISUP services feature on a SINAP/SS7 node. For example, ISUP_FEATURE=BELGIUM defines the Belgium version of the ISUP services feature. You must define the environment variable separately for each node on which the ISUP services feature is to be activated.

By default, the ISUP services feature is turned off. To activate the ISUP services feature, define the following environment variable before starting the SINAP/SS7 system.

ISUP_FEATURE=<VERSION NAME>

The version name represents a valid version of ISUP Services to be configured on the node.

N O T EThe version of ISUP Services you configure on a node must be compatible with the network variant you configure for that node.

The SINAP/SS7 system supports the versions of ISUP services shown in Table 3-1.

Table 3-1. Valid ISUP Versions and Network Variants


ANSI ANSI



You can define the ISUP Feature environment variable at the UNIX command level before starting or restarting the SINAP/SS7 system or you can uncomment the variable in your $SINAP_HOME/Bin/sinap_env[.sh or .csh] file to have the variable defined automatically each time you start the SINAP/SS7 system.

For more information on ISUP services, see the SINAP/SS7 ISDN User Part (ISUP) Guide (R8053).

Load ControlThe Load Control facility monitors the application’s congestion level and activates load control processing automatically when the application experiences overload conditions. For the SINAP/SS7 system to implement load control processing, load control must be enabled at each of the following levels.

• System—The SINAP/SS7 software is enabled to perform load control processing.

• Application—A particular application is enabled to perform load control processing.

• Instance—Individual application instances are enabled to perform load control processing.

See the SINAP/SS7 User’s Guide (R8051) for instructions on specifying the environment variable that enables load control on the SINAP/SS7 system.

ACIF_G500 BELGIUM BRAZIL CCITT FRANCE1 GERMANY ITALY ITU97 MEXICO NETHERLANDS Q767 SPAIN SWEDEN TAIWAN UK

CCITT

CHINA China

NTT NTT_IC

NTT

Table 3-1. Valid ISUP Versions and Network Variants(Continued)




N O T EYou must specify the load control environment variable before starting the SINAP/SS7 system or you can stop the system, activate the variable, and restart the system. Once the load control variable is specified to run on the SINAP/SS7 software, start the system and activate the load control process.

After configuring load control parameters for an application, you must issue an enable command to initiate load control operation. By default, this command automatically enables load control at the system and instance levels. To enable load control at the application level, issue the enable command and specify the application for which you want to enable load control.

If you disable load control at the system level, you cannot enable load control for a particular application until you first re-enable load control at the system level.

Likewise, if you disable load control for specific application instances, you must also explicitly re-enable load control for those instances. Enabling load control at the application level does not supersede the load control enabled settings for individual application instances. For example, if you disable load control for instances 1, 3, and 5 of an application whose specified SSN is 254, you must explicitly re-enable load control for those instances. Enabling load control for SSN 254 does not enable load control for instances 1, 3, and 5.

Simple Network Management Protocol (SNMP) (supported in HP-UX only)The SINAP Simple Network Management Protocol (SINAP/SNMP) is a subagent software application for the retrieval of SINAP configuration and status values within the HP-UX operating system’s SNMP Master Agent/Subagent structure. SNMP V1 and V2 standards are supported as defined in the associated Management Information Base (MIB). However, only get requests and get next requests are supported as all the objects defined in the MIB are read-only.

In addition, SNMP traps based on SINAP alarm events are generated and forwarded to a configurable network management station host. The SINAP Alarm Subagent process receives alarm events from the SINAP software, which it decodes in order to create either a specific or a generic SNMP trap. The Alarm Subagent is configurable so that specific alarms can be easily added or changed. See the SINAP/SNMP MIB Guide (R8065) for additional information.

System ComponentsThe SINAP/SNMP application consists of a SINAP Subagent process, a SINAP Alarm Subagent process, multiple SINAP Data Access Processes (DAPs), and multiple SINAP Alarm DAPs. The SNMP application functions within the structure of the HP-UX operating system’s SNMP Master Agent/Subagent structure.



• The Emanate Master Agent provides SNMP V1 and V2 compatibility and conformance, converting PDU requests to a common API and forwarding it to the appropriate Subagent.

• The SINAP Subagent process handles get and get next requests for SINAP configuration and status data. The Subagent will forward the request to the appropriate SINAP DAP process.

• A SINAP DAP process should be running on each SINAP Node in order to access shared memory for the retrieval of SINAP information.

• A SINAP Alarm DAP runs on each SINAP Node. The SINAP Alarm DAP receives alarm notifications from the SINAP software and forwards them to the SINAP Alarm Subagent. The alarm subagent transforms the SINAP alarm events to SNMP-specific trap events, forwarding the trap to the Master Agent via the Master Agent/Subagent API. The Master Agent formulates the V1/V2 SNMP trap and forwards it to the configured destinations.

Application EnvironmentThe SINAP/SNMP application is designed to support the distribution of processes across multiple platforms in order to distribute processing and disk storage load if necessary. Each SINAP Node should have a SINAP DAP and a SINAP Alarm DAP associated with it.

• The SINAP DAP registers with the CASL in order to access SINAP shared memory to retrieve the SINAP information.

• The SINAP Alarm DAP registers with the CASL in order to receive alarm notifications.

The DAP processes communicates with the SINAP Subagent and SINAP Alarm Subagent via socket communication. The Subagents communicate with the Master Agent via the Emanate Master Agent / Subagent API.

The SINAP/SNMP execution environment is depicted in Figure 3-1.



Figure 3-1. SINAP/SNMP Process Model

Partial Global Title TranslationA SINAP node normally uses all the address digits to perform global title translation (GTT) procedures. However, you can define an environment variable, in the CCITT/TTC/NTT/ANSI/China network variants, to enable a SINAP node to use only the first few digits to perform global title translations.

If you set the environment variable PARTIAL_GTT to enable partial global title translations on the node, you can further define two additional environment variables to specify the maximum and minimum number of digits to use in the translations. See the SINAP/SS7 User’s Guide (R8051) for information on setting environment variables.

Distributed Logical Point Code (DLPC)In the CCITT, ANSI, and China network variants the distributed logical point code (DLPC) feature supports distributed ISUP user applications on two SINAP nodes on different Continuum systems (or the same system). When the SINAP nodes are configured for the DLPC feature, up to 15 ISUP user applications per node can register for the same logical point code

E m an ate M aster A g en t

S IN AP A larm D ata Access P ro cess

S IN A P D ata A ccess P ro cess

S IN A P A larm S u b ag en tS IN AP S u b ag en t

S IN AP P ro cess S u ite


Highlights of SS7 Standards Implementation

(LPC) by using a destination point code (DPC) other than the SINAP nodes’ own signaling point code (OSP). From the SS7 network perspective, the LPCs appear to be behind a pair of signaling transfer points (STPs). The STPs are the DLPC-configured SINAP nodes executing on Continuum machines.

The ISUP user application registers with the SINAP node using a destination point code (DPC) other than the SINAP node’s own signaling point code (OSP). The OSPs (configured via the CREATE-OSP command) on the SINAP nodes act as logical point code routers (LPCRs) that function like a pair of STPs. Note that although the DLPC-configured nodes are addressed by the network as an STP pair for purposes of routing ISUP messages to the LPCs, they do not route messages to other SS7 nodes and cannot forward messages to actual SS7 point codes behind them.

For incoming ISUP messages on each DLPC node, the originating point code (OPC) in the MTP routing label specifies the remote service switching point (SSP) that originated (or sent) the message. The destination point code (DPC) in the routing label identifies the logical point code that the ISUP application registered on the SINAP node. The SINAP driver along with the assistance of the ISUP manager (using the intermodule agent (IMA)) routes the message to the correct ISUP user application on either machine based on the following:

In case a DLPC machine fails or is manually shutdown, the SS7 network routes all ISUP messages to the other DLPC machine. Note that the SINAP node network configurations on the two DLPC machines must match. See the SINAP/SS7 ISDN User Part (ISUP) Guide (R8053) for additional information.

Highlights of SS7 Standards ImplementationIn addition to the necessary SS7 functionality required by telephony customers, the SINAP/SS7 system provides several optional features for developing and deploying IN and AIN network services. These include:

• Signaling link selection (SLS) routing for circuit-specific data

• MTP user flow control

• Multiple link congestion levels

• Duplicate concerned point codes (DUCPCs)

• Network and cluster routing (ANSI and China network variants)

• Transfer Restricted Messages

• RSC Message Handling

The following sections describe these features.



Signaling Link Selection (SLS) Routing MTP-boundary users can ensure sequentiality of messages by routing based solely on the signaling link selection (SLS) and destination point code (DPC). For example, if a telephone user part (TUP) user employs the CIC for the SLS value for all messages pertaining to that circuit, all messages will go out over the same link to a particular DPC, even when load sharing over two link sets, thus ensuring they all remain in sequence.

In the ITU-T and China network variants, a four-bit SLS value can be set. In the ANSI network, MTP-boundary users can ensure sequentiality of messages by setting either a five-bit or eight-bit SLS value in the MTP routing label.

This feature is enabled by setting an environment variable. See the SINAP/SS7 User’s Guide (R8051) for information on setting environment variables.

Random SLS Generation (ANSI)The SINAP/SS7 software, by default, conforms to the ANSI T1.111.4 standard (1988) and uses a default SLS value of zero for the Route Set Congestion Test (RCT) message. However, always sending the RCT message on the same link within the same link set that the Transfer Controlled message (TFC) was received on always results in the RCT message testing the same network path, which may or may not be congested. If traffic is not evenly distributed this may result in over controlling (which will occur when the RCT message is routed on the path that is more likely to be congested) or under controlling (which will occur when the RCT message is routed on the path that is more likely to not be congested).

Random Link SelectionTo smooth out this effect, the SINAP system provides a feature for the user to enable the generation of a random signaling link selection (SLS) for RCT. The random SLS is placed in the SLS field of the outgoing RCT message.

To enable this feature, change $SINAP_HOME/sinap_env[.sh or .csh]:

MTP_RCT_LOAD_SHARING_SLS

N O T EThis feature is available for ANSI users only. Setting the environment variable has no effect for other NSP variants.

Eight-bit SLS Processing (ANSI)In the ANSI network variant, you can select an eight-bit SLS processing scheme for a national network using the CHANGE-SLSTYPE command. After the SINAP node has been started, you can use this command anytime to change the SLS processing scheme to either 8-bit or 5-bit. The initial default (after SINAP installation and startup) is 5-bit processing. You can also specify



8-bit or 5-bit SLS processing in the MML file by adding one of the following lines to the file immediately after the CREATE-OSP command:

CHANGE-SLSTYPE:TYPE=8CHANGE-SLSTYPE:TYPE=5

See the SINAP/SS7 User’s Guide (R8051) for detailed information on implementing this feature. See the SINAP/SS7 Programmer’s Guide (R8052) for considerations for application design and development.

MTP User Flow ControlThe MTP user flow control feature allows the SINAP/SS7 system to generate User Part Unavailable (UPU) messages to implement message flow control for the client application. Turn on this feature using an environment variable which sets a flag in shared memory.

When this variable is set, the SINAP/SS7 system generates the UPU message if the client application’s input queue is full or if the number of MSUs in the queue reaches a threshold defined by the formula, threshold = Q - (Q/10) where Q is the number of MSUs the queue can hold. For example, if a client application’s input queue holds 50 MSUs, the SINAP/SS7 system starts generating UPU messages when there are 45 MSUs in the input queue.

N O T EUPU functionality is supported by the CCITT, China, and ANSI network variants. The TTC and NTT network variants do not support UPU messages.

Defining UPU MessagesUPU functionality is part of MTP Level-3 signaling-traffic flow control. This feature enables MTP to send a UPU message to an origination user part (that is, an application) when the SINAP/SS7 system cannot deliver an incoming message to its destination. The origination application can then arrange to stop sending messages to that destination until it becomes available again.

To activate UPU functionality on a particular SINAP/SS7 node, define the environment variable on that node before starting the SINAP/SS7 system. You need not assign a value to the variable. The SINAP/SS7 system simply verifies that the variable exists. (See the discussion on defining SINAP/SS7 environment variables in the SINAP/SS7 User’s Guide (R8051) for instructions on defining variables.)

If the environment variable is not defined, the SINAP/SS7 system does not generate a UPU message when it cannot deliver an incoming message, even if the destination user part is unavailable. If the variable is defined, the SINAP/SS7 system generates a UPU message when it receives an incoming message that it cannot deliver. (See the SINAP/SS7 Programmer’s



Guide (R8052) for details on how the SINAP/SS7 system handles incoming UPU messages and requirements for applications.)

Link Congestion LevelsThe SINAP/SS7 system provides different methods of handling link congestion based on the network variant being implemented.

Variant DifferencesIn the ITU-T and China network variants there are three optional congestion levels you can configure:

• International one congestion onset and one congestion abatement option (default)

• National multiple congestion states with congestion priority option

• National multiple congestion states without congestion priority

You can implement the ITU-T and China national multiple congestion states by setting environment variables. For more information, see the SINAP/SS7 User’s Guide (R8051).

In the ANSI, TTC, and NTT, network variants, the SINAP/SS7 system automatically implements the National multiple congestion states (levels 0–3) with congestion priority. No environment variable is required to activate this option.

Congestion StatesMultiple link congestion states enable the SINAP/SS7 system to maintain up to four levels of signaling link congestion (0, 1, 2, and 3), and to set a link’s congestion status according to these levels. The system uses the same congestion onset, abatement, and discard levels in all variants of the SINAP/SS7 system.

The SINAP/SS7 system implements multiple link congestion levels on a system-wide basis so that when you specify the thresholds for each link-congestion level, the SINAP/SS7 system monitors each of its configured links for these thresholds. A link’s congestion status indicates the level of congestion that the link is experiencing based on the number of messages on the link’s SS7 driver queue. When the number of messages on the queue exceeds the number of messages allowed for a particular congestion level, the SINAP/SS7 system increases the value of the link’s congestion status to indicate that the link is becoming congested. As the link becomes less congested, the SINAP/SS7 system decrements the value of the link’s congestion status.

N O T EFor the national multiple congestion states with congestion priority option, if the congestion priority level (set within the application) is greater than the congestion discard level set for a DPC, the message is sent. If the congestion priority level is less than the discard level, the system discards the message. The



default congestion priority level is 0. (See the SINAP/SS7 Programmer’s Guide (R8052) for information on changing the congestion priority within an application.)

In all network variants of the SINAP/SS7 system you can display and change the settings of threshold values by issuing MML commands. You can also display the settings of congestion onset, abatement, and discard tables by using the SINAP/SS7 system debugger, sy, from any SINAP/SS7 login window. These processes are described in the SINAP/SS7 User’s Guide (R8051).

Automatic Congestion Control (ACC)Automatic Congestion Control is described in Section 2.11 of the ITU Q.764 standards for ISUP. In the SINAP ISUP, there are two main ways in which the ACC parameter is included in a Release (REL) message. The first is through the API, when calling a function to send a REL message. The application can reasonably be expected not to do this if the network does not want to see this parameter. The second way that ACC is included in a REL, however, is done automatically by the ISUP protocol software, when the level of available buffer resources is beneath an internal threshold at the time a REL is being sent. Because this is beyond the control of the application, an environment variable can be set to disable the automatic addition of the ACC parameter to a REL message. (See the SINAP/SS7 ISDN User Part (ISUP) Guide (R8053) for additional information.)

Changing System Tables The Change System Table (CHANGE-SYSTAB) command changes the values of timers and thresholds in the system tables. You can change the settings for the following types of timers and thresholds:

• MTP Level 2 timers

• MTP Level 3 timers (includes MTP restart, TCCO, and TCD)

• MTP thresholds

• SCCP timers (includes SCTX freeze timer and SCTY message reassembly timers for the CCITT and China network variants)

• ISUP Services timers (CCITT, NTT, and ANSI)

• SCCP SCOC timers

• SLT timers (CCITT, ANSI, and China)

• SRT timers (TTC and NTT)

Duplicate Concerned Point Codes (DUCPC)Defining a DUCPC creates a logical association between a client application (the primary application) and a remote point code that contains a copy of the same client application (the secondary application). This association between the primary and secondary client applications enables the remote point code to serve as a backup node for your Stratus system. Before the



primary client application goes out of service, it notifies the remote node of its intent. The remote node activates the secondary client application to take over processing for the primary client application.

N O T E S1. Only one DUCPC per local SSN can be defined.

2. The TTC and NTT variants do not support this feature.

Network and Cluster Routing (ANSI and China)The ANSI and China variants of the SINAP/SS7 system use the following ANSI point code format:

network-cluster-member

network is a network ID number between 1 and 254.

cluster is a network cluster ID number between 1 and 255 (or an X if network-only routing is defined). For example, 254-X-X.

member is the network member ID number between 1 and 255 (or an X if network or cluster routing is defined). For example, 254-056-X.

In the China network, the network-cluster-member components have the following equivalents:

The SINAP/SS7 system allows specification of an abbreviated point code by defining the network ID only, or both the network ID and the cluster ID. Typically, you must specify the

ANSI China

network main signaling area

cluster subsignaling area

member signaling point code



node’s complete point code, such as 254-056-002. The SINAP/SS7 system passes traffic using the point code scheme listed in Table 3-2.

Dynamic Route Provisioning (ANSI and China Variants)Dynamic route provisioning enables the SINAP/SS7 system to create a new route set for the express purpose of marking it unavailable. This is necessary because the SINAP/SS7 system designates a node as UNAVAILABLE by making the route set to the node unavailable. However, in cases where the only access to a particular node is through a route set that uses network or cluster routing, the SINAP/SS7 system cannot mark that node UNAVAILABLE without also marking other nodes in the network or network cluster UNAVAILABLE. To avoid this problem, the SINAP/SS7 system uses dynamic route provisioning to create a route set that uses member routing. The SINAP/SS7 system then marks this route set UNAVAILABLE to indicate that the node cannot accept traffic. When the SINAP/SS7 system receives a transfer allowed (TFA) message from the node, the SINAP/SS7 system marks the dynamically provisioned route set ALLOWED to indicate that the node is available.

For example, suppose the only access to the node whose point code is 254-56-2 is through a route set that uses network routing (that is, DPC=254-X-X). If the node cannot accept traffic, the SINAP/SS7 system must dynamically provision a route set that uses member routing (that is, DPC=254-56-2) and mark that route set UNAVAILABLE; otherwise, the SINAP/SS7 system would have to mark the original route set UNAVAILABLE, which would prohibit traffic to all nodes in network 254.

The SINAP/SS7 system performs dynamic route provisioning only when MTP Level 3 receives one of the following management messages. The SINAP/SS7 system does not perform dynamic route provisioning when passing traffic over a route set that uses network or cluster routing.

Table 3-2. SINAP/SS7 Point Code Formulas

Routing Method Description

Network routing (network ID only)

Specifies only the network ID. The SINAP/SS7 system passes traffic to the specified network (for example, 254-X-X). The destination can be any node in any cluster in this network (for example, 254-056-002, 254-090-006, 254-080-006).

Cluster routing (network ID and cluster ID)

Specifies a point code containing both the network ID and the cluster ID. The SINAP/SS7 system passes traffic to the specified network cluster ID. The SINAP/SS7 system passes traffic to the specified network cluster (for example, 254-056-X). The destination can be any node in this network cluster (for example, 254-056-002, 254-056-008, 254-056-016).

Member routing (complete point code)

If you specify a complete point code (for example, 254-056-002), the SINAP/SS7 system passes traffic directly to the specified node.



• For a route set that uses network or cluster routing, the SINAP/SS7 system dynamically provisions a member-routing route set whenever MTP Level 3 receives a transfer allowed (TFA), transfer prohibited (TFP), or transfer restricted (TFR) message.

• For a route set that uses network routing, the SINAP/SS7 system dynamically provisions a cluster-routing route set whenever MTP Level 3 receives a transfer cluster allowed (TCA), transfer cluster prohibited (TCP), or transfer cluster restricted message TCR).

Transfer Restricted Message (TFR)While the ANSI variant of the SINAP/SS7 system supports Transfer restricted messages (National option), this feature is not supported in the ITU-T variant default configuration (ITU-T November 1988 Recommendations). However, an environment variable can be set in the ITU-T variant to support the March 1993 ITU-T Recommendation Q.704 13.4 “Transfer restricted (National option).”

To activate the ITU-T Transfer restricted (National option) functionality on a particular SINAP/SS7 node, define the environment variable on that node before starting the SINAP/SS7 system. You need not assign a value to the variable. The SINAP/SS7 system simply verifies that the variable exists. (See the discussion on defining SINAP/SS7 environment variables in the SINAP/SS7 User’s Guide (R8051) for instructions on defining variables.)

TFR procedures are not supported by either the TTC or China variants of the SINAP/SS7 system. Instead, TTC supports the transfer-controlled (with congestion priorities) procedures described in JT-Q.704. The China variant supports the transfer-controlled (International network) procedures described in China’s August 1990 Technical Specifications for SS7.

RSC Message HandlingIn the ANSI network variant, an ISUP services option (ISUP_RSC_BLO_PER_EXP) can be enabled to have the SINAP/SS7 system perform the following events whenever the SINAP/SS7 system sends a blocking (BLO) message to a remote point code and starts timers IST12 and IST13 and the remote point code responds with a reset circuit (RSC) message:

• Return a release complete (RLC) message in response to the RSC message received from the remote point code

• After timer IST12 expires, the SINAP node sends a BLO message to the remote point code

• After timer IST13 expires, the SINAP node stops timer IST12 and uses timer IST13 expiration as the new schedule for sending BLO messages

If you do not define this environment variable, the SINAP node immediately responds to an RSC message from the remote point code with a BLO message (without waiting for timer IST12 to expire), then sends an RLC message (as described in section 3.1.4.4 of GR-317-CORE standard).


System Administration Features

Determining a Local Processor Outage Condition You can activate heartbeat messages between MTP Level 2 and Level 3 on a SINAP node to determine whether a local processor outage (LPO) has occurred on the node. When you activate these messages, MTP Level 2 sends a heartbeat message to MTP Level 3 and expects MTP Level 3 to respond with an I'm Alive heartbeat message with two seconds. If MTP Level 3 fails to return five heartbeat messages in a row within 10 seconds, MTP Level 2 considers the link to be in an LPO condition. In this case, the SINAP node notifies the link's remote end of the processor outage.

System Administration FeaturesThe following sections describe the features that the SINAP/SS7 system provides for system administration of a SINAP node.

SINAP/SS7 LogsThe SINAP/SS7 system maintains the types of logs described in Table 3-3.

Table 3-3. SINAP/SS7 Logs (Page 1 of 2)

Log Description

Alarm History Maintains information on alarms including a time stamp from the event causing the alarm, the alarm class, and the reason for the alarm. The SINAP/SS7 system creates a new version of this file each day.

Measurement Day Contains MTP, SCCP, and TCAP statistics that the SINAP/SS7 system collects. Measurement reports can display on a terminal or print. The SINAP/SS7 system creates a new version of this file each day.

Recent Change Command

Contains all changes made to the SINAP/SS7 database since the last system backup (since the current shared memory image was written to disk). Each entry contains a description of each MML command that affected the SINAP/SS7 node configuration and/or its status since the last backup. This log file ensures that the node configuration is always up-to-date, even if the node stops and restarts.

MML Command Maintains a record of all MML commands entered through any user interface. The log also contains records of the error messages associated with an unsuccessful attempt to execute a command. The SINAP/SS7 system creates a new version of this file each day.



Logging SINAP/SS7 Alarms and Error MessagesThe SINAP/SS7 system logs its alarms and error messages to an error log file and to the console.

The SINAP/SS7 device driver uses the UNIX System V, Release 4 STREAMS (the UNIX device driver) with a UNIX kernel-utility routine (cmn_err()) to log SS7 device-driver error messages.

The process is described in the following sections.

Operating System Error Log Files The SINAP/SS7 software logs error messages to the /var/adm/syslog directory (HP-UX operating systems) or the /var/adm/messages (Solaris operating systems) or the /var/log/messages file (Stratus ft Linux operating systems). The operating system uses the openlog(), syslog(), and closelog() commands to control entries to the system log (syslog.log for HP-UX and messages for Solaris and Stratus ft Linux operating systems). Refer to the man. pages for these commands for complete details on how they operate.

N O T E S1. The HP-UX operating system does not back up the system

error log file syslog.log under the /var/adm/sylog directory. Instead, the SINAP node runs a shell script, src/lb/bkup_syslog, at one minute to midnight. This timing ensures that the date associated with the saved file and its name is the same date on which the entries were created. The script copies the contents of syslog.log to syslog.log.YYMMDD. In doing so, it removes any log file copies older than the number of days passed as an argument to bkup_syslog. Default time is ten days.

2. The Solaris operating system does not back up the system error log file messages under the /var/adm directory. Instead, the SINAP node runs a shell script,

BITE Monitor Traces messages at any level of the SINAP/SS7 system. The SINAP/SS7 system creates a BITE Monitor Log whenever you execute the MML START-MON command.

Software Notebook Contains a list of all software event and error messages. The contents of this file can display on a terminal or print.

Table 3-3. SINAP/SS7 Logs (Page 2 of 2)

Log Description



src/lb/bkup_syslog, at one minute to midnight. This timing ensures that the date associated with the saved file and its name is the same date on which the entries were created. The script copies the contents of messages to messages.YYMMDD. In doing so, it removes any log file copies older than the number of days passed as an argument to bkup_syslog. Default time is ten days.

3. The Stratus ft Linux operating system does not back up the system error log file messages under the /var/log directory. Instead, the SINAP node runs a shell script, src/lb/bkup_syslog, at one minute to midnight. This timing ensures that the date associated with the saved file and its name is the same date on which the entries were created. The script copies the contents of messages to messages.YYMMDD. In doing so, it removes any log file copies older than the number of days passed as an argument to bkup_syslog. Default time is ten days.

In addition to the logging feature, the SINAP/SS7 system categorizes alarms and error messages by severity, as described in Table 3-4. In the table, _L indicates that the message will be logged to the appropriate system error log file only; _LP indicates that the message will be logged to the system error log file and display on the console.

Table 3-4. SINAP Alarm Severity Messages

Severity Description

CRITICAL Indicates a condition causing a severe disruption of service. This condition requires immediate attention. If you specify this value, make sure to specify the value, CRITICAL, for the severity field of the message’s syntax as it is defined in the Emsg file.

MAJOR Indicates a condition causing a serious disruption of service. If you specify this value, make sure to specify the value, NONRECOVERABLE_L or NONRECOVERABLE_LP, for the severity field of the message’s syntax as it is defined in the Emsg file.

MINOR A condition that is not likely to cause a serious disruption of service. If you specify this value, make sure to specify the value, RECOVERABLE_L or RECOVERABLE_LP, for the severity field of the message’s syntax as it is defined in the Emsg file.



MeasurementsYou can use the measurement-reporting commands to access the MTP, SCCP, and TCAP statistical information that the SINAP/SS7 system maintains while it is active. When you issue a measurement-reporting command, you specify the time period you want the report to cover using the start and stop arguments in the commands. The command generates a report presenting the statistics gathered for that time period. You can generate a report for a particular time period, such as a day, a week, a month, or longer.

You must set an environment variable before starting the SINAP/SS7 system to define the measurement interval you want to use. You can set it for a 5, 15, or 30-minute measurement interval. For example, a 15-minute interval allows you to produce reports for any time period between 15 minutes and one year. If you set it for 30-minutes, the SINAP/SS7 system produces reports for 30-minute time periods. The system default is 30-minutes if no time is defined for this environment variable.

You can save a measurement report to a file by specifying the file name and location using the Print to Filename argument. You can then print and view particular reports when needed.

This section describes all the measurement-reporting capabilities of the SINAP/SS7 system. Measurement-reporting tasks include:

• Reporting measurements

• Retrieving measurements

• Starting and stopping on-demand measurements

• Starting and stopping writing to a log file

• Dumping log files at specified intervals

You can issue commands directly from the UNIX prompt or use the Terminal Handler menus and prompts.

NOTICE Indicates a service-affecting condition; this message is provided for informational purposes only. If you specify this value, make sure to specify the value, INFO_L or INFO_LP, for the severity field of the message’s syntax as it is defined in the Emsg file.

Table 3-4. SINAP Alarm Severity Messages(Continued)

Severity Description



Using the Terminal Handler menu selection mode, select the Measurements Commands option from the Network Commands menu to display the measurements commands, shown in Figure 3-2.

Figure 3-2. Measurements Commands Menu

The Report Measurements menu offers options shown in the sample menu in Figure 3-3.

Figure 3-3. Report Measurements Menu

For each option on the menu, you can define the time period that the report covers, generate a report that presents the statistics or measurements gathered, save the report to a file, and print a copy of the report.

When you select one of the measurement-reporting options from the Report Measurements menu, the MML build screen displays, prompting you to enter a start date and time and an end date and time for your report. All measurements from the specified time period are retrieved and included in the report. The sample screen in Figure 3-4 includes sample entries to create the

Measurements Commands:1. Report Measurements2. Retrieve Measurements3. Start On Demand Measurement4. Stop On Demand Measurement5. Start Write Log File6. Stop Write Log File

Report Measurements:1. Report MTP Measurements2. Report SCCP Measurements3. Report TCAP Measurements4. Report ALL Measurements



MML command for a report for the time period of 12:00 AM on January 15, 1999 through 12:00 AM on January 16, 1999. User entries are in bold type.

Figure 3-4. Report Sample Screen

You specify the time and date information using these guidelines:

• For the start and end date, use the format [CC]YY-MM-DD where [CC]YY is the century and the year, for example, 1999. Optionally, you can enter only a two-digit year, for example, 99. MM is the month, for example, 01 for January. DD is the date, for example, 15. Include hyphens between the values, as in 1999-01-15, or optionally, 99-01-15.

Valid values for the year arguments include:

• CC = 19 or 20

• YY = 80 through 99 for century 19, or 0 through 38 for century 20

• MM = 01 through 12

• DD = 01 through 31

To generate a report for today’s measurements, you can enter the value, TODAY, as the date argument instead of using the format [CC]YY-MM-DD. If you do not specify an end date, the end date will be the same as the start date.

• For the start and end time, use the format HH:MM where HH is the hour and MM is the minutes. Include a colon between the values. If no end time is specified, the command generates a report for a 30-minute period, beginning at the specified start time. For example, if you specify 12:00 as the start time and do not specify an end time, the command generates a report for the 30-minute time period between 12:00 and 12:30.

MML as built isREPORT-MALL:

Date is specified as [CC]YY-MM-DDSpecify start date: DATE=1999-01-15DATE=1999-01-15Time is specified as HH:MMSpecify start time [where MM is 00 or 30 only]: TIME=00:00DATE=1999-01-15,TIME=00:00Date is specified as [CC]YY-MM-DDSpecify end date: DATE:1999-01-16DATE=1999-01-15,TIME=12:00,DATE=1999-01-16Time specified as HH:MMSpecify end time [where MM is 00 or 30 only]: TIME=00:00



Valid values for the start and end times are:

• HH = 1 through 24

• MM = Either 00 or 30

Report Measurement ConsiderationsWhen you issue commands to generate a measurement report, consider the following:

• Measurements are only generated while the SINAP node is active. If you issue a measurement-reporting command for a period of time during which the SINAP node was inactive, the command generates an empty measurement report.

• If the SINAP node was active for any amount of time during the specified time period, the measurement report will contain data, but it will not be obvious from the data how much of the time the SINAP node was active. If the measurement report contains MTP statistics, you can determine the amount of time that the SINAP node was active from the L2 Serv field of the MTP measurements section. The L2 Serv field shows the amount of time (in seconds) that the SINAP node was active during the time period covered by the measurement report. For example, suppose you generate an MTP measurement report for a 24-hour period of time during which the SINAP node was active for only 12 hours. Although the report appears to contain data for the specified 24-hour time period, the L2 Serv field indicates that the SINAP node was only active for 12 of the 24 hours.

• A blank measurement report indicates there is no measurement data for the specified time interval. This indicates one of the following conditions: the SINAP node was not running during the specified time period, the SINAP node was running but the measurement-collection process was turned off, or the log file containing those measurements was deleted from the $SINAP_HOME/Logs/system directory.

• If you issue one of the measurement-reporting commands and specify an invalid period of time, the command returns an error message.

For more information, see the SINAP/SS7 User’s Guide (R8051).

System DebuggerIn addition to the BITE Monitor and Log Analysis facilities, the SINAP/SS7 system provides the sy debugging tool to isolate and resolve problems. Use this tool to display the status and verify the availability of network elements. The sy utility troubleshoots by displaying most of the internal tables and structures in the SINAP/SS7 system. To run sy, log in to the SINAP/SS7 account on the node that you want to troubleshoot, then type sy at a UNIX prompt.

If the information resulting from a normal sy trace does not lead to the resolution of the problem, you can perform a gathersy trace. This facility is a script file that runs all possible sy commands for trace information and stores the output as ASCII text in the output file, problemx.x. The Stratus help desk personnel request the output from this file whenever you require their support to assist in defining a problem. You can run a gathersy trace by entering the command from a UNIX prompt.



Automatic Configuration Re-creationThe static2mml command provides a mechanism for saving an existing configuration of SINAP/SS7 network elements for re-creation at a later time. The static2mml command examines the specified SINAP/SS7 configuration, creates a list of the MML commands required to re-create this configuration, and writes this list of MML commands to the specified output.

Automated Start-up ProceduresSeveral features automatically start the SINAP/SS7 system and the client applications running on the SINAP/SS7 system. For example, you can use the script file, start_sinap, to start the SINAP/SS7 system, or you can automatically start the SINAP/SS7 system from the UNIX initialization file, /etc/inittab.

Starting the SINAP/SS7 Systems With the start_sinap Script FileThe start_sinap script uses the SINAP_HOME environment variable (defines the home directory of the SINAP user), and several commands it executes use other SINAP/SS7 environment variables.

At a UNIX command prompt, issue the command, start_sinap, to start the SINAP/SS7 system. Note that the command provides options for executing in verbose mode or test environment mode. When the console or the SINAP/SS7 error log displays the message, All SINAP Subsystems Started, the SINAP/SS7 system is active and you can start client applications.

start_sinap checks the SS7 daemon (ss7dmn) to determine whether the SINAP/SS7 system is running. If it is, the script file terminates to prevent the SINAP/SS7 system from terminating if it is already running.

Automatically Restarting SINAP/SS7 from the UNIX Initialization FileThe UNIX initialization file, /etc/inittab, provides a mechanism for automatically restarting the SINAP/SS7 system or respawning the SINAP/SS7 processes whenever you reboot the operating system or shut down the SINAP/SS7 system. During the SINAP/SS7 configuration process, the system prompts you to determine whether you want to start the SINAP/SS7 system from the UNIX initialization file. Answering y (yes) turns on this mechanism.

Starting a Client ApplicationThe SINAP/SS7 system provides two ways to start client applications.

• Using the startappl script file

• With the Utility Monitor



Starting a Client Application Using the startappl Script FileThe startappl script file allows client applications to automatically start up whenever you start the SINAP/SS7 system using the start_sinap script file. The node management parent executes this script after all the required child processes for node management, the Built-In Test Environment (BITE), MTP, and Signaling Connection Control Part (SCCP) subsystems are started and running.

To automatically start an application using the startappl script file, edit the file Bin/startappl using any UNIX-compatible editor, such as vi, and add the startup commands required for the application.

If you want to start up multiple applications with this script file, add the startup commands required for each application to be started.

Starting a Client Application with the Utility MonitorThe SINAP/SS7 Utility Monitor program, sinap_utlmon, starts, monitors, and restarts processes by executing user-defined command line arguments. For example, you can specify the startup commands required to start an application for the Utility Monitor to execute. You can specify multiple commands, including their associated arguments or parameters. The Utility Monitor starts each specified command and, after waiting one second, executes a kill (2) command with a parameter of 0 to determine if the command is still running. If it is, sinap_utlmon keeps the command alive by restarting it, if it exists. Otherwise, it considers the command “unrunable” and continues to process other commands.

After starting all specified commands, sinap_utlmon saves the command environment in the sinap_utlmon.dat environment file in the directory, $SINAP_HOME/Bin. The Utility Monitor continues to monitor and process commands and restart any failed commands.

The Utility Monitor detects command failures in two ways. First, if a command exits, sinap_utlmon normally receives a SIGCHLD (child death) signal. Otherwise, sinap_utlmon sends a kill (2) command periodically to detect if a child process is still alive. After starting all specified commands, sinap_utlmon saves the command environment in the sinap_utlmon.dat environment file in the directory, $SINAP_HOME/Bin. The Utility Monitor checks the status of all children, then sends a health response to the SINAP/SS7 system. If the SINAP/SS7 system does not receive the health response, it starts another instance of sinap_utlmon.

Accessing the User InterfaceThe SINAP/SS7 system provides two user interfaces: the Terminal Handler and the UNIX MML command interface. The following subsections describe the basic operations of the Terminal Handler interface and the UNIX MML command interface, which uses the send_cm command.



Terminal HandlerThe Terminal Handler interface is part of the Node Management subsystem and provides two ways to perform system operations, maintenance, and diagnostic tasks. Specifically, the Terminal Handler allows you to configure the SINAP/SS7 system, debug problems, and create and print reports. You can use the Terminal Handler in either of two ways:

• Menu selection mode—This method uses menus and interactive screens to build and execute task commands. You select a task from a menu and follow subsequent menus and screen prompts to enter information, which results in the generation of the MML command to perform the task.

• Free-form MML command mode—This method bypasses the menus and allows you to enter MML commands from the Terminal Handler command line.

You can access either method from within the Terminal Handler.

N O T ELogging in as sysopr automatically brings up the Terminal Handler because the .profile or .bash_profile (Stratus ft Linux operating system) for the user sysopr runs the Terminal Handler.

The Terminal Handler’s SINAP System Main Menu appears. Figure 3-5 shows the SINAP Main menu and submenus.



Figure 3-5. SINAP/SS7 Menu Hierarchy

S I N A P S y s t e m M a i n M e n u1 . S y s t e m C o m m a n d s2 . N e t w o r k C o m m a n d s3 . A p p l i c a t i o n C o m m a n d s4 . B I T E C o m m a n d s5 . E X I T M e n u ( R e t u r n t o U N I X )

S y s t e m C o m m a n d sB a c k u p N o d e

( B A C K U P - N O D E )R e s t o r e N o d e

( R E S T O R E - N O D E )C h a n g e B a c k u p o r P u r g e D a y

( C H A N G E - B K U P D A Y )D i s p l a y B a c k u p o r P u r g e D a y

( C H A N G E - P U R G E D A Y )D e l e t e F i l e

( D E L E T E - F I L E )R e a d T r e a t m e n t T a b l e

( R E A D - T R E A T )R e p o r t A l a r m

( R E P O R T - A L A R M )R e p o r t S o f t w a r e N o t e b o o k

( R E P O R T - N B O O K )S e t P r i n t e r D e f a u l t

( S E T - P R I N T E R )

N e t w o r k C o m m a n d sC r e a t e

( C R E A T E )C o n f i g u r e

( C O N F I G U R E )C h a n g e

( C H A N G E )D i s p l a y

( D I S P L A Y )D e l e t e

( D E L E T E )D u m p T a b l e

( D U M P - T A B L E )M e a s u r e m e n t s

( f o r e x a m p l e ,R E T R I E V E - N O M ,S T A R T - M E A S U R E ,S T O P - M W R I T E )

A p p l i c a t i o n C o m m a n d sD i s p l a y S S N

( D I S P L A Y - S U B S Y S T E M )B a c k u p A p p l i c a t i o n

( B A C K U P - A P P L )R e s t o r e A p p l i c a t i o n

( B A C K U P - A P P L )L o a d C o n t r o l

( f o r e x a m p l e ,S E T U P - L O A D - C O N T R O L ,D I S A B L E - L O A D - C O N T R O L )

B I T E C o m m a n d sM o n i t o r C o m m a n d s

( f o r e x a m p l e ,S T A R T - M O N , S T O P - M O N )

S c e n a r i o C o m m a n d s( f o r e x a m p l e ,S T A R T - S C E N , S T O P - M O N )

S t a r t D e b u g( f o r e x a m p l e ,S T A R T - D B G )

T e s t L i n k( T E S T - L I N K )

L o g A n a l y s i s( f o r e x a m p l e , F I N D ,S E L E C T )

D i s p l a y P r o c e s s V e r s i o n( D I S P L A Y - P R O C E S S -V E R S I O N )

(RESTORE-APPL)


Online Help Documentation (Man Pages)

UNIX MML Command LineFor each node, the SINAP/SS7 system maintains a global MML definition file (mmlverb) that defines the list of MML commands it recognizes. This file also maintains the privilege level associated with each MML command and its destination process in the SINAP/SS7 system. When users log in to the Terminal Handler, they are assigned privilege levels based on their user classes. Thus, users can send only those MML commands that have privilege levels less than or equal to their privilege levels.

No privilege level is associated with MML commands sent to application processes. Application processes are defined only the menu definition file (MDF), so this restriction does not apply to them.

Online Help Documentation (Man Pages)Help documentation for specific SINAP/SS7 tasks and procedures is available online in the form of UNIX online manual pages. In common usage, manual pages are referred to as man pages. Man pages are available to provide task descriptions and further information about using the product. A man page is available for each help topic.

To display SINAP/SS7 man pages, issue the man command at the UNIX prompt. If installed, the man pages are located in the directory, $SINAP_HOME/man/man1. (This discussion is described in the man page, displ-man.)

N O T EAlthough most SINAP/SS7 man pages describe Terminal Handler commands, the man command itself is a UNIX command. The Terminal Handler does not provide a shell feature. Therefore, to display a SINAP/SS7 man page, you must exit the Terminal Handler and return to the UNIX prompt to issue the man command.

The SINAP/SS7 installation process automatically appends the path name of the SINAP/SS7 man page directory to the MANPATH variable.


Chapter 4Hardware and Software

Requirements4-

The SINAP/SS7 system runs on the HP-UX, Solaris, and Stratus ft Linux operating systems available on the Distributed Network Control Platform (Continuum), the Sun Netra 20/T4 and SunFire V480, and the ftServer T Series hardware platforms. (See Table 4-1.) This chapter details the SINAP/SS7 hardware and software requirements.

Table 4-1 shows an overview of the major hardware and software requirements for the SINAP/SS7 system.

Table 4-1. SINAP/SS7 Hardware and Software Requirements

Hardware Operating System

Processor I/O Adapter Comments

Continuum Series 400 and Series 400-CO

HP-UX version 11.00.01

PA-8000PA-8500PA-8600

PCI Cards: U403 V.35 U420 T1/E1 (G.703)

32-Bit HP-UX operating systems require RSE and MRSE software v11.0 or later (Stratus-RSEDev)

HP-UX version 11.00.03

PA-8500PA-8600

U916 T1/E1 (G.703) 64-Bit HP-UX operating systems

Sun Netra 20/T4 and SunFire V480 series

Solaris 8 Operating Environment, release 2/02 or later

SPARC U915 or U916 T1/E1 (G.703)

64-Bit Solaris operating systems

Stratus ftServer T Series

Stratus ft Linux OS, release 2.1 or later

Intel Xeon U918 T1/E1 (G.703) 32-Bit Stratus ft Linux operating systems

Hardware and Software Requirements 4-1

Disk Space

Table 4-2 shows the maximum number of I/O adapter cards that can be used in each Continuum Series 400, Netra 20/T4, or SunFire V480 system configuration.

Disk SpaceTable 4-3 identifies the maximum SINAP/SS7 disk space requirements for installation. During preinstallation, the installation process determines the amount of free disk space available on the system. If available disk space is insufficient to install the SINAP/SS7 software, the installation process terminates and displays the message, Not enough disk space to install base SINAP system. You must free up the appropriate amount of disk space and try installing the software again.

Table 4-2. Maximum Number of Communication Cards per System

Operating System and Hardware

Processor Communications Cards Maximum Number of Cards

32-Bit HP-UXContinuum Series 400

PA-8000

PA-8500

U403 (4 links)U420 (8 links)

U403 (4 links)U420 (8 links)

88

88

64-Bit HP-UXContinuum Series 400

PA-8500PA-8600

U916 (32 links) 8

64-Bit SolarisNetra 20/T4 or SunFire V480

SPARC U915 or U916 (32 links) 3

32-Bit Stratus ft Linux ftServer T30

Intel Xeon U918 (32 links) 4

Table 4-3. SINAP Disk Space Requirements

Operating System Disk Space Required

HP-UX, Stratus ft Linux, and Solaris operating systems

120 MB (for installation)


Hardware Interfaces

Hardware InterfacesA SINAP/SS7 link provides the interface between the SINAP/SS7 system and the SS7 network. The physical transmission medium of a SINAP/SS7 link consists of an I/O adapter and the cable connected to it. The I/O adapter is considered the data terminal equipment (DTE) end of the connection. SINAP/SS7 links can be configured for use with two types of I/O adapters:

• G.703 T1/E1 Interface complies with the ITU-T Recommendation G.703 (1988). Each T1 or E1 line has multiple channels, each supporting a single logical link.

— Terrestrial 1 (T1) for ANSI

— European T1 (E1) for ITU-T (CCITT).

Two T1/E1 I/O adapters are supported on the Continuum hardware platform:

— U916 PCI card supports up to 32 links. (64-bit systems)

— U420 PCI card supports up to 8 links. (32-bit systems)

Two T1/E1 I/O adapters are supported on the Netra 20/T4 and SunFire V480 platforms:

— U915 PCI card supports up to 32 links.


One T1/E1 I/O adapter is supported on the Stratus ftServer T Series platforms:


• The SINAP/SS7 system supports the following IBM ARTIC (A Real Time Interface Coprocessor) cards for Continuum systems only.

— U403 Synchronous Adapter (4 port) using RS-422 or V.35/V.36.

U91x Card ClockingThe U91x family of cards are designed for use in codirectional synchronized or plesiochronous digital networks as described in ITU-T specification G.703. Clocking signals are derived from the incoming line signal.

All ports on an individual card must share a common clock source. This is done to allow a single the internal TDM bus to provide frame transport to and from all time-slots on all ports.

To understand clocking on the U91x card, it is important to understand how frames are moved in to and out of the card. For received frames, the FALC (framer chip) extracts data for an individual time-slot from the received super-frame and stores it in an elastic receive buffer. The internal TDM switch (T8105) reads data from the elastic buffer and moves it over the TDM bus to a previously allocated buffer in memory. For transmit frames, the procedure is reversed. The T8105 moves data from memory over the TDM bus to the FALC's elastic transmit buffer. The


U91x Card Clocking

FALC takes data from the elastic buffer and inserts it in the outgoing super-frame. There is a single T8105 (interface to memory). There is a FALC for each port (interface to the line).

There are three uses of clocking on the card.

1. The TDM clock is the clock signal used to control the internal TDM bus. This is the clock signal used to move data between memory and the elastic buffers.

2. The receive clock is used to control the reception of frames. This clock signal is used to extract data from the incoming super-frame and store it in the elastic buffer.

3. The transmit clock is used to control the transmission of frames. This clock signal is used to read data from the elastic buffer and insert it in the outgoing super-frame.

The TDM clock is usually extracted from the signal received on one of the ports. The specific port used is defined by the 'Primary Clocking Port', 'First Backup Clocking Port', 'Second Backup Clocking Port', and 'Third Backup Clocking Port' fields specified in the configuration. The card will attempt to extract the TDM clock from the primary source first. If clocking cannot be extracted from the primary source, the card will attempt to extract clocking from the port configured as the first backup source. If clocking cannot be extracted from the first backup source, the card will attempt to extract clocking from the port configured as the second backup source, etc. In this way the card would attempt to extract clocking from ports in the order specified by the configuration. If there is no clocking signal present on any of the ports, the card will use the internal crystal (Stratum level 3 accuracy) as the clock source. When a valid signal is detected on a port, the clock source is switched to that port. Note that the default clock source is port 1 (ports numbered 1 to 4). It is recommended that port 1 be used as the primary clock source.

The receive clock is always extracted from the ports receive signal. Thus, data is always moved into the receive elastic buffer using the clock signal extracted from the line. It is important to note that since data is removed from the elastic buffer using the TDM clock, data slips will occur if the receive clock is different from the TDM clock.

The transmit clock will be taken from the source configured in the 'Clocking' field. If 'MASTER' is specified, the internal crystal will be used as the transmit clock. If 'SLAVE' is specified, the TDM clock will be used as the transmit clock. If 'RECOVERED' is specified, the ports receive clock will be used as the transmit clock. Data is removed from the transmit elastic buffer using the transmit clock. It is important to note that since data is stored in the elastic buffer using the TDM clock, data slips will occur if the transmit clock is different from the TDM clock.

There is interaction between these clocking uses. For example, if port 1 is configured as the primary clock source and as a 'SLAVE' port, the clocking signal extracted from the port 1 signal will be used as the TDM clock and as the port 1 transmit clock.

A second example would be if port 1 is configured as the primary clock source and as a 'MASTER' port. In this case, the card's internal clock source would be used as the transmit clock. The network destination is expected to be in 'SLAVE' mode and to use the clocking


U91x Card Clocking

signal extracted from its receive signal as its transmit clock. Port 1 would use the received clocking signal as the receive clock and as the TDM clock.


U91x Card Clocking


Chapter 5Standards Compliance5-

Standards SupportThe SINAP/SS7 network variants adhere to the national and international standards for Signaling System 7 (SS7) described in the section following this one. See Table 4-3 in SINAP/SS7 Installation Guide (R8060) for the valid SINAP stack configurations of Network Service Part (NSP, i.e. MTP + SCCP layers) and TCAP layer.

ITU-T (CCITT) RecommendationsThe CCITT network variant of the SINAP/SS7 system is based on the Series Q - Switching and Signaling November 1988 (with many user-selectable features of the March 1993 Recommendations).

• Message Transfer Part (MTP) Q.701-Q.705 and Q.707

• Signaling Connection Control Part (SCCP) Q.711–Q.714

• Integrated Services Digital Network (ISDN) User Part Q.761–Q.764 and Q.766

• Integrated Services Digital Network (ISDN) User Part Q.767 (Feb. 1991)

• Transaction Capabilities Application Part (TCAP) Q.771–Q.775

ANSI StandardsThe ANSI network variant of the SINAP/SS7 system is based on the following specifications.

• ANSI T1.111 - (1990/1992) - Telecommunications - Signaling System No. 7 (SS7) - Message Transfer Part (MTP)

• ANSI T1.112 - (1990/1992) - Telecommunications - Signaling System No. 7 (SS7) - Signaling Connection Control Part (SCCP)

• ANSI T1.113 - (1990/1992) - Telecommunications - Signaling System No. 7 (SS7) - Integrated Services Digital Network (ISDN) User Part (ISUP Encoding and Decoding functions are based on 1988 Standards.)

• ANSI T1.114 - (1990/1992) - Telecommunications - Signaling System No. 7 (SS7) - Transaction Capabilities Application Part (TCAP)

Standards Compliance 5-1

Standards Support

TTC Standards (Japan)The TTC network variant of the SINAP/SS7 system is based on the following recommendations.

• 1994 JT-Q.700 Recommendations

• Message Transfer Part (MTP) JT-Q.701 to Q.704 and JT-Q.707

• Signaling Connection Control Part (SCCP) JT-Q.711 to JT-Q.714

• Transaction Capabilities Application Part (TCAP) JT-Q.771 to JT-Q.774

N O T ESINAP only has either ANSI or CCITT variant to choose for TCAP variant during SINAP configuration, and SINAP CCITT TCAP variant should be chosen for TTC since TTC 1994 TCAP protocol is actually based on ITU-T (CCITT) 1993 White Book TCAP.

NTT Standards (Japan)The NTT network variant of the SINAP/SS7 system is based on the following specifications.

• ISUP Services Specifications NTT-Q762-a, NTT-Q763-a, and NTT-Q764-a, Edition 1-1

• NTT-Q700 Specifications NTT-Q701-b, NTT-Q702-a, NTT-Q703-a NTT-Q704-b, and NTT-Q707-b

China SpecificationsThe China network variant of the SINAP/SS7 system is based on the following specifications.

• Technical Specifications for SS7 GF001-9001 August 1990

• Technical Specifications for SCCP and TCAP October 1994

Table 5-1 details the specific Recommendations/Specifications supported by the SINAP/SS7 software.


Standards Support

Table 5-1. Standards Supported by SINAP/SS7 (Page 1 of 2)

Recommendation/Specification

Boundary ITU-T (CCITT)

ANSI TTC (Japan)

NTT(Japan)

China Description

MTP Q.701 T1.111.1 JT-Q.701 NTT- Q701-b

Q.701 Functional description of the Message Transfer Part (MTP)

Q.702 T1.111.2 JT-Q.702 NTT- Q702-a

Q.702 Signaling Data Link

Q.703 T.1.111.3 JT-Q.703 NTT- Q703-a

Q.703 Signaling Link

Q.704 T1.111.4 JT-Q.704 NTT- Q704-b

Q.704 Signaling Network Functions and Messages

Q.705 T1.111.5 --- --- Q.705 Signaling Network Structure

Q.707 T1.111.7 JT-Q.707 NTT- Q707-b

Q.707 Testing and Maintenance

SCCP Q.711 T1.112.1 JT-Q.711 --- Q.711 Functional description of the Signaling Connection Control Part (SCCP)

Q.712 T1.112.2 JT-Q.712 --- Q.712 Definition and function of SCCP messages

Q.713 T1.112.3 JT-Q.713 --- Q.713 SCCP formats and codes

Q.714 T1.112.4 JT-Q.714 --- Q.714 SCCP procedures


Standards Support

TCAP Q.771 T1.114.1 JT-Q.771 --- Q.771 Functional description of the Transaction Capabilities Application Part (TCAP)

Q.772 T1.114.2 JT-Q.772 --- Q.772 Transaction Capabilities Information Element Definitions

Q.773 T1.114.3 JT-Q.773 --- Q.773 Transaction Capabilities Formats and Encoding

Q.774 T1.114.4 JT-Q.774 --- Q.774 Transaction Capabilities Procedures

Q.775 T1.114.5 --- --- Q.775 Definition and Functions of Transaction Capabilities Operations, Parameters, and Error Codes

ISUP Q.761 T1.113.1 --- --- Q.761 Functional Description of ISUP

Q.762 T1.113.2 --- NTT- Q762-a

Q.762 General Description of ISUP Signals and Messages.

Q.763 T1.113.3 --- NTT- Q763-a

Q.763 Message Formats and Field Codings

Q.764 T1.113.4 --- NTT- Q764-a

Q.764 Signaling Procedures

Q.766 T1.113.5 --- --- Q.766 Performance Objectives

Q.767 --- --- --- --- International ISDN Interconnection

Table 5-1. Standards Supported by SINAP/SS7 (Page 2 of 2)

Recommendation/Specification

Boundary ITU-T (CCITT)

ANSI TTC (Japan)

NTT(Japan)

China Description


Advantages of the 1993 TCAP Standards

Advantages of the 1993 TCAP StandardsThe SINAP/SS7 client applications adhering to the 1993 TCAP standards can interoperate with the services offered by some of the more complex applications in a network. These services are often not available to applications adhering to the 1988 standards.

Typically, an application providing services in an AIN (such as an application for translating 1-800 telephone numbers) is designed to operate with a particular message protocol. However, that protocol might not be supported by all the switches in the network. To enable the application to support applications running on those switches, the 1993 standards make it possible for an application to have one or more subapplications, each supporting a different variant of the application’s message protocol. An application running on a switch can access the AIN services by accessing the subapplication that supports its message protocol.

The AIN services subapplication handles information from the switch application and converts that information to the format required by the main AIN application, and vice-versa. For example, an ISDN application accessed by applications running on three different switch types might have three subapplications. Each one is accessed by the particular switch application using that variant of the AIN application’s message protocol.


Advantages of the 1993 TCAP Standards


Index

IndexIndex-

$SINAP_HOME/Bin/sinap_env, 2-20

AACC, 3-15adapters

see input/output adaptersalarms

severity leveldefining, 3-22

alarms and error messages, 3-21applications, registration limitations, 2-34ARTIC, 4-3Automatic Congestion Control, 3-15

Bbackup routing, GTT, 2-14, 3-4BITE

description of, 2-28Log Analysis program, 2-29log file, 2-29monitor facility, 2-29, 2-30

Built-In Test Environmentsee BITE

CCAC, xivCAD

see custom application distributionCASL

BITE functions, 2-26description of, 2-24IPC functions, 2-25Load control functions, 2-26SS7 functions, 2-24

COF, 2-15Common Application Service Layer

see CASLconcerned point codes, configuration

limitations, 2-33configuration

limitations and requirements, 2-32–2-40parameters, 2-31

congestion tables, displaying and changing settings, 3-15

connection-oriented services, 2-15CPC

see concerned point codesCS1, 3-6custom application distribution, ServiceKey, 3-6

Ddebugging tool, 3-25destination point codes

see DPCdisk space requirements, 4-2displaying man pages, 3-30distributed logical point code, 3-10DLL, 2-22DLPC, 3-10documentation

notation conventions, xiirelated, xiiirevision information, xiviewing, xiv

DPC, configuration limitations, 2-33drda_daemon processes, 2-34DUCPU, configuration limitations, 2-33duplicate concerned point codes

see DUCPUDynamic Linked Libraries

see DLLdynamic linked libraries

see DLLdynamic route provisioning, 3-17

Eenvironment variables

GTT_WITH_BACKUP_DPC_SSN, 2-35LOOPBACK_DISPLAY, 2-38MTP_ANSI88_RSR_RST, 2-39MTP_ANSI92_RESTART, 2-36MTP_ANSI92_TCCO, 2-37MTP_ANSI92_TCD, 2-37MTP_RCT_LOAD_SHARING_SLS, 3-12MTP_SLS4_LOAD_SHARE, 2-39MTP_WHITE_BOOK_RESTART, 2-36MTP_WHITE_BOOK_SLC, 2-37MTP_WHITE_BOOK_TCCO, 2-37MTP_WHITE_BOOK_TFR, 2-39

Index 1

Index

PARTIAL_GTT, 2-35TTC_WITH_NSTATE, 2-33

error detection and recovery, 2-21ETSI

see European Telecommunications Standards Institute

European Telecommunications Standards Institute, 3-6

Extended Unitdata Message, 2-16Extended Unitdata Service Message, 2-16

Ffree-form mode in the Terminal Handler, 3-28

GG.703

configuration limits, 2-32support for, 4-3

gathersy trace, 3-25global title

backup routing, 2-14description of, 2-14

global title translationalternate SCCP routing variable, 2-35description of, 2-14partial, 3-10

GTsee global title

GTTsee global title translation

GTT_WITH_BACKUP_DPC_SSN, 2-35

Hhardware

interfaces, 4-3requirements, 4-1

heartbeat messages, processor outage, 3-19HP-UX operating system, error log files, 3-20

II/O adapters

see input/output adaptersINAP, 3-6input/output adapters, 2-21instances per application, 2-34interfaces, physical, 1-6

interprocess communicationssee IPC

IOAsee input/output adapters

IPC, 2-25ISUP

basic bearer services, 2-18description of, 2-17Functionality, 2-18NTT, 2-18services, key features, 2-18Supplementary Services, 2-18supplementary services, 2-18

ISUP ServicesACIF_G500, 3-7ANSI, 3-6BELGIUM, 3-7BRAZIL, 3-7CCITT, 3-7CHINA, 3-7FRANCE 1, 3-7GERMANY, 3-7ITALY, 3-7ITU97, 3-7MEXICO, 3-7NETHERLANDS, 3-7NTT, 3-7NTT_IC, 3-7Q767, 3-7SPAIN, 3-7SWEDEN, 3-7TAIWAN, 3-7UK, 3-7

Llimitations, 2-32link congestion

changing congestion table settings, 3-15displaying congestion table settings, 3-15

link operating speeds, 2-32link sets, configuration limitations, 2-32load control, 3-7load-shared routes, configuration limitations, 2-32local processor outage, heartbeat messages, 3-19log

Alarm History, 3-19BITE Monitor, 3-20event and error messages, 3-20

2 SINAP/SS7 Technical Overview R8055-16

Index

Measurement Day, 3-19MML Command, 3-19Recent Change Command, 3-19

logical point code router, 3-10Long-Term Processor Outage, 2-8loopback, 3-3loopback detection environment variable, 2-38LPCR, 3-10LPO

see local processor outage

Mman command, 3-30man pages, displaying, 3-30Management Information Base

see MIBmanuals

notation conventions, xiirelated, xiiirevision information, xiviewing, xiv

measurement(s)Commands menu, 3-23handling, 3-25interval, defining, 3-22reports

considerations, 3-25saving to a file, 3-22setting interval, 3-23, 3-25

menu selection mode in the Terminal Handler, 3-28message

discrimination, 2-6distribution, 2-6routing, 2-7

Message Transfer Partsee MTP

messages, evening distribution of, 2-39MIB, 3-8MML command mode, 3-28MTP

description of, 2-2restart process, 2-9, 2-36time-controlled changeover, 2-7user flow control, 3-13

MTP_ANSI88_RSR_RST, 2-39MTP_ANSI92_TCCO, 2-37MTP_ANSI92_TCD, 2-37MTP_SLS4_LOAD_SHARE, 2-39

MTP_WHITE_BOOK_SLC, 2-37MTP_WHITE_BOOK_TCCO, 2-37MTP_WHITE_BOOK_TFR, 2-39MultiStack, 1-4, 3-2multivariant, 1-5

NNetra 20/T4 system

configuration limits, 2-32PCI card maximums, 4-2requirements for SINAP, 4-1supported PCI cards, 4-3

Network Cluster Routing, 3-16Network Service Part, 5-1network variants, 1-5Node Management

components, 2-26processes, 2-27subsystem, 2-26

NSP, 5-1NTT, 2-18

OOA&M

See Operations, Administration, & Management

Operations, Administration, & Management, 2-28

Ppartial global title translation, 3-10PARTIAL_GTT, 2-35PCI cards

maximum configurations, 4-2maximum supported, 2-32

Peripheral Component Interconnectsee PCI cards

physical interfaces, 1-6processes, configuration limitations, 2-34processor outage, 2-8

see also MTP time controlled changeover, 2-7

Rrandom SLS generation, 3-12remote processor outage, 2-8

see also MTP time controlled changeover, 2-7route sets, configuration limitations, 2-32

Index 3

Index

routes, configuration limitations, 2-32routing capabilities, ensuring sequential, 2-39

SSCCP

backup routing, 2-14description of, 2-12

SCOC, 2-15ServiceKey, 3-6Short-Term Processor Outage, 2-8Signaling Connection Control Part

see SCCPsignaling data link, 2-3

see also MTPsignaling link

configuration limitations, 2-32description of, 2-3management, 2-4see also MTPselection, 3-12, 3-13

signaling message handling, 2-6signaling network

description of, 2-3management, 2-4messages with nonzero SLCs, 2-37see also MTP

signaling point restart control, 2-9signaling route management, 2-4signaling traffic management, 2-4Simple Network Management Protocol

see SNMPSINAP

features and benefits, 1-6handling measurements, 3-25node, 1-4stack, 1-4variant, 1-4

SLMsee signaling link management

SLSsee signaling link selection

SMHsee signaling message handling

SNMsee signaling network management

SNMP, 3-8software requirements, 4-1SRM. See signaling route management

SS7signaling unit types, 2-20stack components, 2-2stack configurations, 1-5

standards, 5-1standards, supported, 1-6, 5-1Start Monitor command, 2-30startappl script file, 3-27starting BITE monitor, 2-30START-MON command, 2-30STM

see signaling traffic managementSTM processes

changeback, 2-5changeover, 2-5controlled rerouting, 2-5forced rerouting control, 2-5link availability control, 2-6link set control, 2-6signaling route control, 2-5

Stop Monitor command, 2-30STOP-MON command, 2-30STREAMS, 2-25SunFire V480 system

configuration limits, 2-32PCI card maximums, 4-2requirements for SINAP, 4-1

SVR4, 1-6sy utility, 3-25system administration, 3-19system debugger, 3-25

TT1/E1 links, configuration limits, 2-32TCAP

description of, 2-17variants, 1-5

TCCOdescription of, 2-7implementation, 2-8MTP_ANSI92_TCCO, 2-37MTP_WHITE_BOOK_TCCO, 2-37processing overview, 2-7

TCDdescription of, 2-10environment variable for, 2-37

Terminal Handlermenu selection mode, 3-28


Index

MML command mode, 3-28TFR, 3-18

description of, 3-18environment variables for, 2-39

time-controlled changeoversee TCCO

time-controlled diversionsee TCD

TPRC, 2-9tracking network events

see logTransaction Capabilities Applications Part

see TCAPtransfer restricted message

see TFR

UU403 PCI card

configuration limits, 2-32description of, 4-3

U420 PCI cardconfiguration limits, 2-32description of, 4-3

Utility Monitor program, 3-27

XXPG3, 1-6XUDT, 2-16XUDTS, 2-16

Index 5

Index


SINAP/SS7 Technical Overview -...

Documents

Transcript of SINAP/SS7 Technical Overview -...