1.1 Introduction

1.2 SS7 Architecture

1.3 ISUP Layer Services

1.1 Introduction

The SS7 ISDN User Part Developer's Reference Manual explains how to create applications that utilize the SS7 ISUP layer.

Subsequent sections of this document describe the general characteristics and operation of the ISUP APIs, as well as a detailed specification of the messages and function calls that comprise them.

1.2 SS7 Architecture

Figure 1 shows the SS7 software architecture in a typical system with separate host applications handling the data/control (ISUP) interface, system configuration, and system alarms. The system consists of the following components:

On the TX board:

• The ISUP task running on the TX board. This task implements the SS7 ISUP layer.

• The MTP task running on the TX board. This task implements the SS7 MTP 2 (data link) layer and the SS7 MTP 3 (network) layer.

• The (optional) SCCP task running on the TX board. This task implements the SS7 SCCP layer.

• The (optional) TCAP task running on the TX board. This task implements the SS7 TCAP layer.

• The TX Alarms Manager task. This task collects unsolicited alarms (status changes) generated by the SS7 tasks and forwards them to the host for application-specific alarm processing.

On the host:

• A TX driver for the native host operating system which provides low level access to the TX device from the host.

• A function-call based API which provides the application with a high-level interface to the ISUP protocol layer services.

• A function-call based API which provides the application with a high-level interface to the ISUP management layer services.

• A log process is provided for capturing alarms and saving them to a text file.

• A configuration process is provided which reads the SS7 configuration file(s) and loads the configuration to the TX tasks at system startup.
  
  
  Figure 1. SS7 System Architecture

1.3 ISUP Layer Services

The ISUP process maintains a database of circuits and circuit groups being controlled by the application process and keeps track of the state of each circuit. The initial characteristics of each circuit [group], such as the circuit identification code (CIC), direction, and destination point code, and routing instructions are specified in the ISUP configuration file read in at startup time by the ISUP process.

For outgoing call setup requests, the ISUP process can select a circuit for the connection based on called party number or transit network selection, depending on the contents of the application's connection request; or, the application can specify the circuit to be connected. The ISUP process can optionally insert a pre-configured calling party number on behalf of the application if desired. For incoming calls, the ISUP process verifies the circuit state and characteristics (such as, bearer capability) are compatible with the incoming call request parameters before passing the incoming call indication up to the application. For both incoming and outgoing calls, the ISUP process provides all necessary connection timers, notifying both the application and far exchange with necessary indications (connection clearing) when critical timers expire.

The ISUP process provides circuit supervision for the duration of the connection, adjusting the circuit state as needed based on requests from the application and ISUP messages received from the far exchange. As mentioned above, the ISUP process provides connect and disconnect timing, handles circuit [group] blocking and unblocking (updating the state of the affected circuit(s) as needed), and detects protocol errors on behalf of the application.