Chapter 7 - General Description of SCCP Functions | Signaling System #7, Fifth Edition (McGraw-Hill Computer Communications Series)

Chapter 7 General Description of SCCP Functions



		The Signaling Connection Control Part (SCCP) is much like X.25 in the services it provides. The only really significant feature added by SCCP is global title translation. Many applications within the SS7 network rely on this routing feature. We will discuss global title translation in full detail a little later.



		The SCCP is a protocol used for accessing databases and other entities within the network. As part of level four, SCCP relies on the services of the Message Transfer Part (MTP), or of M3UA, M2UA, SCTP, or TALI in IP networks, just like the other level-four protocols in the SS7 network. The primary difference between the two services is in the addressing scheme and routing. SCCP also provides connection-oriented and connectionless services, whereas the MTP is strictly datagram.



		The SCCP provides both connection-oriented and connectionless services, with connectionless services currently supported in ANSI networks. However, if one examines the procedures closely, the protocol uses a number of procedures and parameters to emulate connection-oriented services. In fact, SCCP has the ability to maintain a dialog with another network entity, just as if there was a virtual connection between the two resources. SCCP does not, however, establish a connection before beginning the dialog-hence, the reason it is considered connectionless. Still, the service it delivers is very much like connection-oriented service, which is why I classify it as a connection-oriented ''like" service.



		When we look at the SS7 protocol stack, there is an indication that the ISDN User Part (ISUP) also uses the SCCP services to deliver messages in the network. The ITU, ANSI, and Telcordia standards all provide procedures for ISUP services over SCCP, but this has not yet been implemented. The thought is to allow SCCP to deliver end-to-end signaling capability for ISUP messages, rather than node-to-node via the MTP.



		It is unclear whether this capability will ever be implemented. One would think that with Advanced Intelligent Network (AIN) features, this may be a useful feature, but even this standard has not been fully defined to date.



		When we examine the services provided by the SCCP in contrast to the MTP, we can begin to understand the fundamental differences between the two. MTP provides routing, sequencing, and flow control. However, SCCP also provides these functions. The difference lies in the user of these services.



		The SCCP relies on the MTP to route its payload from one node to another node. This means that SCCP must provide enough information to MTP that these functions can be carried out. SCCP provides the same functions, but the user is either the Transaction Capabilities Application Part (TCAP) or the ISDN User Part (ISUP). This means that the functions used at SCCP will be somewhat different from those used by MTP. Let's look at the basic services that SCCP provides, and you can refer to Chapter 6 on MTP to compare the two.



		Services of SCCP



		The SCCP is divided into five classes of service, or protocol classes. Each protocol class defines which level of service SCCP is to provide. The five classes of service are



		Class 0-basic connectionless



		Class 1-sequenced connectionless



		Class 2-basic connection-oriented



		Class 3-flow control connection-oriented



		Class 4-error recovery and flow control connection-oriented



		The first two classes, class 0 and class 1, support the connectionless environment, which is all that is used in today's networks. Classes 2, 3, and 4 are used for connection-oriented services and, even though well-defined, they are not used in today's network.



		Class 0 services provide for the basic transport of TCAP messages (the payload does not need to be TCAP, although this is the most commonly used today). There are no procedures used to segment data or provide any sequencing of data. Typically, class 0 is used to deliver noncritical messages (such as database queries) when guarantee of delivery is minimal.



		Class 1 is used whenever more than one SCCP message exists for a transaction. A transaction is something that takes place at the TCAP level. The best way to define a transaction is as a function that is being requested by the application level.



		For example, if there is a feature to be invoked at a remote switch, TCAP would send a message with several components. Each of the components would direct a particular portion of the switch to provide a function. All of the functions combined cause the feature to be invoked. The entire process is considered a transaction.



		When this occurs, the TCAP message may be too big to fit in one SCCP message. SCCP must then provide segmentation of the data and possibly sequencing as well. The segmentation function divides the TCAP header and the application entity data into smaller segments, which can then easily fit within multiple SCCP messages. The TCAP header and the application-level information are left intact before the segmentation.



		In other words, the TCAP header is not duplicated for each of the SCCP messages. Rather, it is segmented, as is, right into the payload portion of the first SCCP message. The sequencing function is used to ensure that the SCCP messages are received in the same order in which they were sent.



		The routing function at level three examines the protocol class parameter to determine if the signaling link selection (SLS) field should remain the same or be rotated. If messages are part of the same transaction, the SLS is not rotated, ensuring the messages are received in sequence. If rotation of the SLS field is allowed, associated messages may be received out of sequence.



		To ensure that the messages that are part of the same transaction are delivered in sequence, the routing function at level three examines the protocol class parameter to determine if the SLS field should remain the same or be rotated. If rotation is allowed, then a message may be allowed to travel through a different path, whereas if the SLS field is not rotated (bit rotation), the messages may be received out of sequence.



		Protocol class 2 provides a basic connection-oriented service. A connection must first be established between the two entities and, once established, a two-way dialog may take place. In the case of SS7, the same physical link may be used to carry multiple connections at the same time. This is the same concept as multiplexing several telephone conversations onto one physical facility.



		To maintain an order between the various "connections," a reference number is established at both ends as an index to each of the particular connections. This allows either end to determine which virtual connection a message is destined to, much in the same way that X.25 uses virtual channels for a connection.



		Protocol class 3 provides the same services as class 2, but adds the function of flow control and expedited data. Message loss and missequencing can also be detected and reported to the opposite end of the connection by way of an SCCP management (SCMG) message. When such an event occurs, class 3 has the capacity to reset the connection and restart transmission of the upper level messages again.



		Protocol class 4 adds error recovery to the class 3 functions. This has presently been removed from Telcordia standards, but is still defined in the ANSI standards. Error recovery supports retransmission of errored messages.



		All of these protocol classes involve services of SCCP. Primitives are used to convey information between the levels, whether between the user part and SCCP, or between SCCP and MTP.



		Figure 7.1 illustrates the various functions provided by SCCP. Through the use of primitives, all user parts that use the services of SCCP must discern whether they need connection-oriented or connectionless services. A separate interface is maintained for either one of these services.



		The various routing functions of SCCP are handled by the SCCP routing control (SCRC) function, which interfaces directly with MTP. This includes any global title translation if the signaling point is equipped with that function. Remember that not all signaling points are equipped with global title translation.



		The signaling point may also provide the reverse option of global title, which is translating the calling party address from point code and subsystem number into nothing but global title. This is especially useful for secure networks, where a message is being routed outside of the network and only the global title needs to be given to prevent outside networks from learning the point codes of internal signaling points. This is a function which would be provided by a gateway Signal Transfer Point (STP).



		MTP sends all received messages to the SCCP routing control for discrimination and distribution. If you remember our discussion from Chapter 6, you will remember that MTP also has a message discrimination function as well as a distribution function. The SCRC function is much like MTP in that it also must discriminate messages at the SCCP level and distribute to a higher level if addressed to the local application.



		The called party address field provides the addressing information necessary for the SCRC to route a particular message to the correct destination. The SCRC is not concerned about which signaling point to route the message to, because this is the function of MTP. The SCCP level is concerned only about its users, which are at the application level. Therefore, the destination point code is not used by the SCRC function. It exists simply for the sake of the MTP. The subsystem number is the only information (besides the global title, which is passed to the subsystem) that is needed at this point for routing by the SCRC.



		Figure 7.1 This figure illustrates the four functions defined in SCCP and the primitives used to interface to other protocols in SS7.



		The message distribution function routes the message to the correct user part, as defined in the called address field. Later, we will define the values of the various subsystems which have been defined by both Telcordia and ANSI and identify which applications they represent. Routing is discussed further in the next section.

	The SCCP connection-oriented control (SCOC) and the SCCP connectionless control (SCLC) are both used to control functions such as segmentation and sequencing of messages. The user part must determine which service is required for the particular transmission. At the present time, only the SCLC function is used.



		SCCP management (SCMG) is notified any time a message cannot be delivered to a user part. In the case of the connectionless service, the received message is actually returned to the originator using the Unitdata Service (UDTS) or Extended Unitdata Service (XUDTS) message structure. In either one of these formats, the payload is also returned to the originator.



		In the case of connection-oriented service, the connection request is denied and SCMG is notified. There is no return of the data sent. SCMG may reset the connection, if one has been established, or simply return a connection reject message if no connection previously existed.



		Routing Services of SCCP



		As mentioned earlier, the SCCP provides end-to-end routing functions to the TCAP. The TCAP protocol, in turn, provides transport services to the application entity with which it interfaces [such as the Mobile Application Part (MAP)].



		The addressing requirements are somewhat different for TCAP than what the MTP is able to provide. MTP bases its addressing (the point code in the routing label) on information from SCCP. This information is found in a called/calling party address field in the SCCP message.



		The called/calling party fields provide three forms of addresses. The first consists of digits. These digits, referred to as global title, are usually what the subscriber (calling party) dialed in the case of an 800 number call. However, they do not have to be digits dialed. They can also be the mobile identification number (MIN) used in the cellular network to identify a cellular subscriber. At any rate, whatever the address is (dialed digits or some other form of digits), SCCP provides this information to MTP in the form of a primitive. This allows MTP level three to determine which signaling point to route the SCCP message to. If the destination point code is part of the SCCP called party address, this information is given to the MTP of routing.



		If this is the only information found in the called party address, then nothing else is included in the primitive to MTP. However, if the called party address includes global title and subsystem number, then this information is given to MTP for transmission only.

MTP simply includes this information as part of the SCCP header and sends it to the destination. If MTP does not get this information, then these fields are filled with zeros.



		Typically, when routing an ISUP message, level-three MTP knows what the end destination will be for a particular circuit. But remember that MTP needs to know only about signaling points that have a direct trunk connection to their location. This is because of the nature of the signaling taking place with ISDN User Part (ISUP) services. The whole basis for this protocol is to establish a physical connection between the originating signaling point and an adjacent signaling point for a circuit connection (telephone call).



		In TCAP transactions, the intent is different. We are no longer interested in circuit-related transactions. The purpose of TCAP is to provide a means for information exchange between two network entities, whether they are a database or another switch. This requires different routing procedures.



		*Global Title Translation*



		Most end-office switches will not know the actual address of all of the databases in the network, especially if the database is located in another company's network (the exception is when the network is very small and there are only a few point codes). Large networks need to consolidate resources and maintain smaller routing tables. This means that the MTP must be able to route based on global title digits (such as an 800 number).



		The MTP will route the message to a Signal Transfer Point (STP), which is capable of providing a more detailed address, point code, and subsystem number for the actual database that will provide the 800 number routing information. This application is referred to as global title translation.



		Not every STP in the network needs to have this capability. In fact, global title translation is usually a function which is centralized within the network. The global title digits are given to the SCCP function of global title translation, so that SCCP routing can determine the point code and subsystem number the message needs to be routed to for the information. This feature applies to both 800/900 -type numbers as well as to cellular mobile identification numbers. The ability to provide this type of routing at the SCCP level allows MTP routing tables within individual signaling points to remain condensed, without the need to know every point code in the network.



		When using the global title translation feature, messages from a Service Switching Point (SSP) which is always the originator of such messages are routed to a STP, which must then translate the SCCP address fields into the point code/subsystem number combination. The message is then given back to the MTP with the additional address information so that it may be routed by MTP level three to its final destination.



		This method of routing also allows networks to accept messages from other networks, without disclosing their own internal point codes. For example, a company providing a database feature to other carriers may provide the point code of a gateway STP. The purpose of the gateway STP is to control who has access to the network (using a security feature called gateway screening) and also to provide global title translation.



		The carriers route SCCP messages to the database service using only global title digits. It is then up to the database service to determine which of their databases will receive the messages by performing global title translation on the global title digits and routing the message through their own network using the point code/subsystem number combination. This method is currently being used in Canada and some other countries with centralized databases, and will likely be used in the United States for cellular databases.



		I should mention here, by the way, that the point code in the called party address field is that of the Service Control Point (SCP), which is providing an interface to the actual database. While it is possible to have a database resident within an SCP, these devices are usually front-end database servers used to route SCCP messages to actual database systems located on an X.25 network or TCP/IP network.



		The subsystem number is actually the address of the database itself and is necessary for getting the TCAP message to the database. Each SCP may interface to a number of databases, each with its own subsystem number.



		We can now see the fundamental differences between SCCP routing and MTP routing. SCCP is providing a more flexible routing scheme and actually provides three addresses: the global title, the point code, and the subsystem number. MTP routes to the point code of a signaling point, which has a direct voice facility connection or signaling points within a cluster. It may also address signaling points that provide centralized services, such as global title translation.



		Flow Control



		Another fundamental difference between the MTP and the SCCP is flow control. The MTP network management procedures of level three provide flow control to a signaling point. In the event that a signaling point experiences a failure at the link level or the processor level, level-three management provides the procedures for routing around the failure.



		The SCCP also provides flow control, but at a different level. As previously mentioned, SCCP interfaces to the TCAP and ISUP protocols, which, in turn, provide services to an application entity.



		The flow control in the SCCP management (SCMG) procedures provides management of message flow to a user part rather than a signaling point. In the event that a particular user part (today it is only TCAP) becomes congested, the SCMG function throttles the traffic destined to that user part. This has no effect on the traffic destined to the signaling point, unless configuration of the signaling point warrants rerouting.



		There are procedures that allow for a database function or application entity function to be duplicated or replicated at another mated signaling point. If this is the case, then through configuration of the signaling point, the messages destined for a congested user part may be redirected to another signaling point.



		This is not necessarily a feature of the protocol, other than as an indication as to how the message should be handled (the indication is through the multiplicity indicator, located in the SCMG messages).



		The multiplicity indicator indicates whether there are duplicated subsystems or not. There are no handling procedures other than the indicator. If the indicator says that the subsystem is solitary, then messages to a congested user part can be returned to the sender by SCCP management. If the subsystem is duplicated, then the signaling point configuration can determine the method to be used for handling messages. They may be rerouted to the duplicate subsystem, or they may be returned. This, of course, depends on the implementation at the signaling point.



		In RBOC networks, messages routed to a congested or failed user part must be rerouted to the duplicate subsystem, only if the duplicate subsystem is available and not under congestion itself. Otherwise, the message is discarded and a Unitdata Service (UDTS) or Extended Unitdata Service (XUDTS) message with a return cause is sent to the message originator.



		This is also supported in the ANSI standards, but has not made its way into the standards publications as of the date of this publication. There is mention of the requirements, however, in Telcordia STP Generic Requirements TA-NWT-000082, Issue 5, May 1992 Revision 1, July 1992. This document cites the need for rerouting SCCP messages per the ANSI T1S1.3 standards group, but indicates that the requirement has not yet been added to the other standards publications and has, therefore, been included in the STP generic requirements publication.



		*Flow Control Procedures*



		Flow control is provided only in connection-oriented procedures. The purpose is to manage the number of data units sent on a particular connection. The unique thing about SCCP connection-oriented services is the ability to use one transaction to manage several connection sections.



		The credit parameter in the connection request and connection confirm is used to establish the window size for a connection section. There may be multiple connection sections within one signaling point at any given time. The connection section is the equivalent of a virtual connection within an entity.



		During the connection phase, the connection request message sends a credit parameter with the requested window size. This is based on the number of the messages that need to be sent. The credit may be negotiated between the two entities.



		When the connection confirmation is returned, the credit parameter indicates the window size that was granted, based on the available resources of the destination signaling point. The actual credit granted may be larger or smaller than what was originally requested.



		The sequence numbering then determines when additional messages may be sent. If the window size has already been met, then no other messages may be sent until messages sent can be acknowledged and processed. Once they have been removed from the receiving signaling points buffer, additional messages may be sent.



		The sequence numbers in the SCCP messages are used to notify both entities when messages have been acknowledged. This works the same way as message sequence numbering at the MTP level.



		Another unique point about flow control compared to MTP is the fact that flow control at SCCP is used to control the flow of messages to a user part and not a signaling point. MTP flow control controls the traffic destined to a signaling point, whereas SCCP controls traffic to an application.



		If the resources available to a particular user part (which serves as the communications interface to applications) become congested, then SCCP flow control is used to throttle the messages to the affected subsystem.



		Connection-oriented Services



		The SCCP supports connection-oriented services for the Transaction Capabilities Application Part (TCAP) and the ISDN User Part (ISUP). However, none of these uses connection-oriented services in networks today. It is important to remember that the protocol defines the procedures and functionality for a great many services, but only a fraction are actually implemented to date. For the sake of this book, we consider the possibility of all of these procedures and functions being used at some point in time.



		This is a particularly interesting development, since the mechanisms used in the connectionless service emulate a connection-oriented protocol. Part of the reason for using connectionless versus connection-oriented services lies in the resources required to support hundreds of connections at any given time.



		Because of the nature of the SS7 network, to establish a virtual connection with an application entity for every transaction that takes place in the network and maintain that connection through the entirety of the transaction would require far too many resources. If the same information could be sent to the application without having to establish a connection, then the results would be the same, but with fewer resources.



		Nevertheless, connection-oriented services are defined and described here because there may come a time when these services will be needed. Besides, no discussion could be complete without discussing all the capabilities of this network, instead of what is implemented.



		Connection-oriented services provide for two types of connections: permanent and temporary. Permanent connections are established for operations, maintenance, and administration functions. These connections must be maintained permanently so that continuous real-time information can be exchanged between the network entities and the operations centers. In today's networks, this is not used, since connection-oriented services are not supported.



		Temporary connections are used for all other services and, as the name implies, are established on a temporary or as-needed basis. These must be established when data transfer is requested and released when data transfer is complete. This works just like a telephone call in the Public Switched Telephone Network (PSTN).



		For example, in the case of remote control of another telephone switch, there may be a need to establish a temporary connection before transmitting the actual data. This requires the services of connection-oriented SCCP, which will send a connection request to the distant end and establish a connection with the resources required at the remote switch. Once the connection has been established, the actual data, or control information, is sent over the established connection (which is actually a virtual connection, or session, if you think in mainframe terms).

When the transaction is complete and there is no other control information to be sent, the connection can be released. This means that whatever resources that were required for the transaction are now made available for other entities. Temporary connections, if used today, would be the most commonly used connection.



		As mentioned already, connection-oriented services are not presently supported in ANSI networks, nor in any of the ITU networks known by this author. This may change in light of the many new Advanced Intelligent Network (AIN) features being deployed throughout the world. To date, there have not been any features defined that require connection-oriented services.



		Even though connection-oriented services are not supported, the connectionless services do emulate many of the features of a connection-oriented protocol. Index numbers are used throughout the message in the TCAP portion to provide references back to previous transmissions, much in the way that virtual circuits are used in X.25. These index numbers are of no significance to the SCCP protocol. It is important to understand how these work and how TCAP works in general, so that one may understand the services of the SCCP. You may want to read Chapter 8, on TCAP, first or review this chapter after reading about TCAP.



		Connection-oriented services consist of several phases, which represent the various activities that take place during transmission of data between two entities. Some of these phases are represented during connectionless services as well.



		The main disadvantage of connection-oriented services is the number of resources required for a connection-oriented transaction. For example, for two entities to exchange data regarding a mobile telephone subscriber (such as location data), a connection would be established first, virtually dedicating resources on both ends for the transaction. The data could then be transferred and the resources released.



		The problem comes when there are many of these transactions occurring throughout the network. In cellular networks, a mobile subscriber's phone may send a location update message every three to five minutes. You can imagine the number of such messages which must travel through a cellular network supporting 10,000 to 15,000 subscribers! This is one of the reasons connectionless is so widely used in SS7 networks today. Nevertheless, let's look at the procedures of the connection-oriented protocol and discuss the functions.



		*Connection-oriented Procedures*



		As mentioned earlier, there are several phases that take place during connection-oriented transmission. The first phase is the connection establishment phase. This phase is when the resources of both entities, the receiver and the originator, are dedicated to the transaction.



		This is then followed by the data transfer phase, which is when the data is actually being exchanged between the two entities. During this phase, no other entities are allowed to send anything to the resource that has been assigned to this transaction. Notice we said ''resource." Switches and computers have multiple processors and have the capability of handling many transactions at once. This is due to the usage of distributed processing.



		Following the data transfer phase is the release phase. This consists of a volley of messages exchanged between the two entities, releasing the resources which were dedicated for the particular transaction.



		To better understand the various phases and the exchange of messages that takes place, let's look a little closer at each of the three phases.



		Connection Establishment



		To understand the events that take place, we must first understand the routing of SCCP messages. A discussion of SCCP routing can be found in previous sections; here we need to talk about the differences between routing in connection-oriented and connectionless procedures.



		In connection-oriented messages, the addressing is somewhat different than that of connectionless. The address information for all SCCP messages is located in two fields: the called party address and the calling party address.



		In connectionless services, the called and calling party addresses represent the originating and destination point codes for the message. However, in connection-oriented services, each node involved in the connection establishes a connection between itself and the next intermediate node.



		A good example of how this works is the voice network. A central office usually does not have a direct trunk connection to the final destination of the call, unless it is a local call. To reach the final destination, it must route through any number of intermediate switches.



		During the call setup, a message is sent from the originator to the next intermediate node involved with the connection. The connection is then established between these two entities. Any messages regarding that connection are directed to the intermediate node and not to the final destination.



		The intermediate node is then responsible for establishing a connection between itself and another intermediate node or the final destination if possible. This requires messages that are originated from the intermediate node to the next node in the connection. This same scheme is used for SCCP routing when connection-oriented services are to be used.



		However, with connectionless services, the message can be addressed directly to the destination and, regardless of the number of intermediate nodes in the path, the message is routed according to the final address. No connection is established and the message addressing consists of the message originator and the final destination of the message.



		In connection-oriented services, each node will have to establish two connections. The first connection is for the incoming message. The second connection is for the outgoing message. Both of these connections must be correlated to one another. This is referred to as a connection-section in the protocol. The entity that establishes the connections must be responsible for maintaining an association between the incoming and the outgoing ports used for this connection.



		Other messages can be received over these facilities, addressed to other entities. This makes this connection-section a logical, or virtual, connection, rather than a physical connection.



		To establish a connection between two entities, the originator must send a connection request (CR) message. This is sent to the first intermediate node, or the final destination if there is a direct connection available (the destination is an adjacent node to the originator). The CR contains the information necessary to define the parameters of the connection. This includes the Quality of Service (QoS) which is defined by the protocol class and the addresses.



		The data parameter may contain bearer information to be exchanged with the application with which a connection must be established. A maximum of 130 octets may be sent in the data field.



		To ensure minimal delay caused by routing through an excessive number of intermediate nodes, a hop counter is maintained. This hop counter is configured per network and decrements as it passes through each node. When the counter reaches zero, the message is in error, the connection is aborted, and an error message is returned with a cause code to the originator.



		When the connection request is received by the destination, a connection confirmed (CC) message is returned. The CC is an acknowledgment that the resources necessary to maintain such a connection are available and are now reserved for the transaction. In the event that the resources are not available, then a connection refusal (CREF) message is returned, along with a refusal cause code.



		When a connection has been established, a local reference number is assigned to that connection (see Figure 7.2). This works much the same way as a virtual channel in the X.25 protocol. Other messages may be received over the physical link, even though this link has been established for a connection, but any messages bearing the same address and reference numbers previously established will be handled in the same way as if the link was a permanent physical connection. You may think of this as a switched virtual circuit, which will be released upon termination of the transaction.



		Figure 7.2 This figure illustrates an SCCP message being sent to an SCP with a local reference value of 1. The local reference number is only of significance to A, which uses this number much in the same way as logical channels are used in X.25. Any responses to this SCCP message will carry the same local reference number.



		The reference number is assigned to both the incoming connection and the outgoing connection, but both independent of one another. They are referred to as the source local reference number (incoming) and the destination local reference number (outgoing).



		All messages that come in to the signaling point on a connection are then given the source local reference number of that signaling point. When a message is returned to that entity, it may provide the reference number so that the signaling point then knows to which connection the message is relevant.



		Reference numbers are of local significance only. In other words, if the reference number of a connection at the originating signaling point were sent to the destination signaling point, the destination would not know what the number was, because it was created and corresponds to a connection back at the originating signaling point.



		The local reference number is used by the remote node as an address. It becomes the destination reference number for all subsequent messages. This address is not found in the connection establishment phase, because it has not yet been created. During the data transfer phase, all data transfer messages will contain a destination local reference number, which is assigned by the remote entity.



		When a connection has been released, the reference number assigned to the connections section related to that connection is "frozen." This means that the number may not be reassigned for a certain time. A timer is set to determine when the reference number may be "unfrozen," and available for reassignment to a new connection. This procedure is necessary to prevent an incoming message associated with a previous connection section from being routed to an incorrect reference number.



		Also a part of the connection establishment phase is the negotiation for the QoS. The receiver may choose a different QoS based on present conditions within that node and the resources available. The QoS is directly related to the protocol class parameter.



		If we review for a moment the valid protocol classes, this means that an originator may propose protocol class 3, which calls for connection-oriented services with sequenced delivery and flow control. The receiver may instead assign protocol class 2, which provides the sequenced delivery without flow control. The connection confirm (CC) message is used to indicate which protocol class will be used.



		If flow control is provided, the window size of the receiver may also be negotiated. This is accomplished using the credit field in the connection request (CR) message and the CC message.



		When the CR is sent, the credit field is sent with the proposed window size for the connection. The receiver may then assign a different (lower) window size if it wishes. This is sent using the connection confirm message credit parameter. The credit parameter is also related to the QoS of a message. This is assigned to a connection throughout the lifetime of the connection.



		Data Transfer Phase



		When a message containing data is sent over the established connection, the called party address is used by the SCCP routing control function to determine which connection section to route the message over. All subsequent data messages with this called party address will be routed over the same connection section.



		In the event that there is an incoming and outgoing connection section (represented by the source local reference number and the destination local reference number), then the SCCP routing control must determine which of the outgoing ports is associated with the source local reference number and routes the message to that destination.



		The message, when received by the final destination, is given by the MTP to the SCCP routing control to determine the address of the message. If it is determined that the address is of the signaling point which has received it, then the data is given to the user part (TCAP or ISUP) via a primitive. Remember that primitives are used whenever a lower level function is passing information up to a higher level function. The primitive is the interface through software that communicates with the other signaling point entities.



		Sequence numbering is provided (if the protocol class warrants) by using the sequence number parameters in the data form 1 (DT1) and the data form 2 (DT2) messages. The sequence numbers act as an acknowledgment for previously received messages as well. This works much the same way as in other protocols and as sequencing works at the MTP level.



		The originator of data may send up to 127 data messages through a connections section in one direction. Another 127 messages may be sent through the same connection section in the opposite direction. At any time, the receiver may change the size of the window, depending on resources and other parameters, by changing the value of the credit parameter. The credit parameter indicates the number of messages that may be sent in any one direction.



		For example, if the credit parameter has a value of 7, only seven messages may be sent in one direction (towards the sender of the credit parameter of 7). When the receiver of this credit has sent seven messages, it must wait until it receives a message acknowledging receipt of the previously sent seven messages. It may then continue transmission.



		If the credit size has been changed, then the sender is limited to the number of messages it may send or, if the number has been increased, the sender may be able to send more messages. This dynamic window size allows the protocol to control the number of messages sent to an entity according to real-time events, rather than using a fixed parameter that is not sensitive to events that may take place during transmission (such as congestion).



		Data acknowledgment messages may be sent even when there is no data to be transmitted. This allows for the acknowledgment of received messages and allows transmission to continue, even when transmission is only in one direction.



		Some messages may exceed the capacity of the SCCP envelope. When this occurs, the data must be segmented into multiple packets before transmission. Keep in mind that the level above SCCP (the user part) includes header information. This header information is not included in every single data segment. Rather, the data and the header information are sent in their entirety to SCCP routing and, when segmented, the first set of bits is encapsulated and transmitted.



		The remaining bits are then encapsulated and transmitted, with no knowledge of header information. The header information of the user part will then be received along with some of the data in the first segment. The header information will be in its entirety.

The remaining data will be received in subsequent SCCP messages. Segmentation is not necessary if the message is equal to or less than 255 octets.



		To ensure that data has been received, an expedited data message may be sent instead. The expedited data message allows up to 32 octets of user data to be sent to the destination. No further data may be sent, however, until an acknowledgment has been received. Once an acknowledgment has been received, then additional expedited data messages may be sent.



		This is only true on one connection section. Multiple expedited data messages may be sent to a node (signaling point) on different connection sections, but only one at a time may be sent on any one connection section. This ensures that the transmitted data is indeed received without error. Flow control can be accomplished by with-holding the expedited data message acknowledgment. Expedited data only applies to protocol classes 3 and 4.



		In the event that two entities are no longer in sync with each other, a reset can be initiated. The reset changes the sequence numbering back to zero at both ends of the connection, and changes the window size back to the initial window size from when the connection was originally established. The credit field is also reset back to zero.



		When a reset message is received, the receiver also resets its sequence numbers back to zero. Any data messages received after the reset request are discarded. A confirmation must be sent to confirm that the reset has been initiated before data can begin transmitting again. Once the confirmation has been sent, the originator of the reset begins sending data using sequence numbers beginning with 1.



		Release Phase



		Once data transmission has been completed, and there are no further transmissions necessary, a release may be initiated. The release may be initiated by either node at any time during the life of the connection. However, there are measures which are taken at the user part to ensure that a connection is not prematurely released before an entity has completed its transactions.



		The TCAP uses a permission parameter, which is inherent within specific message types, indicating whether or not an entity has permission to disconnect a connection or not. Permission is not granted when there is additional data to be sent in association with a particular transaction.



		As previously mentioned, the release may be initiated by either node, and by the user part or SCCP. When SCCP requests a release, it usually indicates a problem with the connection. SCCP may request a release or a pause on the connection, or it may also request a release without permission to reestablish the connection.

The release cause parameter indicates the reason for the release and will also implicate the originator of the release. A release must be acknowledged by a release complete before the connection is considered available for another transmission.



		Connectionless Services



		Connectionless transfer of data using the services of SCCP requires the use of the unitdata and the extended unitdata message structures. These message structures provide all the information necessary for data to be transferred to a remote entity and to be processed by that remote entity.



		There are two protocol classes that support connectionless services: protocol class 0 and protocol class 1. When protocol class 0 is used, there is no guarantee that the subsequent data will arrive in the same order in which it was transmitted. That is because the signaling link selection field in the routing label of the MTP header may be rotated at each node. When this occurs, a message may travel a different route than its associated messages.



		Due to cross-delay, messages are received out of sequence when this occurs. To prevent this from happening, protocol class 1 can be specified. Any message with a protocol class of 1 indicates that the signaling link selection field should not be rotated, and any other messages received for the same destination are transmitted over the same SLS as the previous associated messages. This ensures that messages that are associated with one another follow the same path and do not get delivered out of sequence.



		There is really only one phase during connectionless procedures: data transfer. There is no connection establishment, because a connection is not necessary. Data is encapsulated into a message envelope with all of the information necessary for the receiving entity to process the information as it was received.



		Subsequent data may be sent in the same fashion, as long as there is enough information for the receiving entity to process the data. Obviously, connectionless services do not require the same resources as connection-oriented services and, thus, have found more favor in SS7 networks today. Let's look a little closer at the procedures used to transfer data with a connectionless protocol.



		*Connectionless Procedures*



		The application service element wishing to send data to a remote entity requests connectionless services from SCCP. The application service element can be TCAP or some other transport mechanism used by an application entity. The application entity could be the Operations, Maintenance, and Administration Part (OMAP) or the Mobile Application Part (MAP).



		The method used to transport data between two entities is transparent to the application entity and is the responsibility of the application service element, such as TCAP. All routing is handled by the SCCP routing control (SCRC), which provides routing parameters to the MTP.



		In large networks, it is not feasible for every node to know the address of every other node. For this reason, the SCCP routing control function can provide additional translation services. This is known as global title translation and is explained in detail in the preceding section on SCCP routing.



		When there is too much data to fit into one SCCP envelope, or when it is determined that the message should be segmented (this can be determined by network management based on network conditions), the extended unitdata (XUDT) is used. The data is then divided into equal-length segments. The rule is that the first segment should be sized in such a way that the total message length is less than or equal to the size of the first segment multiplied by the number of segments being sent. This is to prevent buffers from becoming unmanageable.



		All subsequent messages are configured with the same address information, and protocol class 1 is selected to ensure in-sequence delivery of all messages. The segmentation parameter in the XUDT message is set to indicate that there are additional segments to be sent, and the segment number field indicates how many additional segments are yet to be transmitted.



		In the event that a message is received in error, an error message is returned to the originator of the message. The error message is in the form of the unitdata service or extended unitdata service messages. The data is also returned, along with a return cause code, which indicates why the message is being returned.



		Unlike connection-oriented services, connectionless services do not assign any logical reference numbers to transmissions, because there is no connection to be established. Therefore, tracking is not important. The only objective is to get the data to its destination. At the user part level, there are many schemes used to ensure that messages are received without error and, at least in the case of TCAP, indexing schemes to keep track of associated data.



		SCCP Management (SCMG)



		SCCP management (SCMG) is used to maintain the integrity of SCCP services. While the MTP maintains link integrity and alerts adjacent signaling points of congestion at another signaling point, SCMG is concerned about the status of a subsystem or application entity.



		To accomplish this, SCMG is divided into three tasks: signaling point status, subsystem status, and traffic management. Management messages use the unitdata message structure found in connectionless SCCP.



		To maintain the status of the signaling point, SCMG relies on information from the MTP, which is sent to SCMG through primitives. These primitives consist of the MTP-Pause, MTP-Resume, and MTP-Status primitives and their parameters. Subsystem information is gathered by SCMG through primitives from the subsystem directly to SCMG.



		Probably the most advantageous feature of SCMG is the ability to route messages away from a failed or congested subsystem to a mated subsystem in another location. This ensures that services are not lost when a subsystem fails, and guards against failures due to subsystem congestion.



		This requires that subsystems be "replicated," or duplicated and placed in different geographical locations. When this has been adhered to, the diversity of the network increases, and the reliability increases. The protocol can now control message flow to the replicated databases.



		There are several roles which a database can play within the protocol structure. One is as the dominant subsystem. The dominant subsystem will hold a higher priority than its replicated subsystems. All replicated subsystems possess the same subsystem number, so it is up to the signaling points to determine how to route to the subsystems. This is decided at configuration time, and each signaling point is configured to handle SCCP traffic according to these rules.



		Each replicated subsystem may have a priority, with the subsystem with the highest priority receiving the bulk of the traffic. The assignment of the dominant subsystem may change dynamically or may be a fixed configuration, depending on the network. One thought is to allow the priority to change based on current load. This provides for a more dynamic routing scheme, but could prove difficult to implement.



		A solitary subsystem is one that is not replicated and must, therefore, handle all traffic. In the event that this subsystem fails, traffic may be routed to another network or stopped altogether. This is the least favorable in any network, because it increases the single point of failure and decreases reliability in the network.



		Another scheme is to have a primary subsystem that receives all traffic until a failure occurs, in which case, all traffic is routed to an alternate. The alternate would then handle all SCCP traffic until a failure occurred, in which case it would be marked as inaccessible and all traffic would be routed back to the other alternate.



		This uses a standard master/slave relationship, but it is not favorable, because there is no use of the other subsystem until a failure occurs. This means that the other subsystem is sitting idle and not being utilized in any capacity. If there is something wrong with this subsystem (in terms of being able to handle messages), you will not likely find out until it goes online and begins handling messages, which is a little too late.



		SCMG also uses a concept referred to as the "concerned" point code. There are really two point codes that are affected by SCCP management. One is the affected point code, which is the failed or congested entity. The other is the point code that utilizes the service of the affected point code. The concerned point code must be notified when there is a status change at the affected point code, so that it knows how to route SCCP messages. The concerned point code is updated about an affected point code's status using SCMG messages and connectionless services of SCCP.



		SCMG messages are sent to "adjacent" signaling points (adjacent in the logical sense only) to alter the translation functions located within those signaling points. By altering the translation function, when a protocol class 0 message is received, messages can be routed to other replicated subsystems. The action to be taken depends on the type of SCMG intervention.



		*Signaling Point Status Management*



		Signaling point status management is concerned with the status of a Service Control Point (SCP). If the SCP becomes congested or should fail, then the subsystems adjacent to the SCP cannot be reached. Traffic must then be diverted to replicated subsystems.



		This requires a series of management messages that provide the status of a signaling point (SCP) and subsystem combination. These messages are not to be confused with the messages used by network management at level three, although there are some similarities. Level three is more concerned with all signaling points within the network, rather than just a select type.



		A signaling point prohibited procedure indicates that the affected signaling point has been prohibited and cannot receive any traffic. The signaling point will be a SCP, rather than a SSP or STP, because this is the only entity SCMG is really concerned about.



		When a prohibited message has been received, the receiving node changes its translations to route traffic to the replicated subsystems, if any exist, according to the configuration of the replicated subsystems (dominant role, alternate role, or solitary).



		When the signaling point (SCP) is considered as ''allowed," the translation tables are once again modified according to the roles of the replicated subsystems. Traffic is then allowed to be directed towards the affected signaling point, and subsystem status tests may be invoked.



		All translation changes are made at "adjacent" nodes. Adjacency refers to a logical adjacency. This means that a path exists from one signaling point to the affected signaling point. An example would be a STP that provides global title translation. This entity needs to be kept apprised of signaling point status, because it will have to change its routing tables and translation tables based on the status of the SCPs and their subsystems.



		*Subsystem Status Management*



		The purpose of subsystem status management is to monitor the status of individual subsystems within a signaling point. A SCP may have multiple subsystems. If the signaling point becomes congested, or fails, then none of those subsystems can be reached (signaling point status management). If only one of the subsystems becomes congested or fails, then subsystem status management redirects traffic from that one subsystem to other replicated subsystems.



		This should point out the fundamental difference between signaling point status management and subsystem status management. One is concerned with the status of the SCP while the other is concerned with the status of the subsystems located within or adjacent to the SCP.



		Translation tables must also be changed to allow routing to be diverted away from the failed or congested subsystem and routed to replicated subsystems, depending on their roles in the network (solitary, dominant, or alternate).



		The same status is provided for subsystems as for signaling points. A subsystem is either prohibited or allowed. There is no restricted mode as used by level-three management. If a subsystem is unable to handle traffic due to congestion or failure, then traffic is immediately diverted to replicated systems. Throttling of traffic cannot be tolerated, due to the nature of the transactions taking place at a subsystem.



		When a subsystem is marked as prohibited, a status test is used to audit the prohibited subsystem and ensure the status is correct. The test is invoked by the SCP so that it may keep track of the status of all of its subsystems. If, for any reason, the subsystem status has changed to allowed and the subsequent management messages were not received, a subsystem could remain prohibited in the status tables of the adjacent SCP, while the actual status of the subsystem is allowed.



		In addition to testing the status of a subsystem, a SCP may also invoke a broadcast which allows the SCP to inform other local subsystems (concerned subsystems) of the status of other signaling points or subsystems. This is reserved for local subsystems, which means they have a direct adjacency to the SCP and can be communicated to through the use of primitives, rather than protocol messages.



		Other signaling points can be notified through the use of a broadcast procedure for signaling points. This procedure is used to inform concerned signaling points of status changes concerning subsystems. Only concerned signaling points are sent status updates. A concerned signaling point is that which regularly routes messages to the SCP/subsystem combination. Usually, this is a STP, which provides the global title translation function for the rest of the network.



		Now you can see one of the distinct advantages behind using a centralized STP with global title translation, rather than spreading the routing function through all of the nodes. SCMG, as well as routing, can be simplified if only a few of these entities provide this functionality.



		There is also a procedure which allows for the calculation of traffic mixes, although much of this is still under study. Traffic mix information can be provided as an option in ANSI networks and can prove useful to some databases for the purpose of network management and network monitoring.



		The traffic mix indication informs end databases as to the type of SCCP traffic being routed: normal SCCP traffic or "backup." Normal SCCP traffic is that which would normally have been routed to the subsystem without network management intervention. Backup traffic is all messages routed to the subsystem as the result of an SCCP management function. This indicates that the receiving subsystem is a replicate subsystem and is receiving traffic from another subsystem that is prohibited.



		As mentioned earlier, a subsystem is either prohibited or allowed. There are no procedures currently defined for flow control to a subsystem. Because of the nature of the transactions that take place at a subsystem, flow control may not be a viable option.



		SCCP Message Structure



		The SCCP is divided into several sections, as we saw earlier. In this section, we will define the various fields and values for these fields, and identify where they can be found in the SCCP message. These fields are defined according to their location in the SCCP message. There are three parts to the message: the mandatory fixed part, mandatory variable part, and optional part (see Figure 7.3).



		Figure 7.3 This figure identifies all of the fields in an SCCP message and its location in relation to the rest of the protocol.



		The mandatory fixed part consists of those parameters that are mandatory for the particular message. Each message will have different parameters which will be fixed in length (according to the message type). The message type may have one octet or may have several octets of parameters. The field will not vary, however, and, because of the message type, it can be determined how large these parameters will be.



		The mandatory variable part consists of those parameters that are required of a particular message type, but are not of a fixed length. A good example of a mandatory variable part is a called or calling party address. This field uses length indicators to identify the length of each individual parameter field and the beginning of the parameter. Also in the mandatory variable part is a pointer that identifies the beginning of the optional part. This field consists of the binary representation of the binary offset. An offset is the octet count from the beginning of the pointer to the optional part indicator.

Each of the parameters found in the mandatory variable part is preceded by a length indicator and the parameter indicator. A pointer at the beginning of the mandatory variable part points to the octet of each of the individual parameters.



		The optional part also uses length indicators after every parameter. The parameter is identified by a one-octet indicator, which provides a unique pattern for every parameter type.



		Following the optional parameter is the length indicator, which provides the length for the entire parameter, excluding the parameter indicator. The length indicator is then followed by the parameter itself.



		Not all SCCP messages will use all of these fields. Some SCCP messages will only use the mandatory fixed part; others will only use the mandatory fixed and variable parts. Following are the definitions for the various parameters found in the SCCP message structure.



		*Mandatory Fixed Part*



		The mandatory fixed part succeeds the message type code, which identifies what type of SCCP message is being sent. As discussed in the introduction, there are two types of services provided by the SCCP: connection-oriented and connectionless. The connection-oriented classes of service require several different types of SCCP messages, while the connectionless requires only one. In the U.S., connection-oriented classes of service are not supported. We will define them here anyway, since there may come a use for these services in the future.



		Even though there are no present uses for connection-oriented services using SCCP, there are many functions of SCCP that emulate connection-oriented services. We will look at the various parameters that are used for connection-oriented emulation when we examine the mandatory variable fields and the optional parameters.



		*Mandatory Variable Part*



		The parameters found in this field will depend on the type of message being sent. Each message has different requirements and may or may not require variable parameters. Not all SCCP messages will use the mandatory variable part.



		The "mandatory" indicates that this field may be required for specific message types. The "variable" indicates that the length of these parameters is not fixed in nature and will be variable. This includes addresses and other parameters, which will vary from message to message.



		*Optional Part*



		The optional part is always a variable-length field, and may or may not be used with specific message types. "Optional" indicates that the field is not required for a specific parameter, but may be used to provide additional information relating to a transaction.



		Length indicators are used before every parameter in this field to delineate between the various parameters. By providing these length indicators, the receiving signaling point can determine where the beginning and the end of a parameter is without the use of pointers.



		Message Types



		The first field of the mandatory fixed part is the message type. This field is found in all SCCP messages. The message type will determine which parameters will be used in the mandatory variable part and the optional part.



		The mandatory fixed part will be followed by varible and optional fields in some situations. This depends on the message type. The various parameters will provide additional information, again depending on the message type (the parameters are not shown in their entirety in this section).



		This section describes the message types that are supported for connection-oriented and connectionless services. These message types and their parameters are shown as follows with explanations for the message types and their functions. The parameters are explained in their entirety in the next section.

End of Optional

Hop Counter

Data

Clg Party

Credit

Cld Party

Proto Class

Src Loc Ref

Msg Type

24 to 3120

32+

24+

Connection Request (CR)

Mandatory Fixed Part

Source Local Reference

Protocol Class

Mandatory Variable Part

Called Party Address

Optional Port

Credit

Calling Party Address

Data

SCCP Hop Counter

End of Optional Parameters

End of Optional

Data

Cld Party

Credit

Proto Class

Src Loc Ref

Dst Loc Ref

Msg Type

24 to 3120

32+

Connection Confirm (CC)

Mandatory Fixed Part

Destination Local Reference

Source Local Reference

Protocol Class

Optional Part

Credit

Called Party Address

Data

End of Optional Parameters

End of Optional

Data

Cld Party

Cause

Dst Loc Ref

Msg Type

24 to 3120

Connection Refused (CREF)

Mandatory Fixed Part

Destination Local Reference

Refusal Cause

Optional Part

Called Party Address

Data

End of Optional Parameters

End of Optional

Data

Cause

Src Loc Ref

Dst Loc Ref

Msg Type

24 to 3120

Released (RLSD)

Mandatory Fixed Part

Destination Local Reference

Source Local Reference

Release Cause

Optional Part

Data

End of Optional Parameters

Src Loc Ref

Dst Loc Ref

Msg Type

Release Complete (RLC)

Mandatory Fixed Part

Destination Local Reference

Source Local Reference

Data

Seg/Reassembly

Dst Loc Ref

Msg Type

16 to 2048

Data Form 1 (DT1)

Mandatory Fixed Part

Destination Local Reference

Sequencing/Reassembling

Mandatory Variable Part

Data

Seq/Segment

Dst Loc Ref

Msg Type

16 to 2048

Data Form 2 (DT2)

Mandatory Fixed Part

Destination Local Reference

Sequencing/Segmenting

Mandatory Variable Part

Data

Credit

Rcv Seq #

Dst Loc Ref

Msg Type

Data Acknowledgment (AK)

Mandatory Fixed Part

Destination Local Reference

Receive Sequence Number

Credit

Data

Clg Party

Cld Party

Proto Class

Msg Type

16 to 2032

Unitdata (UDT)

Mandatory Fixed Part

Protocol Class

Mandatory Variable Part

Called Party Address

Calling Party Address

Data

End of Optional

ISNI

Segment

Data

Clg Party

Cld Party

Hop Cntr

Proto Class

Msg Type

24 to 144

16 to 2032

Extended Unitdata (XUDT)

Fixed Mandatory Part

Protocol Class

SCCP Hop Counter

Mandatory Variable Part

Called Party Address

Calling Party Address

Data

Optional Part

Intermediate Signaling Network Identification (ISNI)

Segmentation

End of Optional Parameters

Data

Clg Party

Cld Party

Return Cause

Msg Type

16 to 2032

Unitdata Service Message (UDTS)

Mandatory Fixed Part

Return Cause

Mandatory Variable Part

Called Party Address

Calling Party Address

Data

End of Optional

ISNI

Segment

Data

Clg Party

Cld Party

Hop Cntr

Rtn Cause

Msg Type

24 to 144

16 to 2032

Extended Unitdata Service Message (XUDTS)

Mandatory Fixed Part

Return Cause

SCCP Hop Counter

Mandatory Variable Part

Called Party Address

Calling Party Address

Data

Mandatory Variable Part

Intermediate Signaling Network Identification (ISNI)

Segmentation

End of Optional Parameters

Data

Dst Loc Ref

Msg Type

16 to 264

Expedited Data Message (ED)

Mandatory Fixed Part

Destination Local Reference

Data

Dst Loc Ref

Msg Type

Expedited Data Acknowledgment Message (EA)

Mandatory Fixed Part

Destination Local Reference

Reset Cause

Src Loc Ref

Dst Loc Ref

Msg Type

Reset Request Message (RSR)

Mandatory Fixed Part

Destination Local Reference

Source Local Reference

Reset Cause

Src Loc Ref

Dst Loc Ref

Msg Type

Reset Confirmation Message (RSC)

Mandatory Fixed Part

Destination Local Reference

Source Local Reference

Err Cause

Dst Loc Ref

Msg Type

Error Message (ERR)

Mandatory Fixed Part

Destination Local Reference

Error Cause

Credit

Seq/Segment

Proto Class

Src Loc Ref

Dst Loc Ref

Msg Type

Inactivity Test Message (IT)

Mandatory Fixed Part

Destination Local Reference

Source Local Reference

Protocol Class

Sequencing/Segmenting

Credit

Data
SCMG Msg

Clg Party SSN=SCMG

Cld Party SSN=SCMG

Proto Class
0/NO RTN

Msg Type
0000 1001