SS7
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:
123456789FLG - Opening Flag 8 BitsBSN - Backward Sequence Number 7 BitsBIB - Backward Indicator Bit 1 BitFSN - Forward Sequence Number 7 BitsFIB - Forward Indicator Bit 1 BitLI - Length Indicator 6 BitsUB - Unused Bits 2 BitsCK - Check Bits (CRC) 16 BitsFLG - 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:
123456- 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.
12345678910MSU Service Indicator Bits-------------------------------------------------------0000 Signalling Network Management Messages0001 Signalling Network Testing and Maintenance Messages0010 Spare0011 SCCP - Signalling Connection Control Part0100 TUP - Telephone User Part0101 ISUP - ISDN User Part0110 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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
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:
123456789101112H0 ABREV MESSAGE DEFINITION---- ----- ---------------------------------------------0001 FAM Forward Address Message0010 FSM Forward Setup Message0011 BSM Backward Setup Message0100 SBM Successful Backward Setup Information Msg.0101 UBM Unsuccessful Backward Setup Information Msg.0110 CSM Call Supervision Message0111 CCM Circuit Supervision Message1000 GRM Circuit Group Supervision Message1001 Reserved1010 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.
1 2 3 4 5 6 |
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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
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.