Signaling System No.7 Protocol Architecture And Sevices part 33 pdf

SCCP Management (SCMG) SCMG manages the status of subsystems and SCCP-capable signaling points (SPs). It maintains the status of remote SCCP SPs and that of local subsystems. It interacts with the SCRC to ensure that SCCP traffic is not sent to inaccessible destinations; if they are available, they use alternative routes or alternative subsystems to provide SCCP traffic rerouting. In addition, SCMG throttles SCCP traffic in the event of network congestion. SCMG uses the concept of a "concerned" subsystem or SP. A "concerned" subsystem or SP is marked as requiring immediate notification if the affected subsystem or SP status changes. An affected SP might not have any subsystems or SPs marked as "concerned"; in this case, when a subsystem fails or inaccessibility occurs at the affected SP, it does not broadcast the status change. If it has entities marked as "concerned," it will broadcast the SSP message so the SCMG at the "concerned" entities can react to circumvent routing to the unavailable SP or subsystem. A response method is used when a message is received that is addressed to an unavailable subsystem from an SP/subsystem that has not been notified of the status change. Upon receiving such a message, the affected SP returns the SSP message. The notified SP/subsystem can then periodically check whether the affected subsystem is available by sending a SCMG Subsystem status Test (SST) to the affected SP. The affected SP returns an SCMG Subsystem Allowed (SSA) message if the subsystem is available again. An SP/subsystem might not have been notified of the status change because it was not on the "concerned" list, the SSA/SSP message sent from the affected SP was lost, or the affected SP was recovering from either an MTP or SCCP failure, in which case it does not make a broadcast upon recovery. Figure 9-22 presents an example of the response method. Figure 9-22. Possible Sequence of Messages Exchanged Between PC-Z and PC-Y When the Toll-Free Subsystem at PC-Z Becomes Unavailable In Figure 9-22 , the toll-free subsystem (SSN = 254) at SP-Z is down. When SP-Y tries to send connectionless data to the subsystem, SP-Z informs SP-Y that the subsystem is not available using the SSP message. SP-Y periodically checks whether the toll-free subsystem at SP-Z is back up again by using the SST message. On the second SST, the subsystem is available again and, as a result, SP- Z sends back a SSA message. It should be understood that other subsystems might exist at SP-Z and these might be functioning as normal, even though the toll free subsystem went down and later came back up again. Upon receiving an SSP message, SP-Y updates its translation tables to select statically provisioned alternative routing to backup SPs and/or backup subsystems (if available). R eplicate Subs y stems Subsystems can be deployed in pairs; this is known as a replicate subsystem. Replicate subsystems are normally only used at an SCP pair and are connected to a common intermediate node (STP). Under normal conditions, SCCP traffic can be load-shared across the replicate subsystems. Optionally, one of the subsystems can be designated as primary and the other as backup. If the primary subsystem becomes prohibited, the backup subsystem services the SCCP messages that were originally destined for the primary subsystem. SCMG messages are used to coordinate the activity of a replicated subsystem. When one subsystem that belongs to the pair wishes to go out of service, a Subsystem Out-of-service Request (SOR) is sent to the replicate's other subsystem. If the subsystem that receives the SOR determines that the replicate can be taken out of service without degrading SCCP performance, a Subsystem Out-of-service Grant (SOG) is sent in response. The determination of whether the SOG is sent is based on the traffic load and available resources. The ANSI SCCP standards specify three optional messages [2 ] for providing SCCP traffic mix information when subsystems are deployed as primary/backup p airs: • Subsystem Backup Routing (SBR) • Subsystem Normal Routing (SNR) • Subsystem Routing Test (SRT) If a primary subsystem becomes prohibited, the intermediate node that is connected to the replicate pair sends an SBR message to the backup subsystem to inform the backup subsystem that it is receiving traffic that was originally destined for the primary subsystem. The SRT is periodically sent to verify the status of a subsystem that is marked as backup routed. When the primary subsystem becomes available again, the SNR message is sent to update the traffic mix information at the backup node. This allows the backup node to be aware that it is no longer serving traffic that is rerouted from the primary node. Figure 9-23 shows an example of using a replicated subsystem with a designated p rimary and backup node. When subsystem 254 is being removed from service, an SOR message is sent from SCP A to SCP B. SCP B determines that it is acceptable for the replicate subsystem to be removed from service and returns a SOG. In this example, the optional SBR message indicating that backup traffic is being received is sent from STP C to SCP B. Figure 9-23. Replicate Subsystem Going Out of Service In Figure 9-24 , subsystem 254 is returned to service at SCP A, and the optional SNR message is sent to SCP B to indicate that it is no longer receiving backup traffic. Figure 9-24. Replicate Subsystem Being Returned to Service The messages used by SCMG are detailed in the following section. S CMG Messa g es SCMG messages are carried using the SCCP's connectionless service. When transferring SCMG messages, Class 0 is requested with no special option. The called and calling party address parameters that set the SSN to SCMG, and set the RI to route on SSN. SCMG messages are encapsulated in the data parameter of the UDT, XUDT, or LUDT message. Table 9-15 shows the SCMG message types. Table 9-15. The Format Identifiers of ANSI and ITU-T SCCP Management Messages. Pseudonym/Message Binary Code Subsystem Allowed (SSA) 00000001 Subsystem Prohibited (SSP) 00000010 Subsystem Status Test (SST) 00000011 Subsystem Out-of-service request (SOR) 00000100 Subsystem Out-of-service Grant (SOG) 00000101 SCCP/Subsystem Congested (SSC) 00000110 Subsystem Backup Routing [1] (SBR) 11111101 Subsystem Normal Routing [1] (SNR) 11111110 Subsystem Routing Test [1] (SRT) 11111111 [1] Found only in ANSI SCCP [2] Appendix C includes a full description of these messages. It should be clear that these are independent from MTP3 signaling network management messages. Signaling Point Status Management Signaling point status management informs the other management functions of changes in other nodes. For point code failures, all functions that are associated with the failed node are marked as failed. Message routing programs broadcast messages to the rest of the network to inform the network of the failure. Subsystem Status Management Changes in the status of any of the local subsystems are reported to other SPs in the network. If the failure is at another node, this SCCP function informs the local subsystems about the problem. < Day Day Up > < Day Day Up > Summary The SCCP provides additional OSI network layer functionality and, with the MTP, p rovides an NSP. It uses the signaling network to transport noncircuit-related signaling, such as queries and responses between switches and telecommunications databases. SCCP provides two categories of service with two protocol classes in each. Classes 0 and 1 are within the connectionless category, and do not establish a virtual connection before transferring data. Classes 2 and 3 are within the connection-oriented category and establish a virtual (logical) connection before transferring data. SCCP provides flexible routing based on DPC, SSN, or GT, or a combination of all three. Global titles are an alias for a DPC and SSN and must be translated at nodes administered with the proper information (usually STPs). This p rocess, which is known as GTT, frees originating nodes from having over- burdensome routing tables. < Day Day Up > < Day Day Up > Chapter 10. Transaction Capabilities Application Part (TCAP) The Transaction Capabilities Application Part (TCAP) of the SS7 protocol allows services at network nodes to communicate with each other using an agreed-upon set of data elements. Prior to SS7, one of the problems with implementing switching services beyond the boundary of the local switch was the proprietary nature of the switches. The voice circuits also had very little bandwidth for signaling, so there was no room for transferring the necessary data associated with those services. Moving to a Common Channel Signaling (CCS) system with dedicated signaling bandwidth allows the transfer of a greater amount of service- related information. Coupling the standardization of data communication elements with the necessary bandwidth to transmit those elements creates the proper foundation for a rich service environment. To that end, TCAP provides a generic interface between services that is based on the concept of "components." Components comprise the instructions that service applications exchange at different nodes. This chapter examines components and other details of the TCAP protocol, including the following: • Overview of TCAP • Message types • Transactions • Components • Dialogue portion • Message encoding • Element structure • Error handling • ITU protocol message contents • ANSI protocol message contents • ANSI national operations In trying to understand how TCAP works, the differences between ANSI TCAP (as p resented in the ANSI T1.114) and ITU TCAP (as presented in the Q.700 series) are normalized as much as possible. While differences between the two certainly exist, a great deal of commonality also exists and often varies only in the naming of identifiers. < Day Day Up > < Day Day Up > Overview The following topics provide an overview of TCAP and how it is used to provide enhanced network services: • Generic service interface • Role of TCAP in call control • TCAP within the SS7 protocol stack • Transaction and component sublayers Generic Service Interface TCAP is designed to be generic to accommodate the needs of a wide variety of different services. This chapter focuses on understanding these generic mechanisms. Chapter 11 , "Intelligent Networks (IN)," examines the prominent network services that use TCAP in an effort to understand how services use these generic mechanisms. Some common services that use TCAP include number translation services, such as Enhanced 800 Service (toll-free) and Local Number Portability (LNP). Other examples of TCAP users are Custom Local Area Signaling Services (CLASS), Mobile Wireless, and Advanced Intelligent Network (AIN) services. Figure 10-1 shows how TCAP uses standardized components as the basic building blocks for services across network nodes. Figure 10-1. Standardized Components Used to Create a Generic Interface [View full size image] Most TCAP services can be viewed as a dialogue of questions and answers. A switch needs additional information that is associated with call processing, or with a particular service that causes it to send a TCAP query that requests the needed information. As shown in Figure 10-2 , the answer returns in a TCAP response, which provides the necessary information, and normal call processing or feature p rocessing can resume. The query for information can be sent to a Service Control Point (SCP) or to another SSP, depending on the type of service and the information required. The SCP is an SS7-capable database that provides a centralized point of information retrieval. It typically handles number translation services, such as toll-free and LPN; however, SCPs are also used for a number of additional IN/AIN services. Figure 10-2. Simple Query and Response R ole o f TCAP in Call Contro l TCAP is used to provide information to SSPs. This information is often used to enable successful call completion, but TCAP is not involved in the actual call- setup procedures. The protocol's circuit-related portion, such as ISUP and TUP, p erform the call setup. This interaction between the service information provided by TCAP and the circuit-related protocol that performs the call setup occurs at the application level, not at the SS7 protocol layer. Within the SSP, the switching software that is responsible for call processing interacts with both the TCAP side of the SS7 stack and the call setup side of the stack (ISUP, TUP) to complete the call. TCAP Within the SS7 Protocol Stack As shown in Figure 10-3 , TCAP is at level 4 of the SS7 protocol stack. It depends upon the SCCP's transport services because TCAP itself does not contain any transport information. First, SCCP must establish communication between services before TCAP data can be delivered to the application layer. Refer to Chapter 9 , "Signaling Connection Control Part (SCCP)," for more information on SCCP's transport services. TCAP interfaces to the application layer protocols above it, such as the ITU Intelligent Network Application Part (INAP), ANSI AIN, and ANSI-41 Mobile Switching to provide service-related information in a generic format. The application layer that passes information down to be encapsulated within TCAP is known as a Transaction Capability User (TC-User). The terms application, service, and TC-User are used interchangeably. Figure 10-3. TCAP Within the SS7 Stack Transaction and Component Sublayers The TCAP message is composed of two main sections: the transaction sublayer and the component sublayer. A transaction is a set of related TCAP messages that are exchanged between network nodes. The transaction portion identifies the messages that belong to the same transaction using a Transaction Identifier (TRID). The message's component portion contains the actual instructions, or "operations," that are being sent to the remote application. This chapter examines both areas in detail, along with the procedures surrounding their use.  . Subs y stems Subsystems can be deployed in pairs; this is known as a replicate subsystem. Replicate subsystems are normally only used at an SCP pair and are connected to a common intermediate node (STP) SP returns an SCMG Subsystem Allowed (SSA) message if the subsystem is available again. An SP/subsystem might not have been notified of the status change because it was not on the "concerned". of subsystems and SCCP-capable signaling points (SPs). It maintains the status of remote SCCP SPs and that of local subsystems. It interacts with the SCRC to ensure that SCCP traffic is not sent