SS7

Signaling System #7 (SS7) is the protocol that makes the public telephone networks operate, within themselves and across boundaries. Unlike Q.931, which is designed for simplicity, SS7 is a complete, Internet-like architecture and set of protocols, designed to allow call signaling and control to flow across a small, shared set of circuits dedicated for signaling, freeing up the rest of the circuits for real phone calls.

SS7 is an old protocol, from around 1980, and is, in fact, the seventh version of the protocol. The entire goal of the architecture was to free up lines for phone calls by removing the signaling from the bearer channel. This is the origin of the split signaling and bearer distinction. Before digital signaling, phone lines between networks were similar to phone lines into the home. One side would pick up the line, present a series of digits as tones, and then wait for the other side to route the call and present tones for success, or a busy network. The problem with this method of in-band signaling was that it required having the line held just for signaling, even for calls that could never go through. To free up the waste from the in-band signaling, the networks divided up the circuits into a large pool of voice-only bearer lines, and a smaller number of signaling-only lines. SS7 runs over the signaling lines.

It would be inappropriate here to go into any significant detail into SS7, as it is not seen as a part of voice mobility networks. However, it is useful to understand a bit of the architecture behind it.

SS7 is a packet-based network, structured rather like the Internet (or vice versa). The phone call first enters the network at the telephone exchange, starting at the Service Switching Point (SSP). This switching point takes the dialed digits and looks for where, in the network, the path to the other phone ought to be. It does this by sending requests, over the signaling network, to the Service Control Point (SCP). The SCP has the mapping of userunderstandable telephone numbers to addresses on the SS7 network, known aspoint codes. The SCP responds to the SSP with the path the call ought to take. At this point, the switch (SSP) seeks out the destination switch (SSP), and establishes the call. All the while, routers called Signal Transfer Points (STPs) connect physical links of the network and route the SS7 messages between SSPs and SCPs.

The interesting part of this is that the SCP has this mapping of phone numbers to real, physical addresses. This means that phone numbers are abstract entities, like email addresses or domain names, and not like IP addresses or other numbers that are pinned down to some location. Of course, we already know the benefit of this, as anyone who has ever changed cellular carriers and kept their phone number has used this ability for that mapping to be changed. The mapping can also be regional, as toll-free 800 numbers take advantage of that mapping as well.

Signalling System No. 7 (SS No. 7)

The SS No. 7 standards are essential to a wide range of convergence products for a number of reasons, of which we list three here. First, Internet access servers need to access the PSTN signaling network by means of the SS7 gateways. Second, IP telephony gateways need to interact with the PSTN switches in order to establish PC-to-phone (or phone-to-PC) calls and IP trunking. Third, IP telephony gateways, soft switches, and access servers need to access the PSTN service control. For some of these purposes, SS No. 7 needs to be ported into the IP environment (that is, carried by IP-based networks), which, as mentioned before, is one activity carried by the IETF sigtran working group.

SS No. 7 was standardized (based on the common channel experience) in order to satisfy the need for a common signaling interface both within and across the national borders. Another benefit of standardization has been cost eduction through multivendor interoperability. As it happens, European and American SS No. 7 versions differ from one another, and even in the United States implementations in some interexchange carriers’ networks differ from those of local exchange carriers. Nevertheless, signaling across networks works very well, at least as far as the provision of the basic call is concerned.

The overall objective of SS No. 7 is to provide a reliable means of information transfer in support of call control; remote control; and operations, management, and administration. ITU also specifies SS No. 7 measurements and performance requirements. When printed double-sided and stacked one page on top of another, the SS No. 7 ITU-T Recommendations Series (Q.7xx—starting with Recommendation Q.700) is about a yard high. These Recommendations define all aspects of a four-layer protocol stack as depicted in Figure 1.

Figure 1: The SS No. 7 stack.

There are two types of SS No. 7 application users:

1. 
   
   
   Applications that use service-related (but not circuit-related) transactions between the switches and network databases.
2. 
   
   
   Switching applications that rely on the exchange of circuit-related information in order to set up, test, maintain, and tear down trunks.

Applications of the first type (for example, Intelligent Network) use the Transaction Capabilities Application Part protocol; applications of the second type use either the Telephone User Part (TUP) protocol or ISDN User Part (ISUP), which has been the SS No. 7 response to the ISDN. Both TC and ISUP rely on the Signalling Connection Control Part (SCCP) protocol, which in turn runs on top of the Message Transfer Part (MTP), the lowest layer in the SS No. 7 stack. ISUP also uses MTP directly; TAP uses only MTP.

The rest of this section sheds a bit more light on MTP, SCCP, TC, and ISUP, respectively.

Message Transfer Part (MTP)

As Figure 1 demonstrates, MTP has three levels. The first two levels correspond to the physical and data link layers of the OSI model, respectively. The third level (Level 3) performs certain functions (such as routing and data delivery) of the OSI network and transport layers. In addition, MTP is responsible for the network management functions associated with the control of routing tables and other network configuration data.

Physically, MTP can be implemented in the endpoints (that is, switches, network databases, or operation and maintenance centers) or service transfer points (STPs), or both. The messages exchanged between any pair of these elements may traverse more than one intermediate STP. MTP does not guarantee in-sequence arrival and otherwise provides an unreliable connectionless transport mechanism to its users.

Each endpoint and each STP are identified by a unique point code, which is an exact equivalent of an IP address in the Internet. The MTP routing label contains three parts: the originating point code (OPC), destination point code (DPC), and signaling link selection (SLS). (The SLS field is used, among other things, for load sharing among STPs.) MTP can assign a specific hard link value [called signaling link code (SLC)] to an SLS, which is always done for MTP management information messages.

In order to recognize the user (for example, SCCP or ISUP) of the incoming message, MTP employs a combination of the service indicator (identifying the user) and a 2-bit-long network indicator (which, in combination with OPC and DPC, determines whether national or international signaling is involved) fields.

Note that MTP procedures include congestion control, of which MTP informs its users.

Signaling Connection Control Part (SCCP)

SCCP, described in Recommendations Q.711 through Q.716, provides both connectionless and connection-oriented transport services. The services are grouped into the following four classes (enumerated from 0):

0	Basic connectionless class, which does not guarantee in-sequence delivery.
1	In-sequence-delivery connectionless class.
2	Basic connection-oriented class.
3	Flow-control connection-oriented class.

SCCP peers address each other by the DPC–global title–subsystem number (SSN) triplet. Global title is defined in Recommendation Q.700 as a set of “dialled digits or another form of address that will not be recognized in the SS No. 7 network.” The subsystem number identifies a user part or TC application entities.

When the connection-oriented classes services are used, SCCP provides a reliable transport mechanism. During connection establishment, certain routing functions are provided by SCCP as well (in addition to those provided by MTP), as noted in Recommendation Q.711.

Transaction Capabilities (TC) Application Part

TC is most typically used as a protocol between a switch and a network database, but it can also be used between two network databases. The primary user of TC is Intelligent Network, but there are other users (such as mobile service applications, administration of closed user groups, and transaction-oriented operations and maintenance applications). The main feature of all these applications is best defined through an affirmation—they are transaction-oriented—and a negation—they are not circuit-related.

The word transaction-oriented simply means that TC is designed to support the request/response type of communications, although in reality the protocol has evolved to support a dialogue of multiple requests and responses issued by either side of the communications link. Figure 2 depicts the place of TC in SS No. 7 and its structure.

Figure 2: Transaction capabilities (TC) application part.

First of all, TC has two sublayers: the component sublayer (CSL) and transaction sublayer (TSL). We don’t concentrate on the TSL, but we should describe the CSL, which provides the actual interface to the TC user. The CSL is responsible for:

1. 
   
   
   Associating the user’s requests (whose nature is discussed in a later section) with the responses.
2. 
   
   
   Handling all abnormalities.

In a nutshell, the CSL provides the appearance of a (remote) procedure call to the user. In other words, CSL operations can be viewed (and implemented) by a programmer as procedure calls. To this end, TC is partially aligned with the capabilities of ITU-T Recommendations X.219 and X.229, developed jointly by ITU-T and the ISO. The CSL messaging unit is called a component. The user initiating a transaction issues an INVOKE component, which contains the operation code and arguments of the operation. Recommendation Q.771 defines four classes of operations in respect to the expected response:

1. 
   
   
   Both success and failure are reported.
2. 
   
   
   Only failure is reported.
3. 
   
   
   Only success is reported.
4. 
   
   
   Neither success nor failure is reported.

The response can also carry rejection to perform the requested operation. What is most interesting is that the responder may, in turn, send its own INVOKE component before returning a response, by means of linking the components into a dialogue. (A classical example of such dialogue is the freephone service. When a switch asks the service control point to translate a number, the latter requests that the switch connect to the device that plays announcement and collects digits. After the service control gets what it needs, it finally sends the response back to the switch.) The response components are:

• 
  
  
  RETURN RESULT NOT LAST. Contains the list of parameters defining the result, and also indicates that other RETURN components are going to be issued (thus, the response may be segmented).
• 
  
  
  RETURN RESULT LAST. Contains the list of parameters defining the result.
• 
  
  
  REJECT. Contains the problem code (for example, malformed component).
• 
  
  
  ERROR. Contains the error code (the error being the result of performing the operation).

TC is based only on the connectionless capabilities (that is, classes 0 and 1) of SCCP and uses the same addressing mechanism as SCCP.

ISDN END-TO-END CALL SETUP

In the example illustrated by Figure 3, the calling party terminal sends a Q.931 SETUP message to its local switch, which parses it, finds it correctly formed, and in turn sends the ISUP INITIAL ADDRESS MESSAGE (IAM) (of the forward setup category) to the appropriate transit (tandem) switch as indicated in its call routing table. Concurrently, the originating local switch sends the Q.931 CALL PROCEEDING message back to the calling party.

Figure 3: Example of the ISDN end-to-end call setup.

Meanwhile, the tandem switch finds the terminating local switch in its routing table and forwards the IAM message to it. It so happens that the calling party address (CPA) is not sent as part of the IAM, but the terminating switch decides that it needs the CPA to complete the call. For this reason, the terminating switch sends the ISUP INFORMATION REQUEST (INR) message (of the general setup category) with the appropriate parameter (called a request indicator), indicating that the CPA is needed, back to the tandem switch, which passes it on to the originating switch.

The originating switch decides that it can comply with the request, and does so by issuing the ISUP INFORMATION message (also of the general setup category), which is propagated to the terminating local switch. The terminating switch sends the Q.931 SETUP message to the called party terminal, which responds with the Q.931 ALERTING message. The terminating switch also sends the ISUP ADDRESS COMPLETE MESSAGE (ACM) (of the backward setup category) on the backward path. When the originating switch receives this message, it informs the calling party that the alerting of the called party has begun by issuing the Q.931 ALERTING message in turn. By that time the path has been established.

When the calling party answers the call, its station sends the Q.931 CONNECT message to the terminating local switch, which follows up with the ISUP ANSWER message (of the call supervision category). The tandem switch does the same. Finally, the originating switch sends the Q.931 connect message back to the calling party terminal. The ISDN B-channel between the calling and called parties has now been established.

ISDN User Part (ISUP)

As mentioned, SS No. 7 was adapted to interworking with Q.931, and so became the system of choice for the ISDN network support for call management. Call management is in turn realized through switch-to-switch signaling. ISUP is the protocol used for switch-to-switch signaling.

ISUP entities address each other with the MTP addressing scheme, augmented by circuit identification, which refers to a specific trunk.

The ISUP call model views three call phases:

1. 
   
   
   Call setup.
2. 
   
   
   Conversation (includes pure data exchange).
3. 
   
   
   Call teardown.

Accordingly, the ISUP messages are used to establish, maintain, and terminate different phases of a call. In addition, calls originating from ISDN terminals may be supplied with more detailed call progress information.

ISUP employs two methods—link-by-link (which passes messages through all intermediate exchanges, where they can be modified, hot-potato-style) and end-to-end messages that are exchanged between the ISUP endpoints (for example, local exchanges or international gateways). The end-to-end method typically employs either the connectionless or connection-oriented services of the SCCP; employing the latter makes things much simpler.

Unfortunately, there are too many ISUP messages to describe here. (Just the minimum internationally recognized set contains 29!) Instead, we list the basic message categories, followed by a call setup example:

• 
  
  
  Forward setup. The messages in this category are involved in setting up a call with particular characteristics in the direction toward the called party.
• 
  
  
  Backward setup. The messages in this category complete the call establishment (when it is possible) in the direction from the exchange containing the called party toward the calling party. Accounting and charging procedures belong in this category.
• 
  
  
  General setup. The messages in this category carry additional call-related information needed to set up a call.
• 
  
  
  Call supervision. The messages in this category are notifications of events like the call being answered, the circuit being released, or the need for an international operator intervention.
• 
  
  
  Circuit supervision. The messages in this category are all kinds of notifications of the events related to circuits allocated for a call.
• 
  
  
  Circuit group supervision. The messages (primarily of request/response type) in this category relate to circuit groups rather than individual circuits, and are used for network management purposes (for example, as preventive measures—such as call blocking on the indicated trunk groups, or circuit group status queries).
• 
  
  
  In-call modification. The messages in this group support modification of the existing call characteristics (for example, a change from a voice call to a data call) or invoking a particular medium (facility).
• 
  
  
  End-to-end. The messages in this group include user-to-user signaling independent of call control messages.

Technologies : Common Channel Signaling (SS7)

Common Channel Signaling (SS7)
The signaling system #7 (SS7) is an international standard network signaling protocol that allows common channel (independent) signaling between telephone network elements. SS7 system protocols are optimized for telephone system control connections and they are only directly accessible to telephone network operators.

Common channel signaling (CCS) is a separate signaling system that separates content of telephone calls from the information used to set up the call (signaling information). When call-processing information is separated from the communication channel, it is called “out-of-band” signaling. This signaling method uses one of the channels on a multi-channel network for the control, accounting, and management of traffic on all of the channels of the network.

An SS7 network is composed of service switching points (SSPs), signaling transfer points (STPs), and service control points (SCPs). The SSP gathers the analog signaling information from the local line in the network (end point) and converts the information into an SS7 message. These messages are transferred into the SS7 network to STPs that transfer the packet closer to its destination. When special processing of the message is required (such as rerouting a call to a call forwarding number), the STP routes the message to a SCP. The SCP is a database that can use the incoming message to determine other numbers and features that are associated with this particular call.

In the SS7 protocol, an address, such as customer-dialed digits, does not contain explicit information to enable routing in a signaling network. It then will require the signaling connection control part (SCCP) translation function. This is a process in the SS7 system that uses a routing tables to convert an address (usually a telephone number) into the actual destination address (forwarding telephone number) or into the address of a service control point (database) that contains the customer data needed to process a call.

Intelligence in the network can be distributed to databases and information processing points throughout the network because the network uses common channel signaling A set of service development tools has been developed to allow companies to offer advanced intelligent network (AIN) services.

Figure 1 shows the basic structure of the SS7 control signaling system. This diagram shows that a customer’s telephone is connected to a local switch. The local switch converts the dialed digits to a SS7 signaling message. The SS7 network routes the control packet to its destination using its own STP data packet switches and separate interconnection lines. In some cases, when additional services are provided, SCPs are used to process requests for advanced telephone services. This diagram also shows that the connections used for signaling are different than the voice connections. There are multiple redundant links between switches, switching points, and network databases.


Figure 1: Signaling System 7 (SS7) Network