SS7 Overview

back | next | index

Signalling System Number 7 (SS#7) is the protocol used by the telephone companies for interoffice signalling. In the past, in-band signalling techniques were used on interoffice trunks. This method of signalling used the same physical path for both the call-control signalling and the actual connected call. This method of signalling is inefficient and is rapidly being replaced by out-of-band or common-channel signalling techniques.

A network utilizing common-channel signalling is actually two networks in one:

First there is the circuit-switched "user" network which actually carries the user voice and data traffic. It provides a physical path between the source and destination.
The second is the signalling network which carries the call control traffic. It is a packet-switched network using a common channel switching protocol.

The original common channel interoffice signalling protocols were based on Signalling System Number 6 (SS#6). Today SS#7 is being used in new installations worldwide. SS#7 is the defined interoffice signalling protocol for ISDN. It is also in common use today outside of the ISDN environment.
The primary function of SS#7 is to provide call control, remote network management, and maintenance capabilities for the inter- office telephone network. SS#7 performs these functions by exchanging control messages between SS#7 telephone exchanges (signalling points or SPs) and SS#7 signalling transfer points (STPs).
The switching offices (SPs) handle the SS#7 control network as well as the user circuit-switched network. Basically, the SS#7 control network tells the switching office which paths to establish over the circuit-switched network. The STPs route SS#7 control packets across the signalling network. A switching office may or may not be an STP.

Message Transfer Part: Signalling Data Link Level

The SIGNALLING DATA LINK LEVEL of SS#7 is equivalent to Layer 1 of the OSI model. The signalling data link level is defined as a full-duplex digital channel operating at 64 Kbps. In North America, AT&T and Telecom Canada actually run at 56 Kbps.

Message Transfer Part: Signalling Link Level

The SIGNALLING LINK LEVEL of SS#7 is equivalent to Layer 2 of the OSI model. This level is responsible for assuring reliable transmission across the link. As a Layer 2 protocol, the signalling link level must ensure that:

Transmitted blocks are delivered with no errors, losses or duplication.
The blocks are delivered in the proper order.
The receiver is capable of exercising flow control over the transmitted data.

The signalling link level contains the three basic types of frames or signalling units listed below:

FISU - Fill In Signal Unit
LSSU - Link Status Signal Unit
MSU - Message Signal Unit

FISU:

The FILL IN SIGNAL UNIT is sent when no other signal units are available. The SS#7 specification calls for FISUs to be sent with a single intervening flag whenever the link is idle. This is recommended so that link-error information is available even when there is no higher-level information to be sent. In this way, problems will be recognized quickly and corrective actions can be implemented with minimal loss of service. FISUs include:

      FLG  - Opening Flag                8 Bits
      BSN  - Backward Sequence Number    7 Bits
      BIB  - Backward Indicator Bit      1 Bit
      FSN  - Forward Sequence Number     7 Bits
      FIB  - Forward Indicator Bit       1 Bit
      LI   - Length Indicator            6 Bits
      UB   - Unused Bits                 2 Bits
      CK   - Check Bits (CRC)           16 Bits
      FLG  - Closing Flag                8 Bits

In a FISU the length indicator is always 0. Opening and closing flags are shared between frames in SS#7. Thus consecutive FISUs can repeat every 48 bits. At the specified 64 Kbps line speed for an SS#7 link, this equates to a throughput of 1,333 frames per second. Any equipment used on an SS#7 link must be able to handle these high frame rates.

LSSU:

The LINK STATUS SIGNAL UNIT is used by the signalling link level to bring the link into alignment. Like FISUs, LSSUs are sent continuously end to end, with a single intervening flag. The format of an LSSU is identical to the FISU except that the length indicator is always set to 1 or 2. The extra bytes in an LSSU are the SF or status field byte or bytes.
At this time, only a single-byte SF has been defined. Only three bits of this byte are used. These bits provide the following status indications:

    - 000 "O"  Status Indication Out Of Alignment
    - 001 "N"  Status Indication Normal Alignment
    - 010 "E"  Status Indication Emergency Alignment
    - 011 "OS" Status Indication Out Of Service
    - 100 "PO" Status Indication Processor Outage
    - 101 "B"  Status Indication Busy

Alignment is achieved when both sides of a link are sending "N" or "E" LSSUs. After a brief proving period, the link goes "in service" and FISUs and MSUs occupy the link in place of LSSUs.

MSU:

The MESSAGE SIGNAL UNIT carries the actual upper-level information. For example, if ISDN User Part (ISUP) information is to be sent, it will be carried in an MSU.
The length indicator of the MSU can vary from 3 to 63. A length indication of 63 indicates that the Service Info field is 63 or longer. The bytes preceding the length indicator are the same as for the FISU and LSSU.
The first byte following the length indicator is the SIO or Service Information Octet. The SIO is broken into two 4-bit fields:

The service indicator bits indicate what type of message is being carried.

The sub service field indicates whether the frame is for a national or international network.

                     MSU Service Indicator Bits
      -------------------------------------------------------
      0000 Signalling Network Management Messages
      0001 Signalling Network Testing and Maintenance Messages
      0010 Spare
      0011 SCCP - Signalling Connection Control Part
      0100 TUP  - Telephone User Part
      0101 ISUP - ISDN User Part
      0110 Data User Part (call and circuit related messages)
      0111 Data User Part (facility registration & cancellation)

The bytes following the SIO are the Signalling Information Field or SIF. The SIF consists of two sub fields:

The Standard Label (which is a 32-bit address field containing source and destination address information

The User Data

Message Transfer Part: Signalling Network Level

The Signalling Network Level of SS#7 is a connectionless (datagram) style service which handles two primary functions:

Message handling
Signalling network management

The MESSAGE HANDLING functions provide:

Message Discrimination: Determines at each signalling point if the message is to be forwarded to the message routing or message distribution function
Message Routing: Selects the link to be used for each message that is to be forwarded
Message Distribution: Determines which user part at Layer 4 is to receive the message (i.e., TUP, ISUP, etc.) [This selection is based on the level 2 SIO.]

The SIGNALLING NETWORK MANAGEMENT function is unique to SS#7. Due to the criticalness of the SS#7 networks, this facility is provided within the protocol. SS#7 networks are designed with redundant links and with dynamic rerouting.

The signalling management function:

Monitors the status of all of the various links and makes routing decisions based on its findings
Communicates its findings to remote signalling points

Signalling Connection Control Part (SCCP)

The primary function of SS#7 is call control. This function requires high-speed, low-delay, connectionless communications links. The lower three layers of SS#7 (the MTP) are designed to optimize the protocol for this type of operation. Thus, the Signalling Network Level of SS#7 does not provide all of the features required of the network layer by the OSI model.
The SCCP provides additional connectionless services as well as basic connection-oriented services. The combination of the MTP and SCCP conforms to the OSI reference model. That combination (MTP and SCCP) is referred to as the Network Services Part (NSP) of SS#7. Thus, the primary value of the SCCP is that it provides a means for allowing higher-layer OSI protocols to communicate over an SS#7 link.
Many of the major functions of an SS#7 link do not require these capabilities. These functions, such as the Telephone User Part, bypass the SCCP layer. SIGNALLING CONNECTION CONTROL PART (cont)

The SCCP provides five PROTOCOL CLASSES OF SERVICE:

Class 0 - Basic Connectionless Service

Class 1 - Sequenced Connectionless Service enhances Class 0 by providing sequencing

Class 2 - Basic Connection-Oriented Service supports either:

A temporary or a permanent connection between nodes

Multiplexing of different SS#7 connections onto one MTP network connection

Does NOT provide flow-control and sequencing.

Class 3 - Flow-Control Connection-Oriented Service provides:

Connection-oriented service with flow control

Expedited data

Message-loss detection

Sequence checks

Class 4 - Error Recovery and Flow Control Connection-Oriented Service provides error recovery from messages, missequenced messages, and corrupted messages

SCCP messages are carried in MSU-type frames. MSUs carrying SCCP messages have the Service Indicator bits of the SIO set to 0011. An SCCP message contains five parts:

Routing Label
Message Type
Mandatory Fixed Part
Mandatory Variable Part
Optional Part

The message type consists of a single byte and is mandatory in all messages. This byte uniquely defines the function and format of each SCCP message. The message types listed on the following page have been defined:

          MESSAGE TYPE                          CLASS
  --------------------------------------- 0 - 1 - 2 - 3 - 4
  CR    - Connection Request              .   .   X   X   X
  CC    - Connection Confirm              .   .   X   X   X
  CREF  - Connection Refused              .   .   X   X   X
  RLSD  - Released                        .   .   X   X   X
  RLC   - Release Complete                .   .   X   X   X
  DT1   - Data Form 1                     .   .   X   .   .
  DT2   - Data Form 2                     .   .   .   X   X
  AK    - Data Acknowledgment             .   .   .   X   X
  UDT   - Unidata                         X   X   .   .   .
  UDTS  - Unidata Service                 X   X   .   .   .
  ED    - Expedited Data                  .   .   .   X   X
  EA    - Expedited Data Acknowledgment   .   .   .   X   X
  RSR   - Reset Request                   .   .   .   X   X
  RSCM  - Reset Confirmation              .   .   .   X   X
  ERR   - Error                           .   .   X   X   X
  IT    - Inactivity Test                 .   .   X   X   .

Telephone User Part (TUP) and ISDN User Part (ISUP)

The Telephone User Part (TUP) and the ISDN User Part (ISUP) both define the telephone signalling functions supported by SS#7.
The TUP was defined first and is widely deployed outside of North America.
The ISUP was defined later for ISDN applications, but its telephone signalling functions are applicable outside of the ISDN environment. ISUP is being deployed in North America.

Telephone User Part

TUP:: The TUP is used in establishing calls, clearing calls, passing charging information, and a number of other telephone signalling functions. The first portion of the TUP is the label. The label consists of 40 bytes and is broken into three fields (codes):

DPC -

Destination Point: Identifies the destination of the TUP
OPC -: Origination Point: Identifies the origination of the TUP
CIC -: Circuit Identification: Identifies the telephone circuit among those interconnecting the source and destination

The next fields, heading codes H0 and H1, identify message type. H0 identifies the message group and H1 identifies the message within the group. (Currently H1 defines 53 different messages.) The groups currently assigned by H0:

 H0   ABREV  MESSAGE DEFINITION
----  -----  ---------------------------------------------
0001   FAM   Forward Address Message
0010   FSM   Forward Setup Message
0011   BSM   Backward Setup Message
0100   SBM   Successful Backward Setup Information Msg.
0101   UBM   Unsuccessful Backward Setup Information Msg.
0110   CSM   Call Supervision Message
0111   CCM   Circuit Supervision Message
1000   GRM   Circuit Group Supervision Message
1001         Reserved
1010   CNM   Circuit Network Management Group

ISDN USER PART

ISUP:

The ISUP defines the procedures and functions used within the network in order to provide the users with circuit- switched services for voice and non-voice calls. The basic service provided by the ISUP is the establishment and clearing of circuit-switched calls. Some of the other services provided by ISUP are:

Closed user group

User access to calling party address identification

User access to called party address identification

Redirection of calls

Call completion to busy subscribers

Malicious call identification

The ISUP Message consists of the following six parts:

Routing Label: Origination Point Code (OPC); Destination Point Code (DPC); Signalling Link Selection (SLS)
Circuit ID: Specifies circuit ID related to the message
Message Type: Specifies the type of ISUP message being sent (The definition of the following bytes depends on the message type.)
Mandatory Fixed: Contains parameters that are mandatory for the type of message sent
Mandatory Variable: Contains mandatory parameters which are variable in length
Optional Part: Contains optional parameters

There are nine categories of ISUP message types. These message types are:

Forward Address Message

General Setup Message

Backward Setup Message

Call Supervision Message

Circuit Supervision Message

Circuit Group Supervision Message

In-Call Modification Message

Node-To-Node Message

User-To-User Message

Transaction Capabilities Application Part (TCAP)

TCAP:

The Transaction Capabilities Applications Part (TCAP) of SS#7 is used to control non-circuit-related communications between two or more signalling nodes.

The original implementations of TCAP were created to support calling card and 800-number applications in North America by the North American T1 standards committee. This version, referred to as Issue 1 of ANSI TCAP, was submitted to the CCITT as the U.S. contribution to the CCITT TCAP working group. The CCITT reworked the North American version of TCAP and this reworked version was released in the 1988 edition of CCITT recommendations.

The U.S. CCITT committee attempted, without success, to have the 1988 CCITT version of TCAP adopted as Issue 2 of ANSI TCAP. The ANSI committee responsible for TCAP has agreed to work towards an Issue 2 of TCAP which is compatible with the CCITT version.

In the OSI model, TCAP is an Applications Layer entity. In SS#7, the MTP and SCCP levels of the protocol combine to form a standard OSI Network Layer interface.

The layers between SCCP and TCAP are the:

Presentation layer

Session layer

Transport layer

Together they are referred to as the Applications Service Part (ASP) by ANSI and Intermediate Services Part (ISP) by CCITT.

The current implementations of TCAP are all transaction- oriented connectionless services. Connectionless services do not require the services of the ASP/ISP; thus, in current implementations, TCAP interfaces directly with SCCP.

ANSI Issue 1, Revision 2 of TCAP Definition

ANSI Issue, 1 Revision 2 TCAP is based on the encoding rules provided in CCITT Recommendation X.409. A TCAP message consists of:

A transaction portion
One or more component portions

Each data element of a TCAP message is divided into three parts:

Identifier
Length of contents
Contents

The IDENTIFIER uses the two most-significant bits to indicate the Identifier Class.

      CLASS              BITS   USAGE
      ----------------   ----   --------------------------
      Universal           00    Universal
      Application-Wide    01    International TCAP
      Context-Specific    10    Context-Specific
      Private Use         11    National TCAP/Private TCAP

The Identifiers unique to the ANSI implementation of TCAP use the Private Use Class of Identifier. The Identifiers currently defined are listed on the following pages:

      TRANSACTION PORTION IDENTIFIERS          HGFEDCBA
      -------------------------------------    --------
      Unidirectional Package Type              11100001
      Query With Permission Package Type       11100010
      Query Without Permission Package Type    11100011
      Response Package Type                    11100100
      Conversation With Permission Pkg Type    11100101
      Conversation W/O Permission Pkg Type     11100110
      Transaction ID                           11000111
      Component Sequence                       11101000
      Invoke Component (Last)                  11101001
      Return Result Component (Last)           11101010
      Return Error Component                   11101011
      Reject Component                         11101100
      Invoke Component (Not Last)              11101101
      Return Result Component (Not Last)       11101110
      Component ID                             11001111
      National TCAP Operation Code             11010000
      Private TCAP Operation Code              11010001
      Parameter Set                            11110010
      National TCAP Error Code                 11010011
      Private TCAP Error Code                  11010100
      Problem Code                             11010101
      ACG Indicators                           10000001
      Standard Announcement                    10000010
      Customized Announcement                  10000011
      Digits                                   10000100
      Standard Use Error Code                  10000101
      Problem Data                             10000110
      SCCP Calling Party Address               10000111
      Transaction ID                           10001000
      Package Type                             10001001
      Service Key                              10101010

1988 CCITT TCAP Definition

The 1988 CCITT TCAP recommendation is based on encoding rules provided in CCITT Recommendation X.209. The TCAP message consists of a Transaction Portion and a Component Portion.
The Transaction Portion contains elements used by the transaction sublayer. One of the Transaction Portion elements is the Component Portion, and it contains the elements used by the Component sublayer. Each information element in a TCAP message has three fields:

Tag
Length
Contents

The CCITT and ANSI Tag definition are similar. The Tag uses the two most significant bits to define the Class. The Tags currently defined are listed on the following pages:

      TRANSACTION PORTION:

      MESSAGE TYPE TAG            HGFEDCBA
      --------------------        --------
      Unidirectional              01100001
      Begin                       01100010
      (Reserved)                  01100011
      End                         01100100
      Continue                    01100101
      (Reserved)                  01100110
      Abort                       01100111

      COMPONENT PORTION:
                                  HGFEDCBA
                                  --------
      COMPONENT PORTION TAG       01101100


      COMPONENT TYPE TAG          HGFEDCBA
      --------------------        --------
      Invoke                      10100001
      Return Result (Last)        10100010
      Return Error                10100011
      Reject                      10100100
      (Reserved)                  10100101
      (Reserved)                  10100110
      Return Result (Not Last)    10100111

Operations/Maintenance Applications Part

OMAP:

The Operations and Maintenance Part of SS#7 (OMAP) provides for the overall network management of the SS#7 network. There is active discussion within the CCITT on expanding the role of OMAP to include management of the backbone circuit-switched (User) network. The CCITT recommendation specifies the following Operations, maintenance, and administration procedures for the SIGNALLING NETWORK to deal with the following functions:

Management Of Routing Data

Circuit Validation Test

MTP Routing Verification Test

Reception Of A Message From An Unknown Destination

SCCP Routing Verification Test

Long Term Measurement Collection

On-Occurrence Measurement Reporting

Delay Measurements

Clock Initialization

Operations

The CCITT recommendation also specify the following areas:

Operations and maintenance procedures for the EXCHANGES.
Operations and maintenance procedures for both the SIGNALLING NETWORK and the EXCHANGES.
Requirements on the PROTOCOLS used to support the operations and maintenance procedures.
TIMER definitions and values, and PERFORMANCE TIME definitions and values.

back | next | index