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:
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.
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.
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:
The signalling link level contains the three basic types of frames or signalling units listed below:
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.
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.
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:
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 Signalling Network Level of SS#7 is a connectionless (datagram) style service which handles two primary functions:
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:
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:
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:
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 .
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.
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
The ISUP Message consists of the following six parts:
There are nine categories of ISUP message types. These message types are:
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:
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 TCAP is based on the encoding rules provided in CCITT Recommendation X.409. A TCAP message consists of:
Each data element of a TCAP message is divided into three parts:
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
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:
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
The CCITT recommendation also specify the following areas: