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.
There are two types of SS No. 7 application users:
- Applications that use service-related (but not circuit-related) transactions between the switches and network databases.
- 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.
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.
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:
- Associating the user’s requests (whose nature is discussed in a later section) with the responses.
- 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:
- Both success and failure are reported.
- Only failure is reported.
- Only success is reported.
- 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.
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.
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:
- Call setup.
- Conversation (includes pure data exchange).
- 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:
-
- 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.
No comments:
Post a Comment