Chapter 6 - Message Transfer Part Level 3

Chapter 6 Message Transfer Part Level Three

		This chapter will discuss MTP level three functions, as used in channelized networks. Some of these functions have been implemented in new IP protocols specifically for the transport of SS7 over IP networks, but those standards are still under development. The purpose of adding the functions and procedures discussed in this chapter to IP networks is to ensure the reliability of the signaling network and guarantee delivery of signaling messages.

		Therefore, it is important to understand MTP level three although you may not be using TDM networks. You will find that MTP level three is still supported in the signaling nodes (SSPs, STPs, and SCPs) although IP is the transport.

		There are two categories of functionality at this level: signaling message handling and signaling network management. These are level-three functions. Signaling message handling is used for routing messages to the appropriate link and determining if messages are addressed to the received node or are to be forwarded. Signaling network management is used to reroute traffic to other links when nodes become unavailable.

		The Message Transfer Part (MTP) level three relies on the services of level two for delivery of all messages. The interface between the two levels consists of a set of primitives. Primitives allow for parameters to be sent to level two for routing over the network in the form of SS7 messages. At the same time, the primitives allow level two to send parameters to level three for message processing.

		Message processing begins at level three. Level three must determine the destination of a message and the user of a message, and maintain the status of the network. Level three uses primitives to communicate to level-four users. Parameters are sent to level four through these primitives.

		In the same fashion, primitives allow level four to send parameters down to level three for inclusion in a signal unit and transmission over the network. These primitives use the same structure as the primitives used between level two and level three.

		Message-handling Overview

		Message handling includes three different functions: message discrimination, message routing, and message distribution. The interface to level two is the message discrimination function. Message discrimination determines who the destination signaling point is by reading the routing label of the message. If the destination point code is the same as the signaling point's self-identification (its own address), the received signal unit is given to message distribution.

		The message-handling function uses the routing label found in all level-four messages to determine who the originator is and who the destination is. It should be noted that a signaling point may have more than one point code. In addition to its own self-identification, the signaling point can also possess a capability point code, or an alias point code. This allows a signaling point to be partitioned into separate entities. For example, it may be advantageous to assign a point code to an STP for gateway services, and another point code to the same STP for global title services.

		Message distribution is the mechanism used to deliver a message received by a signaling point when the destination point code (DPC) is its own. The distribution function must deliver the message to the proper user part or network management function.

		The service indicator octet (SIO) is used by message distribution to determine who the user part is. The user (usually level four, but not always) can be any user part or network management. In the case of network management, the SIO will indicate whether the user is network management or network management testing.

		Message routing is used to pass a message back to level two for routing over the network. If message discrimination determines that the message is not addressed to the receiving signaling point, it sends the message back to message routing. If level four has generated a message for transmission, it also is given to message routing.

		Message Discrimination Overview

		Discrimination applies to all received messages. Message discrimination uses the routing label of the Message Signal Unit (MSU) to determine the destination of a message. The routing label provides the origination address (origination point code [OPC]), the destination address (destination point code [DPC]), and the signaling link code (SLC).

		Message discrimination reads the routing label, specifically the destination point code, to determine if the destination is the receiving node or if the message must be transferred to another node. If the message is intended for the receiving node, then the message is given to the message distribution function, which must determine which user part will receive the message (user part being the level-four function, such as ISDN User Part [ISUP]).

		The user is determined by reading the service indicator octet field. This field is divided into two parts: the service indicator and the subservice field. The service indicator identifies the user part to receive the message. A user part does not have to be a level-four function. Network management and network management testing are level-three functions that use the information field of a MSU.

		The service indicator can also indicate whether special or regular testing messages are being sent by network management. This is also used by level-three network management, each requiring a unique procedure.

		The service indicator octet subservice field identifies whether this message is from an international network or a national network. This part of the message is used to identify the type of point code structure used, so the discrimination function can determine how to read the routing label. If the value of the network indicator in the subservice field indicates an international network, the routing label uses a different structure than it would for a national message.

		The national network indicator does not necessarily mean that this message came from an ANSI network. The national network indicator is used by ITU-TS to differentiate between various structures used within different countries. This allows each country to use its own point code structure within its own national network, while still conforming to the international standard set forth by the ITU-TS.

		If the service indicator octet indicates that this is a national message, the SIO can also be used to indicate two different versions of a national structure. The ''spare" or reserved code in the subservice field can be used to indicate a different version of the national structure.

		For example, a country may have two unique point code structures used in different segments of its network. This could be indicated by using the reserved bits in the national indicator of the subservice field. In ANSI networks, these bits are used to indicate the priority of a message signal unit.

		If used in a private network that does not access the Public Switched Telephone Network (PSTN), the network indicator does not have to be used (since the network is closed and it will always access the same network). This field can then be used as an extension of the service indicator, providing additional user part identification. The implementation of this feature is network dependent, and it is not defined in the ANSI or Bellcore standards.

		In the ANSI network, the national network indicator includes two spare bits. These spare bits are used to indicate the priority of the MSU. Priorities are used by network management during periods of congestion and rerouting procedures. Recommended values for the priorities are given in the ANSI and Bellcore standards, but they can be network dependent.

		If the message is not intended for the receiving node, then it is given to the message-routing function. The message-routing function must determine which link to choose to reach the destination node. In many cases, the next node to receive the message will not be the final destination. There may be other Signal Transfer Points (STPs) that will receive the message before it reaches its destination. A routing table is used to determine which is the shortest path to reach the destination. The objective in routing is to prevent multiple "hops" between nodes, introducing delay in the transmission. The routing table uses a priority mechanism for determining the most efficient route, that is, the route with the most direct path and the fewest hops.

		If the message is for another node, and the message-routing function determines that it cannot reach the destination, network management must respond. Network management is a level-three function that is invoked when a signaling point failure is detected or a link failure is detected. We will discuss these messages later in the chapter.

		If the point code in the routing label of a message is the point code of an alias, the message is given by message distribution to the global title translation function. If the global title translation function is not available at the signaling point, the message is given to message routing for transmission back onto the network.

		The global title translation function is provided by STPs and can be located regionally or within several STPs. Two levels of global title translation exist: partial and final. Partial global title routing provides the point code of the STP responsible for providing final global title, whereas final global title provides the point code and subsystem of the SCP responsible for providing the data being queried.

 

Message Distribution Overview

		If the destination point code is the address of the receiving signaling point, then the message is given to the distribution function. Message distribution must determine who the user is for any given message. This is determined by examining the service indicator octet service indicator field. As mentioned before, the user can be a level-four function or level-three network management.

		In the event that a user is not available, a user part unavailable (UPU) message is sent by network management as an indication to the originating point that the message was discarded because the user part function was not equipped at the destination or was unavailable. The UPU message also provides a cause code, although this cause code is not very specific. There are three causes provided: the user part function was not equipped at the destination, the user part function was not accessible (i.e., out of service due to a processor outage), or the user part function could not be reached for an unknown reason. The UPU message is shown in Figure 6.1.

		Some user parts are processes that reside within a central processor at the signaling point. For example, the Signal Connection Control Part (SCCP) may provide global title translation, considered a user part in this case. When the processor at the signaling point becomes congested or unavailable, the user part unavailable message would be generated.

		This does not indicate a problem with the signaling point, however. The signaling point may be able to carry on with other processing, such as levels two and three, or even level four. This, of course, depends on the architecture of the signaling point itself. When distributed processing is implemented, the impact of a user part unavailable message should be minimal from a signaling point perspective.

		Message Routing Overview

		If a message is received from another destination, then message discrimination passes the message on to message routing for transmission back onto the network. This is a common function of the STP. An end signaling point, such as a Service Switching Point (SSP), would not likely receive messages that needed to be transferred, unless F-links were deployed. Level four uses the routing function to send messages originated by the point code out onto the network.

		Figure 6.1 This figure illustrates the components of the UPU message.

 

		The routing function must first determine what the destination address is by reading the routing label and looking for the destination point code. In an ANSI network, the subservice field of the service indicator octet will indicate a national network, which means the point code will be a 24-bit field. If the subservice field indicates that the message came from an international network, then the point code will be a 14-bit field.

		The international point code structure is very different from the ANSI structure. The first value indicates the zone of the address. The zone is a four-bit value, and can be used to address a country or a group of countries. The next field is the area identifier. This is an eight-bit field and identifies the network of the address. The third field is the individual signaling point identifier, and it identifies the actual member of the network. A member is any signaling point in the network.

		It is important to note that the international point code structure is only valid at the international hierarchy. Once a particular gateway is reached, messages are converted into national formats, where the point code structure and protocol rules can change. This allows each country to deploy SS7 in its network to meet the needs of the individual country, rather than to define a standard that does not address everyone's needs. The ITU-TS distributes point codes for use in the international network.

		In the U.S., the national standard is ANSI. The ANSI standard is used in the Regional Bell Operating Companies (RBOCs) networks, but it is modified (as published by Telcordia) for the specific requirements set forth by the BOCs. The point code structure defined for usage in the U.S. is quite a bit larger than the ITU-TS version. Point codes in the ANSI network are distributed by Telcordia.

		The first field in the point code is the network identifier and it is used to identify the individual network being addressed. This is an eight-bit field. The network identifier is reserved for only the largest of service providers. Those who receive a unique network identifier are also given usage of all numbers in the cluster and member fields.

		Network identifiers 1 through 4 are reserved for medium networks. Network identifier 5 is reserved to identify small network clusters. There is a network cluster code associated with each state and territory in the U.S. and Canada. These are used to identify smaller networks. Medium networks are those that do not have enough signaling points to warrant the distribution of an entire network number. Presently, only network identifiers 1 and 2 have actually been assigned to service providers. The cluster field then identifies the individual networks.

		The cluster field is also an eight-bit field and is used in two different ways. In the case of those networks that have their own network identifiers, the cluster number can be used to group signaling points together to provide more efficient routing (cluster addressing). In medium networks (network identifiers 1 to 4), the cluster field identifies the individual network.

		Small networks (network identifier 5) use cluster value 1 or 2. The member codes are then divided into three code blocks and given to very small networks with only a few signaling points. The codes are assigned in blocks, depending on location and number of signaling points in the network. The member value of 0 is reserved for STPs.

		Cluster addressing allows STPs to maintain small routing tables. All messages will contain a full point code, but in some networks partial routing is used. Partial routing only examines the network and cluster fields of the point code or, in some cases, only the network identifier. The message is then routed based upon that value only. The full point code does not appear in the signaling point's routing table.

		When networks grow quite large, partial routing helps minimize the number of point code entries required at every signaling point. Every local STP must have the full point code of all signaling points connecting to it directly (homing). If any other point codes are connected indirectly (through other signaling points), only the network identifier and cluster are entered into the routing table. The last field of the point code is the member code.

		The message-routing function receives messages from level four when a newly created message is to be transmitted, and from message discrimination when a message is received but needs to be transferred to another signaling point. The message routing depends on the destination point code located in the routing label to determine the destination of the message, and to determine which link the message is to use.

		There are two forms of routing that may be deployed within any signaling point: full point code routing and partial point code routing. In the case of full point code routing, the signaling point looks at the entire point code to determine how the message will be routed. This means the routing table for that signaling point must include all point codes for all connecting signaling points and end points in the network.

 

Even though a particular point code does not directly terminate with the routing signaling point, the point code of the remote signaling point must be resident in all routing tables. This means that large networks will require large routing tables in their signaling points.

		The use of cluster routing reduces the number of point code entries in the routing table. With cluster routing, only the cluster code is read to determine the path for a message. This only applies to remote signaling points, however, and eventually full point code routing must be used to reach the final destination. The home STP is usually the point at which full point code routing must be used.

		All other STPs need only the cluster address to route a message. This is a significant reduction in the space required in the routing table. Memory requirements can get cumbersome in large networks, making partial routing a necessity.

		When using cluster routing, the STP can have the same cluster number as all those signaling points connecting to it, or it can have a unique cluster number. If it uses the same cluster number as its end points, then an alias point code must be assigned for global title functions resident within the STP. If the STP does not provide this function, then there is no need for an alias.

		The use of a unique cluster for each signaling point code does allow the STP to be directly addressed within any message and can be of benefit for network management. Whether the STP has a unique cluster number or uses the same cluster number as the other signaling points in this cluster group, the member code is usually zero, identifying it as an STP (this is optional, but widely used in many U.S. networks).

		Another form of partial routing is network routing. This uses the same concept as cluster routing but reads only the network address. This is very useful at signaling points connecting to other networks. In some countries, there may be one common database for all networks in the country. In this case, network routing will allow signaling points to route to that database with only the network identifier.

		Gateways are another likely candidate for network routing. Because a gateway connects to so many networks, routing tables can get cumbersome and difficult to maintain. The network administrator must be aware of all point codes it routes to. With network routing, only the network identifier need be known, saving administration and memory resources of the signaling point.

		Link Selection

		The signaling link used to route the call is determined by the value of the signaling link selection (SLS) field located in the signaling link code (SLC) field of the routing label. The SLC code is a preassigned code representing a physical link. The SLC is not the link number, but a logical connection to a physical link.

		All links are assigned a SLC and a terminal number. The terminal number is a logical connection to a physical link. The SLCs range from 0 to 127. This means that each link will have more than one SLC. When a link is deployed, it is up to the equipment software to reallocate the SLCs to accommodate the newly equipped link. When a link fails, software will again reallocate the SLCs so that the failed link no longer has an SLC.

		Before transmission, level-three routing determines which link will be the next outgoing link. This is based on several factors. First, all links within a linkset must carry equal traffic (load sharing). This means no link will be carrying more than the others. The MSU size must also be figured in the traffic capacity of every link, so that one link does not become burdened with large messages while another is sending only small messages.

		After a link is selected, the signaling link code of the physical link is placed in the SLC field of the routing label and sent to level two for transmission. When the message is received at the remote signaling point, the bits in the SLC field are rotated one position to the right by level-three routing. Presently, only the five least significant bits are rotated, even though the standards now support an eight-bit SLC field. The three most significant bits are used for link selection in networks where eight-bit rotation is supported (this is optional today, and will slowly be implemented into all networks).

		There are exceptions when bit rotation is not to be used. Call setup messages and database query messages are examples of messages that should not use bit rotation. These messages usually require more than one signal unit to be sent. These signal units must be received in order, or an error will occur. To prevent them from taking different routes and being received out of order, the messages relating to one transaction or to the same circuit connection always follow the same path (use the same links from one signaling point to another signaling point). Cross links (C-links) between mated STP pairs do not use bit rotation.

		There are also certain maintenance messages which must be routed over specific links. For example, a changeover order is always sent over an alternate link, but the acknowledgment of a changeback order can be routed over any available link. Level-three routing must also take these rules into account before selecting a link and rotating the signaling link selection bits.

		Load sharing must be used whenever there is more than one link or one linkset. In the event that there is more than one linkset, the least significant bit (LSB) is used to select the linkset to be used.

 

The remaining four bits then identify the link within the linkset. In the event that only one linkset exists, the LSB is used as part of the link identifier, but the most significant bit (bit 5) is left unused (maintaining a four-bit link selection code).

		In the international network, load sharing is not used. The SLC field is used to identify the voice circuit identification code (CIC) for all Telephone User Part (TUP) messages. For Data User Part (DUP) messages, the bearer identification code is identified in this field. Bit rotation is not used in international networks.

		Normal Routing Procedures

		Before a message is transmitted, the routing table must identify which link and linkset to route the message to (see Figure 6.2). The routing table is maintained by administration personnel. Every routing table must indicate the primary route to a destination point code and an alternate route(s). Each route is assigned a priority, which indicates whether it should be first choice, second choice, etc. Some equipment manufacturers use different techniques for identifying the priority for a route, but the basic concept is the same.

		The rule is to always choose the most direct route to any destination. The most direct route will always be the route with the fewest "hops" through other signaling points. In the case of an end signaling point, if an F-link is available, it should be first choice if it terminates at the destination. If an E-link is available, it should be the second choice. A-links are last-choice routes. Of course, in many cases, the A-link may be the only route to a destination point code, in which case it will be the first choice.

		Figure 6.2 This figure shows a typical routing scheme for SS7 entities. The numbers indicate the choice, or weighting factor, assigned to each of the links. For example, the "one" indicates first-choice route, and so on.

 

		For a STP, if the destination is an end point (end points are Service Switching Points [SSPs] and Service Control Points [SCPs]), then an A-link should be first choice. If there are no available A-links to the destination point code, then an E-link should be used (if one exists). If the message must go through another STP to reach the destination point code, then the STP which the destination "homes" to should be the next destination for the message. The home STP is that which connects directly with the signaling point (Figure 6.3).

		In the event that the home signal transfer point cannot be reached directly, then the message should be routed to a primary STP in a two-level hierarchy. The primary STP of the destination point code should be the STP used to reach the home STP. In the event that the primary STP cannot be reached, then the primary STP of the message originator should be used.

		When IP facilities are used for signaling links, the routing is somewhat different. The "link selection" becomes more of a virtual selection; however, the SLC code is still significant. Depending on the protocol being used to provide level three services, the SLC can either be maintained by encapsulating MTP level three into an IP message and transmitting to the distant end for processing, or the SLC is emulated by an equivalent code within the IP stack.

		Network Management Overview

		Network management at level three provides the procedures and functionality to reroute traffic through alternate links and linksets or to control the flow of traffic to a specified destination point code. There are three separate network management functions used in SS7:

		Figure 6.3 In this figure, both A and B have the same "home" STP. A home STP is one that is directly adjacent to the SSP.

 

		Traffic management

		Link management

		Route management

		Traffic management is used between two signaling points to divert traffic away from failed links. Traffic management messages are originated by the signaling point, which detects a problem in a link and is sent over an alternate link to inform its adjacent signaling point not to route messages over the affected link. Traffic management also triggers route management from the receiving signaling point to its adjacent nodes.

		Traffic management messages are not propagated through the SS7 network. They are only point-to-point. The difference between traffic management and link management (which incorporates the use of level-two Link Status Signal Units [LSSU]) is the fact that the LSSU is carried over the signaling link that is in question.

		This fundamental difference points out that the link must be capable of carrying level-two traffic, while not being able to carry level-three and -four traffic. In the event that a link cannot carry level-two traffic (such as in the case of a complete link failure), then level-three traffic management will be implemented to advise adjacent signaling points that the signaling link can no longer be used.

		Link management consists of activation and deactivation procedures, as well as link restoration. These functions are used with level two to restore failed links back into service. The link management function is what triggers level-two link alignment procedures and guides the transitions through the various states of alignment.

		Route management is used to divert traffic from a specific signaling point. This is a function provided by STPs, adding an important element to the network. Route management does not pertain to any one specific link as traffic management does, but to an entire signaling point. Route management is triggered by traffic management messages and is sent to the adjacent STPs when a traffic management message is received.

		For example, in Figure 6.4, signaling point F has failed its link to signaling point D. Signaling point F sends a changeover message to signaling point D through signaling point E (traffic management). Signaling point E has no knowledge of what the traffic management message is about, nor does it care. It is transferring the message on to its final destination.

 

		Figure 6.4 This figure depicts traffic management and route management.

		Signaling point D, upon receipt of the changeover message, will send a transfer-prohibited (TFP) message to its adjacent nodes. The TFP message indicates the destination point code, which is no longer accessible through signaling point D. All adjacent signaling points then invoke rerouting procedures to begin routing traffic destined for signaling point F through signaling point E, since this is the only available route. If there were other links available through D, then those links would be used to route traffic to F and the TFP would probably not be sent, since signaling point F can still be reached through D.

		Link management is then invoked by signaling point F to restore the failed link. This triggers level two to begin the alignment procedure and controls the transitions from one state to the next through the use of timers. When the link has been restored by level two, level-three link management is notified, and traffic management sends a changeback message to restore traffic back to the newly restored link.

		Upon receipt of a changeback message, signaling point D then invokes route management to alert adjacent nodes that traffic destined for signaling point F can now be routed back through signaling point D.

		This is only one example of how these three network management functions work together. As we discuss each management function, we will discuss specific examples in greater detail.

		Signaling Network Management Procedures

		As we mentioned before, there are three types or categories of network management. Traffic management diverts messages away from failed links, link management is responsible for the activation and deactivation of signaling links, and route management is responsible for the rerouting of messages around failed signaling points. Route management also controls the flow of messages to a signaling point.

		Network management also provides a layered approach to managing troubles in the network. Procedures are provided that deal with network congestion and outages, from the link level all the way up to the route level.

		Level two provides the means to detect errors on individual links. Level two is not interested in problems outside the signaling point. Level two is only concerned about an individual link. Every link has this function, which is controlled by level-three link management.

		When an error is encountered, level two reports the error to level three, which must then determine which procedures to invoke. Procedures begin at the lowest level, the link level, and work their way up to the route level.

		Link management directs the procedures at the link level. These procedures do not have a direct impact on routing or the status of signaling points. They do trigger other network management events at level three, however.

		Link management does have an impact on other functions, but indirectly. Traffic management is affected by link management, primarily because traffic management must divert traffic away from a link that link management has failed and removed from service. Traffic management ensures the orderly delivery of diverted traffic, providing for the transfer of unacknowledged messages to another link buffer and retransmission of messages on a different link.

		Traffic management does not divert traffic away from a signaling point. The purpose of traffic management is to redirect traffic to a signaling point to different links. However, traffic management does impact routes and route-sets to specific destinations. If a particular route is used by another signaling point to reach a destination, and traffic management has diverted traffic away from that route, adjacent signaling points may have to invoke route management procedures.

		Route management diverts traffic away from signaling points that have become unavailable or congested. The reasons vary, but regardless of the reason, traffic management and link management will be involved at the affected signaling point. In the meantime, all the signaling points around the affected signaling point are invoking route management procedures to prevent messages from becoming lost.

		This layered approach to network management is what makes SS7 networks as robust as they are. Very few network troubles actually cause the network to fail. In fact, there are very few network outages at all in SS7. The protocol maintains a very high level of reliability, due mostly to the Message Transfer Part (MTP) and the network management procedures discussed in this section.

		In this section, we will review each of the messages used in network management and the procedures used. We will look at the structure of each message type and the parameters used.

		Network management messages use the Message Signal Unit (MSU) structure as shown in Figure 6.5. The routing label is used for routing the message to the appropriate signaling point. Within the signaling information field (SIF) is information concerning the point code experiencing the failures or the link that has failed. In addition, status codes, priority codes, and other maintenance codes can be included.

		Because of the nature of these messages, the information field will vary from one network management message to the next. As we discuss each type of network message, we will discuss the structure of the information field and how it is used.

		Link Management Procedures

		Link management provides the procedures necessary to manage the individual links within a signaling point. Link management does not view links from a linkset or even a route perspective, but from an individual perspective.

		The management message (shown in Figure 6.5) uses an H0 and H1 heading code to identify the type of management message being sent. The H0 heading code identifies the type of message, whereas the H1 heading code identifies the type of message for the procedure being declared. Next are the values for the H0 heading codes:

H0 Heading Codes
0000	Spare
0001	Changeover and changeback messages
0010	Emergency changeover message

		Figure 6.5 Network management messages use the MSU. The H0/H1 field is the label which identifies the type of network management message being sent.

 

0011	Transfer-controlled and signaling-route-set-congestion-test messages
0100	Transfer-prohibited, -allowed, -restricted messages
0101	Signaling-route-set-test messages
0110	Management inhibiting messages
0111	Traffic restart messages
1000	Signaling-data-link-connection messages
1001	Spare
1010	MTP user flow control messages

		The link management procedures require the use of Message Transfer Part level-two functions or SAAL to report failures and link status to an adjacent signaling point. These messages are not propagated through the network. Link management is only concerned about the local end of a link.

		There are three functions provided by link management:

		Link activation

		Link restoration

		Link deactivation

		These three functions are explained as follows in greater detail.

		Link Activation

		When a link is first activated, level three directs level two to begin the alignment procedure (described in Chapter 5) and place the link in service. Before messages can actually be transmitted over the link, link management will also send test messages over the link, to ensure the integrity of the link.

		Level two is used to inform the adjacent signaling point of the activities at level three. This is accomplished using the Link Status Signal Unit, described in Chapter 5. The LSSU identifies the status of the link, but does not instruct the adjacent signaling point on any procedures.

		Once the link has been activated and is considered in service, a signaling-link-test message (SLTM) is generated and transmitted over the link. Upon acknowledgment of the SLTM (signaling-link-test acknowledgment [SLTA]), the link is restored to service and traffic is allowed over the link. In the event that the link has a failure (determined and reported by level two), link management invokes the restoration procedures.

		Restoration involves the Link Status Signal Unit (LSSU) to inform the adjacent signaling point of the events taking place. The signaling point that detected the errors is responsible for invoking alignment procedures and notifying the adjacent signaling point about the status.

		Level-three timers are used to control the procedures and ensure that the link does not get caught in an endless loop of alignment procedures. When a link has successfully passed the alignment procedures, level three generates a signaling-link-test message and transmits the test message over the network (as it did during activation). When an acknowledgment (SLTA) is received for the SLTM, the link is considered restored and level three changes the local status to available, in service.

		Link deactivation is used when a link is found in error and needs to be placed into alignment. Link deactivation must first stop all traffic to the link, which will invoke traffic management procedures (diversion of traffic from the failed link). Link management then ''disconnects" the link from its logical connection (signaling link code).

		Every link has a logical connection. In any signaling point, there are a number of logical connections available for a link. All logical connections must be associated with a signaling link selection code. This code is a dynamic code assignment, which changes according to the link status.

		Each link within a linkset is given a unique signaling link selection code, which is used by routing to determine which links a message should be routed over. This is directly related to the bit rotation procedure discussed earlier in the section about MTP level-three routing.

		The bits rotated are the signaling link selection bits. A link may have more than one SLS code. All codes must have an assignment, because of the way the bit rotation is used to select a link. When any link becomes unavailable and must be placed out of service, link management must disconnect the link from its logical connection. This means the table will change. One can view this table as a mapping to every link in the system. Each signaling point must have a similar table in software that allows it to choose signaling links based on status.

		Link management changes the table based on the local status (reported by level two) or the remote status (reported by level two via the LSSU). When a link becomes available again, it is reconnected to its logical connection.

		Notice that all links are listed in numerical order. This ensures that the assignment is linear and not random, which allows both ends of the link to remain synchronous. Because the signaling link code is transmitted in maintenance messages, the code must be the same at both signaling points.

 

Link management can also drive a function referred to as automatic link allocation. Very few systems offer this feature, which allows links from one linkset to be disconnected (logically) by link management and reassigned to another linkset. This requires a link to be connected to the same signaling point as the failed link that it is replacing. This feature is usually invoked by a threshold value, which is typically administrable. When a linkset falls below the predefined threshold, a predefined link can be removed from its linkset and reassigned by link management to replace failed links in another linkset.

		Automatic link allocation also provides for voice circuits to be used as links. The requirement is that the facility must be digital and of the same data rate as the failed link. This is not a concern, because most voice circuits in central offices today are DS0A circuits (interoffice trunks, not local trunks).

		Link management is able to remove the voice circuit from its connection and reassign the voice circuit to a linkset. A predetermined signaling link selection code is assigned to the new link. When the failed link returns to service, the voice circuit is removed from the linkset and returned to service as a voice circuit.

		This feature requires the voice circuit to be connected to the same signaling point as the failed link. This could be the case between two signaling points, provided the voice circuit was terminated in the same signaling point as the failed link. This forces the assumption that the signaling points must be end offices, which provide both voice circuits and SS7 circuits (Service Switching Points [SSPs]).

		To accommodate link management and automatic allocation, a signaling-data-link-connection message (Figure 6.6) must be generated and sent to the adjacent signaling point to inform the adjacent signaling point of the new assignment. The adjacent signaling point must make the same assignment for the link to work.

		In the SDLC message, the signaling link number is the physical link number (such as link one, two, or three), which in turn may be SLC 0, 6, or 12. When identifying the signaling link code, only the first code is provided. The other signaling link codes, even though they are assigned to the same link, are considered secondary and are not used in network management messages.

		Figure 6.6 The signaling-data-link-connection (SDLC) message uses the network management structure, and consists of the components shown here.

 

		Once the SDLC message has been received, an acknowledgment must be sent to confirm that the adjacent signaling point has made the same assignment in its own database. This is accomplished using one of three messages: connection-successful, connection-not-successful, or connection-not-possible.

		If the connection was successful, then traffic can begin on the newly allocated link. If connection was not successful (for any of the reasons provided), then the procedure is aborted.

		In the unlikely event that two signaling points invoke automatic allocation simultaneously, the signaling point with the highest point code will be considered first, overriding the other signaling point.

		To understand the impact that link management has on other portions of the signaling point, we must look at the other network management procedures. Keep in mind the layered approach discussed earlier in this section, and it will help you to understand the individual roles played by all these functions.

		Traffic Management Procedures

		Traffic management is used to divert traffic away from failed signaling links. It uses several messages which are sent using the Message Signal Unit (MSU) over adjacent links or adjacent linksets to adjacent signaling points.

		Traffic management also deals with the source of congestion and provides flow control procedures as well. The objective of traffic management is to deal with the source of a problem whenever possible.

		Traffic management also handles problems on a more direct level than other network management procedures. In essence, network management is offered at several layers, traffic management being the middle layer.

		Traffic management provides the mechanisms for managing traffic diversion due to:

		Signaling link unavailability

		Signaling link availability

		Signaling route unavailability

		Signaling route availability

 

Signaling point restricted

		Signaling point availability

		Signaling Link Unavailability

		In the event that a signaling link should become unavailable, be manually blocked, deactivated by network link management, or inhibited, traffic management provides for the diversion of all traffic normally routed over the affected link to alternate links within the same linkset or other linksets which can route to the same destination.

		Signaling Link Availability

		In the event that a failed, blocked, inhibited, or deactivated link should become available again, traffic management diverts messages back to the affected signaling link. Procedures are provided to ensure that messages are not lost and the transmission is controlled to ensure an orderly delivery of all buffered messages.

		Signaling Route Unavailability

		In the event that an entire route should become unavailable, forced rerouting is used to divert the traffic away from the affected route. A route is a linkset or a group of linksets with a common destination.

		Signaling Route Availability

		Controlled rerouting is used to divert traffic back to a previously unavailable route. It involves an entire linkset, rather than just an individual link. The diversion of traffic to another alternate linkset or route must be conducted in an orderly fashion to prevent messages from being lost.

		Signaling Route Restricted

		When a route becomes restricted, traffic must be diverted to a route of equal priority (or cost). In effect, this procedure invokes load sharing over two routes to prevent a route from becoming unavailable due to congestion (from multiple link failures, for example).

		Signaling Point Availability

		The Message Transfer Part (MTP) restart procedure is used to divert traffic to a signaling point now made available. The MTP restart procedure is a new addition to the Bellcore standards and is not yet widely implemented. However, Bellcore added this ANSI procedure with the intent of implementing it in Bellcore networks in the future.

		Traffic Management Message Structure

		The traffic management message provides the signaling link code of the failed link and, in some cases, the forward sequence number of the last good MSU received on the failed link. This information is sent to adjacent signaling points so they can assume the traffic for the failed link and ensure that no messages are lost. In order to ensure that no messages are lost, the traffic management procedure includes a method for copying all MSUs remaining in the transmission buffer of a failed link to the newly selected link. This procedure will be explained in further detail.

		In all cases of traffic management, existing traffic on any one signaling link must not be interrupted. This means the procedures must allow normal traffic to continue while links are assuming the traffic of other failed links.

		Changeover

		The changeover message is used to divert traffic away from a failed link. LSSUs are sent by level two to indicate the status of the link throughout this procedure. This allows the two signaling points to maintain current status while the link is being realigned. When LSSUs are not being sent, Fill-In Signal Units (FSNs) are transmitted.

		Figure 6.7 shows the contents of the changeover message. The forward sequence number is the FSN of the last MSU received by the failed link. This serves as an acknowledgment for any unacknowledged signal units received on that link. Next are the H1 heading codes used for changeover:

		Figure 6.7 The changeover order (COO) consists of an SLC field, indicating the signaling link code of the failed link and the FSN of the last good MSU received on that link.

 

0 0 0 1	Changeover order signal
0 0 1 0	Changeover acknowledgment signal
0 0 1 1	Extended changeover order signal (SAAL links)
0 1 0 0	Extended changeover acknowledgment signal (SAAL links)

		The signaling link code identifies the failed link. As we learned in our previous discussions about the SLC, this number is not necessarily a physical link number, but the logical link number assigned to the link. Refer to the section in this chapter regarding the routing label and the use of the SLC for details on this field.

		It should also be mentioned here that all changeover-related messages (changeback, acknowledgments, etc.) use the same structure, using the same fields. These related messages are discussed separately for clarity.

		When a link fails (Figure 6.8), there are still MSUs in its transmit buffer which have not been acknowledged. Before these MSUs are discarded and the link realigned, they need to be dealt with in such a way that the messages will not be lost.

		When level two detects a link failure, it first performs a buffer update. The messages in the transmit buffer of the failed link must be placed in the transmit buffer of the alternate link, so that they can be retransmitted in the event that an acknowledgment is not sent from the adjacent signaling point.

		After the transmit buffer has been updated, the changeover message is sent over the alternate link to inform the adjacent signaling point that all messages to the affected node must be rerouted over the alternate link. The message will contain the signaling link code of the failed link, and the forward sequence number (for MTP L2) or the sequence number of the last sequenced data protocol data unit (for SAAL) of the last good MSU received by the affected signaling point. The FSN in this message is used as an acknowledgment to the adjacent node so that it does not have to retransmit all MSUs in its transmit buffer.

		The traffic is diverted to a link or links within the same linkset if there are any links available. However, there are times when there may not be any links available in the linkset. If there are no links available in the same linkset, another alternate linkset or linksets may be used. The destination must be the same for both linksets. In the event that there are no linksets available, routing management is triggered to reroute messages around the signaling point.

		Figure 6.8 In this figure, the link indicated by dashes has failed. Signaling point A sends a COO to signaling point B, indicating the SLC code of the failed link.

 

		In the event that a STP does not normally carry traffic for the affected signaling point (the changeover was to a linkset to a different signaling point), a transfer-prohibited message is sent by route management at the concerned signaling point. This is to prevent messages from being routed to the concerned signaling point and possibly causing congestion to occur (because the signaling point is now handling twice the traffic).

		A transfer-prohibited message informs adjacent nodes that no traffic addressed to the affected signaling point should be sent to the concerned signaling point. The concerned signaling point is that which originated the changeover message and is no longer carrying traffic to the affected destination.

		The affected destination is that which has the failed link. The affected point code is usually provided in network management messages. Note that messages being carried over the concerned point code are being sent from the signaling point that used to carry traffic to the destination, but lost its path. The concerned signaling point has a path, and is now "relaying" those messages, but should not be sent all traffic for this destination.

		A good example of a situation like this is depicted in Figure 6.9. A signaling point that is adjacent to the affected signaling point has received a changeover, but does not normally carry traffic for this destination; therefore, the concerned signaling point sends the transfer-prohibited message to any adjacent signaling points. When the changeover message is received by the concerned signaling point, a changeback acknowledgment is sent to indicate that the changeover was received and traffic is being diverted.

		If there are no available links to the affected point code, then a time-controlled diversion procedure is implemented. This is also true if a processor outage is received, or if the signaling link is marked by the signaling point as inhibited, but is receiving traffic. The time-controlled diversion procedure prevents the signaling link from being failed and realignment from starting.

		This is accomplished by setting level-three timer T1, "Delay to avoid message missequencing on changeover." When timer T1 expires, new traffic can then be transmitted on the alternate link. This helps prevent missequencing of messages, which may occur during a changeover initiated by the receipt of a processor outage or link-inhibited state.

 

		Figure 6.9 A COO may be sent through another signaling point, as depicted here. There is no other path for the message to get to signaling point B, so it must be sent through an alternate route. The TFP is sent to all adjacent signaling points to prevent messages from being sent through A to B.

		Figure 6.10 When timer T1 expires, the COO is sent to B. This is referred to as time-controlled diversion.

		Figure 6.10 shows when the use of time-controlled diversion may be necessary. Notice that signaling point A has lost its path to B, which is the STP for signaling point D. The changeover procedure is diverting traffic through signaling point C, which is adjacent to the affected signaling point D.

		If the signaling link becomes available, and the timer T1 has not yet expired, the time-controlled changeover is canceled and traffic may resume on the affected link. However, if the MTP becomes unavailable at the affected point code, the MTP restart procedure is initiated.

		MTP restart is used to reset all timers and counters used by the MTP and to resynchronize the link. This means that all sequence numbering and error rate monitors are restarted as if for the first time. MTP restart is discussed in a later section.

		If there is a processor outage at the affected link, and the timer T1 expires ("Delay to avoid message missequencing on changeover"), all messages that are available for retransmission are discarded. The processor outage means that level four and possibly level three are not functional and the messages could not be processed anyway. The affected link will not have any recollection of these MSUs ever being received, because its receive buffer will have been reset.

		If there is no acknowledgment received within timer T2 ("Waiting for changeover acknowledgment"), retransmission on the alternate link begins. This means that the changeover procedure will start without the acknowledgment. Any new traffic will be transmitting on the new link(s). This prevents a bottleneck in the event that the changeover message or the changeover acknowledgment was lost.

		If a changeover acknowledgment is received, but there was no change-over order sent, the acknowledgment is ignored and discarded. No further action is necessary.

		Changeback

		The changeback message is used when a failed link has been restored, and traffic may now resume over that link. The message structure, as seen in Figure 6.11, consists of the signaling link code of the now-restored signaling link and the changeback code. Below are the H1 heading codes used in changeback messages:

0 1 0 1	Changeback declaration signal
0 1 1 0	Changeback acknowledgment signal

		The changeback code is a unique pattern assigned by the originator of the changeback message. The changeback code allows a signaling point to initiate the changeback procedure for a number of signaling links. When the acknowledgment is returned, the acknowledgment must also carry the unique changeback code. This allows for the discrimination between acknowledgments and allows the signaling points to begin sending traffic in relation to each of the individual changebacks.

		Figure 6.11 The changeback declaration (CBD) is sent to an adjacent signaling point to indicate that the link that previously failed has now returned to service.

 

		Without this code, there would be no mechanism to allow for the orderly diversion of traffic over multiple signaling links. This is an issue only when there have been multiple link failures to one destination and all of the signaling links have been made available at the same time.

		When the changeback is initiated, all transmission of MSUs on the alternate link is stopped. The changeback message is sent over the alternate link to the affected signaling point to inform it that the changeback procedure has been stopped and transmission over the failed link will now resume (Figure 6.12).

		The affected signaling point must then send a changeback acknowledgment (Figure 6.13). This will trigger the procedure. All MSUs sent by level four or by other links destined to the affected signaling point are stored in a buffer until the changeback procedure is complete.

		The changeback acknowledgment (CBA) may be sent over any available link as long as the message is routed to the originating point of the changeback message. Once the acknowledgment has been received, the MSUs that were stored in the changeback buffer are sent over the now-available signaling link. There is no need to transfer unacknowledged MSUs from the alternate link transmit buffer to the now-available links transmission buffer.

		Figure 6.12 This figure shows the changeback declaration being sent to signaling point B by using an alternate link to C. If there had been an alternate link directly to B, it would have been the path used for the CBD.

		Figure 6.13 The CBA is sent over any available link. In this case, the previously failed link is used for the CBA.

 

		In the event that the changeback is originated from a signaling point that sent a transfer-prohibited, a transfer-allowed is sent to adjacent signaling points, allowing messages to be routed to the signaling point (Figure 6.14). Likewise, if the affected signaling point became isolated due to the failed link, the signaling point is now made available by route management.

		If an acknowledgment is not received within timer T4, ''Waiting for changeback acknowledgment-first attempt," the changeback declaration is repeated and timer T5, "Waiting for changeback acknowledgment-second attempt," is started. If timer T5 should expire before an acknowledgment is received, traffic is automatically started on the now-available signaling link. Maintenance functions within the signaling point are alerted in the event that there was an error in the acknowledgment transmission.

		Emergency Changeover

		In the event that a changeover procedure is initiated but the transmit buffer cannot be read, an emergency changeover procedure is used. The emergency changeover does not provide the forward sequence number (MTP L2) or sequence number (SAAL) of the last good MSU received, because the buffer has been cleared and that information is not available. Below are the H1 heading codes used in emergency changeover messages:

0 0 0 1	Emergency changeover order signal
0 0 1 0	Emergency changeover acknowledgment signal

		Figure 6.14 When MSUs are sent by the affected point code to STP B in this example, the transfer-allowed (TFA) is sent to all of B's adjacent signaling points.

 

Level two begins sending the LSSUs on the failed link and Fill-In Signal Units (FISUs) when the LSSUs are not being sent. All new MSUs are diverted to the alternate link or linkset.

		As was the case in the changeover procedure, the traffic can be diverted to multiple links or alternate linksets. Load sharing is invoked when there is existing traffic on these links to prevent a congestion condition on any one link.

		In the event that there are no available paths to the affected signaling point on which changeover and emergency changeover messages may be transmitted, the time diversion procedure is invoked. As mentioned in the changeover procedure description, time-controlled diversion allows traffic to be diverted without failing the link (link status of "out-of-service").

		Forced Rerouting

		The forced rerouting procedure is initiated in the event that a route to a specific destination becomes unavailable. The purpose is to reroute traffic around the concerned signaling point to the destination, without losing messages or causing any other route to become congested.

		Figure 6.15 shows MSUs destined for signaling point A. Signaling point A becomes unavailable through the route using signaling point C. Signaling point C sends a transfer-prohibited message to signaling points D and E to inform them that the route to signaling point A is inaccessible, and messages should be rerouted through an alternate route.

		In Figure 6.16, the alternate route is through signaling point B. All traffic to signaling point C (destined to signaling point A) is stopped. The forced rerouting buffers store all MSUs with destination of A. When the alternate route is determined (B in this example), all diverted traffic is transmitted to signaling point B. The contents of the forced rerouting buffer are sent first.

		Figure 6.15 In this figure, MSUs are destined to A, through C. The link from C to A has failed. The links from C to B have failed as well, causing messages to be sent back to D and E (circular routing).

 

		Figure 6.16 The link from A to C has been restored. C sends the TFA to its adjacent nodes, allowing traffic to A.

		Figure 6.17 To prevent circular routing, D and E send TFPs to C. This prevents C from sending MSUs destined for A or B back to D and E.

		When the route to signaling point A through signaling point C becomes available again, signaling point C sends a TFA to signaling points D and E (Figure 6.17). Messages destined to signaling point A can now be rerouted back through signaling point C, or signaling point B, depending on the network configuration.

		Any existing traffic on the link should not be interrupted in any way. If there is a lot of traffic on the alternate route, load sharing is used to spread the traffic over the links evenly. This procedure should not cause the alternate route to become inaccessible due to failure or congestion.

		If there are no alternate routes available, traffic is blocked and messages stored in the forced reroute buffer are discarded. Flow control is used to inform user parts to stop sending traffic to the affected point code. A transfer-prohibited is also sent to the adjacent signaling points to stop traffic from being sent to the concerned signaling point (Figure 6.18).

		Controlled Rerouting

		The objective of the controlled rerouting procedure is to restore traffic to the most favorable route, in cases where a particular route was previously restricted. This is probably best explained by Figure 6.19. In the figure, traffic is destined to signaling point A. The primary routes to signaling point A from signaling points D and E use signaling point C, with signaling point B used as an alternate.

 

		Figure 6.18 Once the transfer-prohibited (TFP) has been sent, MSUs in the buffers of D and E can be sent to A through C.

		Figure 6.19 The links from C to A are primary linksets for routing to signaling point A.

		Figure 6.20 Links from C to A and C to B have failed.

		The route from signaling point C to signaling point A fails. In addition to this route failing, the route from signaling point C to signaling point B fails (Figure 6.20). This scenario in the previous example (forced rerouting) caused a transfer-prohibited message to be sent from signaling point C to signaling points D and E. This forces signaling points D and E to route all traffic destined for signaling point A through signaling point B.

 

		Figure 6.21 The link from C to A has now been restored. The TFA is sent to D and E to allow traffic for A to be sent to C.

		Figure 6.22 Signaling points D and E send TFPs to signaling point B, to prevent B from sending traffic destined to A back to D and E (circular routing).

		The route from signaling point C then becomes available. All messages destined for signaling point A can now be routed through the primary route, signaling point C. To initiate this, a transfer-allowed message is sent to signaling points D and E (Figure 6.21).

		Signaling points D and E then initiate the controlled rerouting procedures. To prevent circular routing, signaling points D and E send a transfer-prohibited to signaling point B (Figure 6.22). This prevents signaling point B from sending messages destined for signaling point A.

		A timer T6, "Delay to avoid message missequencing on controlled rerouting," is set and, after its expiration, the controlled rerouting buffers at signaling points D and E are transmitted to signaling point C (Figure 6.23).

		MTP Restart

		The MTP restart procedure (Figure 6.24) is a new addition to the Bellcore standards, even though it has been in the ANSI publications for awhile. The purpose of this procedure is to protect the network and a signaling point in the event that a signaling point becomes isolated for a period of time and then becomes available.

 

		Figure 6.23 After T6 expires, MSUs resume on the links to signaling point C.

		Figure 6.24 The traffic-restart-allowed (TRA) and the traffic-restart-waiting (TRW) messages are used with the MTP traffic restart procedures. There is no information provided other than the management message.

		When this occurs, the signaling point must exchange a great deal of routing status with its adjacent signaling points. The failed signaling point, because of the length of time it was out of service, may not have current routing status. Events involving adjacent signaling points may have occurred while it was isolated and, because no messages were routed to the signaling point, it cannot be aware of congested signaling points or other inaccessible signaling points.

		To ensure that the signaling point has ample time to update its routing status information and exchange information with all of its adjacent signaling points, the MTP restart procedure is implemented with a set of timers. The timers ensure that the signaling point has ample time to retrieve routing status on each linkset or route.

		There really are no set rules for when an MTP restart procedure should begin. One suggestion by Bellcore is to start the procedure upon receipt of a LSSU with a value of processor outage (SIPO).

		There are two levels of MTP restart: a full restart and a partial restart. It is up to the management functions at level three to determine which is implemented and under what conditions. This is network dependent and can be implemented in a number of conditions.

 

One of the suggestions by Bellcore for initiating this procedure is that, when a route becomes available after a remote processor outage, the route initiates a restart procedure. This procedure at the remote end of the route involves the use of timers (T25 and T28), which are initiated upon receipt of the first link status of in-service (determined by level two).

		When a partial restart is initiated at the isolated signaling point, it sends out a TRA message to its adjacent signaling points. The remote signaling points can then initiate their own restart procedures on the direct routes to this signaling point, as specified in the ANSI and Bellcore standards. This procedure involves the use of timers T25 and T28 (as previously mentioned).

		If a full restart is required, then timer T27, "Minimum duration of unavailability for full restart," is started. This timer is used to ensure that all adjacent signaling points see the unavailability of the routes leading to this signaling point and have ample time to respond. During the duration of T27, the isolated signaling point sends level-two processor outage messages to its adjacent signaling points using the Link Status Signal Unit.

		After expiration of timer T27, the signaling point then attempts to place predetermined links back into service. The primary link of each linkset should be the first to be restored. To expedite the alignment procedure on these links, the emergency alignment procedure is suggested for the first links within the linksets.

		Once these links have been brought back into service, route management messages can be exchanged. The route management messages will enable the isolated signaling point to determine current status of all direct routes. While the in-service links are exchanging route status information, the other links can begin their alignment procedures.

		When the first link in a linkset goes into service, timer T22, "Timer at restarting signaling point waiting for signaling links to become available," and timer T26, "Timer at restarting signaling point waiting to repeat traffic restart waiting message," are started. Timer T22 is stopped when sufficient links have become available ("sufficient links'' is a network-dependent parameter). If T26 expires, a TRW message is sent to all adjacent signaling points. Timer T26 is then restarted. This timer (T26) ensures that enough time is allowed for the procedure to be completed. Timer T26 is stopped upon the expiration of several other timers, depending on the events taking place.

		There are many other timers and events that take place during the MTP restart procedure. The intent here is to give you an idea of what this procedure tries to accomplish. Without this procedure, each link is left to its own accord, and the alignment procedure is begun on a link-by-link basis.

		When the links are left to their own devices to get restored, there is no orderly fashion in which routes are reinstated. This procedure brings more order to the alignment procedure and the procedures which take place when an entire signaling point has been isolated.

		Management Inhibiting

		Management inhibiting is used by link management to block a signaling link from level four. The status of the link does not change at level two. The purpose of this procedure is to allow personnel to send test messages over the inhibited link, or to allow link management to send test messages over the link without interference from any of the user parts.

		However, inhibiting a link is not permitted if the signaling point is under a congestion status or if there are no other links available. If the link being inhibited is the last available link, the procedure is denied. If a signaling point should suddenly become isolated (due to other link failures) or if all other links within the same linkset as the inhibited link should become unavailable, inhibiting is canceled and the link is returned to normal service.

		If no other links fail and the inhibit procedure is uninterrupted, only the originator can uninhibit the link. The link inhibition can be initiated either through a command entered at a system terminal or by network management.

		The link is inhibited by sending an inhibit request to the remote signaling point. This informs the remote signaling point that the originator wishes to inhibit the link and the remote signaling point should mark the link as inhibited. If, for any of the reasons here mentioned, the link cannot be inhibited, the request is denied.

		To ensure that the link shows as inhibited at both ends of the link, both signaling points periodically send test messages to check the status of the link at the adjacent signaling point. This is accomplished through the inhibit test message.

		During the time the link is marked as inhibited, the local signaling point sends a local inhibit test message. This is to ensure that the link status in the remote signaling point is still shown as inhibited. If the remote does not acknowledge the local inhibit test message, the procedure begins again, with an inhibit request. The local signaling point must first force an uninhibit of the link before inhibiting the link can start.

		Likewise, the remote signaling point will also periodically send a remote inhibit test message. If the remote inhibit test message does not get an acknowledgment, the link status at the remote signaling point is changed to available (through a forced uninhibit) and traffic is allowed on the link. These two test messages ensure that both ends of the link are aligned properly and show the same status. A signaling point is allowed two attempts at inhibiting a link.

		When the inhibit link message is received by a signaling point, the receiving signaling point initiates a changeover, diverting traffic away from the link onto other links within the same linkset or other linksets. If the signaling point receives an inhibit message, the link is marked as remotely inhibited.

		The originator of the inhibit marks the link as locally inhibited. A changeover procedure is initiated to divert traffic to other links. The local signaling point uses the time diversion changeover procedure.

		If the local signaling point has not received an acknowledgment to its inhibit message within timer T14, "Waiting for inhibit acknowledgment," the procedure is started again. Two consecutive attempts are allowed. If the signaling point is still unsuccessful after two attempts, the inhibit procedure is aborted and the link remains available for traffic.

		Inhibiting a link is usually a manual procedure, used by maintenance personnel for testing the reliability of a link. Test messages with specific patterns can then be exchanged over the inhibited link and checked for accuracy. The signaling point has the responsibility for ensuring that the inhibited link does not remain inhibited after testing is complete (caused by lost uninhibit messages never received by remote signaling points) and that the inhibited link is not the last available link to another signaling point.

		Flow Control

		Flow control at level three is used to control the flow of user part messages from the source. Much about flow control is implementation dependent. The procedures implemented for congestion or unavailable user parts are dependent on the manufacturers of SS7 equipment. The standards only define the need for such procedures and make suggestions as to how they can be addressed.

		The intent of these procedures is to deal with congestion at the source, where the messages are being generated. This, of course, is at level four-user parts. The protocol has no interaction, really, at this level, because these are internal functions. However, the protocol does trigger these internal functions.

		If a transfer-prohibited message is received for a particular destination, level three will interact through network management with the protocol and will direct level four as well. Communications from the protocol to these internal functions are accomplished through the use of primitives, which were discussed in Chapter 5.

		The primitives offer a structured communications format to interact with other levels. In the case of flow control, level three must be able to notify level four of a congestion condition at another signaling point. The result is a reduction in traffic being generated for the affected signaling point.

		The advantage to this is twofold. Only the user part experiencing the congestion is affected, rather than the entire signaling point. The congestion flow control is directed at a specific user part (such as ISUP) rather than an entire signaling point. This allows other traffic to continue without impedance.

		The other advantage is that congestion is dealt with at the source, rather than by trying to redirect messages around the congestion. If a particular node is causing congestion, the amount of traffic generated by that node is throttled, instead of redirecting all that traffic to another destination.

		There are procedures invoked by route management at level three which also deal with congestion conditions; however, they deal with signaling point congestion. Route management does not communicate with the source, the user parts, directly. Traffic management deals with the source.

		The MTP uses traffic management flow control to deal with traffic destined to a user part that has become unavailable. This is from the perspective of the receiver, rather than that of the source.

		If a MSU is received by the MTP, and the message discrimination function has determined that the MSU is addressed to the local signaling point, the message is sent to message distribution to be given to level four. However, if message distribution is unable to give the message to level four because of a congestion condition, or because the user part at level four is not available, traffic management MTP flow control is invoked to inform the originator of the problem (Figure 6.25).

		An example of how this could occur is best explained using the feature of global title translation. Global title translation is performed by a STP when it receives a Signaling Connection Control Part (SCCP) message with a called party address that contains only digits.

		These digits are referred to as global title digits. The digits are typically nonroutable (that is, 800 number or 900 number). The SCCP must deliver the message to a user part (SCCP in this case) at the receiving signaling point for the global title translation function. If the processor dedicated to that function has failed, there are no resources available to perform the global title translation.

 

		Figure 6.25 The user part unavailable (UPU) indicates that a user part is not accessible at the specified destination. The user ID is the same value as that provided in the SIO field.

		The signaling point in this case would return a user part unavailable message to the originator of the message indicating that the message processing could not be completed because the necessary resources are not available to perform the function.

		In Figure 6.25, the user part unavailable message provides the destination point code (the point code of the failed user part), the user part that is not available (SCCP, ISUP, etc.), and the cause. The MTP user code is the same code used in the service indicator octet of the MSU.

		There are only three causes today: reason unknown, an unequipped remote user part, or the remote user part is inaccessible. The condition for each of these causes is purely implementation dependent and may have different meanings in different networks.

		In the event that traffic management should create a routing problem to any other signaling point, the routing management function at adjacent signaling points will be invoked. Likewise, if a signaling point that has invoked traffic management has lost a route to a destination, it will also invoke routing management to resolve routing issues. Route management is described in the following section.

		Routing Management Procedures

		Routing management is used by a signaling point to notify its adjacent signaling points of a routing problem. The routing problem is usually attributed to the loss of a signaling link or linksets, which together comprise a route.

		The purpose of routing management is to redirect traffic around the failed route. This is accomplished through the use of transfer messages, which identify the failed destination by point code and instruct receiving signaling points on how to react (Figure 6.26).

 

		Figure 6.26 Both the transfer-prohibited (TFP) and the transfer-cluster-prohibited (TCP) work in much the same way. The TFP identifies a single entity, while the TCP identifies a cluster of entities.

		When a network is using cluster addressing, cluster routing management can also be invoked. In cluster addressing, each STP is assigned a unique cluster address. All of the signaling points that "home" to that STP are assigned the same cluster address, with unique member addresses (Figure 6.27).

		This allows routing management cluster messages to be sent to an STP and distributed among all of its cluster members. The advantage of cluster routing management is that one message can be sent to address an entire group of signaling points, rather than individual signaling points.

		In addition to cluster routing, all networks must use some prioritizing on their routes. This is typically done by weighting each route in order of efficiency (Figure 6.28). For example, all signaling points will have a primary route. The primary route (one for every destination) is the fastest path to the destination. Therefore, it is considered the most efficient.

		In addition to the primary route, there should also be a secondary route, which is not the most favorable path but provides an alternative in the event that the primary path should fail. This is not the best path, but it will get messages to the same destination.

		Additional routes are weighted in similar fashion. The more paths provided, the more reliable the network. The objective is to provide diverse routes to the same destination so that, in the event that a major failure should occur, messages can still be routed to their destinations.

		When a route fails, a routing management message is sent to adjacent signaling points to advise them that the originating signaling point can no longer reach a destination through its routes, and an alternative should be selected ("Do not send to me, because I can't get there"). For normal routing management, the following messages are used:

 

		Figure 6.27 In this figure, the group of SSPs that share the same home STP have the same cluster address. Network management messages can then be sent from the home STP concerning status of the entire cluster. Signaling traffic can also be routed by cluster address rather than by the entire point code.

		Figure 6.28 In this example, A1 is a primary route to destination F, while A2 is the alternate route. For signaling point B, B1 is the primary route to F and B2 is the secondary route, while B3 is an alternate route.

 

Transfer-prohibited (TFP)

		Transfer-allowed (TFA)

		Transfer-restricted (TFR)

		Transfer-controlled (TFC)

		Signaling-route-set-test (RST)

		Signaling-route-set-congestion-test (RCT)

		During cluster routing management, the following messages are used:

		Transfer-cluster-prohibited (TCP)

		Transfer-cluster-allowed (TCA)

		Transfer-cluster-restricted (TCR)

		Cluster-route-set-test (CRST)

		These messages and their accompanying procedures are explained as follows.

		Transfer-prohibited (TFP)

		The TFP message (H1 heading code 0001) is sent by a signaling point when it determines that it can no longer reach a destination (adjacent signaling point). The reason for the isolation is due to the loss of an entire route, which connects directly to the affected destination.

		The message will provide the destination point code for the affected signaling point. This allows adjacent signaling points to determine which alternate route to select to reach the affected destination.

		In Figure 6.29, signaling point D can no longer route messages to signaling point F. A TFP is sent to signaling points B and C to advise them to select an alternate route. When signaling points B and C receive the TFP message, they stop transmission of all MSUs to the concerned signaling point (D) with the address of the affected signaling point (F) until an alternate route is determined. Once the alternate route has been determined, MSUs are transmitted via the alternate route to the affected destination (F). Any traffic generated at signaling point D destined for signaling point F is sent to signaling point B or C for routing to signaling point F.

		This is a very simple example. Depending on the network configuration, this procedure can involve very little rerouting or a lot of rerouting. The objective in any routing plan is to keep all routing as direct and as simple as possible.

 

		Figure 6.29 In this figure, D can no longer send MSUs to F. A TFP is sent to B and C, to prevent them from sending traffic for F to D. If D gets any traffic from other signaling points, the traffic is sent to C for routing to F.

		When the failed route becomes available again, a transfer-allowed message is sent to all adjacent signaling points by signaling point D, and normal routing is resumed.

		Transfer-cluster-prohibited (TCP)

		Like the TFP message, the TCP message (H1 heading code 0010) is sent by a signaling point to a cluster of signaling points. Each STP is assigned a unique cluster address, while all signaling points which home to the STP have the same cluster address as the STP, but use unique member addresses.

		As seen in Figure 6.30, the home STP sends a TCP message concerning all of the signaling points that are "homed" to the STP. This allows one message to be sent regarding the entire cluster, rather than numerous messages sent by each signaling point in the cluster.

		Transfer-allowed (TFA)

		The TFA message (H1 heading code 0101) is used when a route becomes available again. This is sent by the originator of a TFP message to indicate that traffic may be sent once again to the affected signaling point.

		The message structure is the same as the TFP. When received, the TFA should trigger a changeback to occur on the concerned link.

		Transfer-cluster-allowed (TCA)

		The TCA message (H1 heading code 0110) is used to indicate the route to the specified cluster is now available. This is sent by the originator of a TCP message to indicate that traffic may now be sent to the affected cluster point code.

 

		Figure 6.30 In this example, the STP 246-2-0 has failed and cannot reach any of the signaling points that home to it. A TCP message is sent to indicate this condition and cause routing to be forced to STP 246-2-1.

		Figure 6.31 The TFR message is used to restrict traffic flow. In this example, a link from A to B has failed, leaving only one link available. A changeover has occurred, and a TFR has been sent by the STP to all of its adjacent signaling points.

		Transfer-restricted (TFR)

		The TFR message (H1 heading code 0011) is sent by a STP when it is determined that messages to a particular destination should no longer be sent to the STP for routing to the affected signaling point (Figure 6.31). The TFR is always sent to adjacent signaling points.

		In the event that a signaling link to the affected destination experiences a long-term failure (such as a processor outage), the STP receives a changeover from the affected signaling point, ordering all traffic to be diverted away from the link at fault.

		The STP may then determine that it is necessary to send the TFR to all of its adjacent signaling points to prevent traffic from being addressed to the STP for routing to the affected signaling point.

		The restriction does not prevent messages from being transferred from the STP entirely, however. The restriction prevents normal traffic flow, and forces other signaling points to find an alternate route for traffic destined to the affected signaling point. If there are no alternate routes available, then the traffic can still be routed through the STP normally.

		In this previous case, the TFR is sent using the broadcast method. The broadcast method automatically transmits the TFR when the link has been determined to have failed.

		When a significant number of links in a linkset fail, a TFR is sent to adjacent signaling points using the response method. The response method sends the TFR when a MSU is received on a link for transfer to the affected signaling point.

		The criterion for sending a TFR message under these conditions is implementation specific. The objective is to restrict traffic to the signal transfer point on the linkset that has experienced link failures before congestion occurs. Congestion can occur at both the link level and the user part level.

		If a signaling point was previously prohibited and links become available, the signaling point would be considered restricted and TFR messages would be sent to all adjacent signaling points until the signaling point was 100 percent in service again. This means that all signaling links to the affected destination would have to be in service.

		There are cases when traffic on an alternate route would be diverted via the controlled rerouting procedure to the restricted route. This should occur only when the restricted route has a higher priority than the alternate route. The priority of a route is set by an administration command at each signaling point.

		In the event that both routes should be of equal priority and both are restricted, then load sharing should be implemented to distribute traffic evenly over both routes. This ensures that links are carrying an even amount of traffic, and one link does not become burdened with all the traffic from the failed route.

		Transfer-cluster-restricted (TCR)

		When several routes within a cluster fail or become congested, the TCR message (H1 heading code 0100) is used (Figure 6.32). This message indicates to an adjacent STP that the concerned cluster should not be routed any messages if possible.

 

		Figure 6.32 This is the message structure of a TCR message.

		Figure 6.33 Two signaling links to STP 246-2-0 have failed. The failure of these signaling links triggered a TCR to be sent to the adjacent STPs.

		In Figure 6.33, the signaling points attached to STP A have the same cluster address as STP A. This means that STP A is their ''home" STP. In the event that one or more routes within this grouping of signaling points should become unavailable, STP A would send a transfer-cluster-prohibited to any adjacent STPs. This allows control over the traffic to the signaling points attached to STP A and any of its concerned signaling points. The same rules apply to the TCR as the TFR.

		It should be noted that not all networks use cluster routing. Cluster routing is a network management feature and is not implemented for normal message routing. However, partial point code routing can be used for normal routing of all messages through the network. If partial point code routing is offered within a network, then, most likely, cluster routing is also implemented, since the two are closely related.

		Signaling-route-set-test (SRST)

		This message is used to test the status of any prohibited or restricted route. When a TFP or TFR is received by a signaling point from an adjacent signaling point, a timer T10, "Waiting to repeat signaling-route-set-test message," is automatically activated (Figure 6.34). The following H1 heading codes are used in this message:

0 0 0 1	Signaling-route-set-test signal for prohibited destination
0 0 1 0	Signaling-route-set-test signal for restricted destination
0 0 1 1	Signaling-route-set-test signal for prohibited cluster
0 1 0 0	Signaling-route-set-test signal for restricted cluster

		At the expiration of timer T10, the SRST message is sent to the originator of the TFP or TFR (this also applies to TCP and TCR messages). When the SRST is sent, the timer T10 is reset.

		The SRST message is retransmitted after every expiration of timer T10, until a transfer-allowed has been received by the testing signaling point. This procedure is used to ensure that a prohibited or restricted signaling point does not get stuck in that condition indefinitely. The message contains the status information (from the perspective of the originator) for the concerned signaling point, as well as the heading code. No other information is necessary.

		Another use for this message is when a link becomes available, but traffic is not restarting. Notification is given by level two (LSSU) that the link has started the proving period. The adjacent signaling point receives this status and also begins the proving period. After the proving period has ended and no other indications of failure are received, the link should be considered available.

		Figure 6.34 The message structure of SRST messages is shown in this figure.

 

		However, only the signaling point that initiated the proving period can restart traffic on the link. The adjacent signaling point typically waits until receipt of a MSU. The adjacent signaling point should then send the SRST message to determine if the route has become available. The message would then be transmitted every T10 until either an MSU is received or the status is indicated by level two.

		In the event that a SRST message is sent to a previously restricted cluster, the receiving STP (considered the home STP for all other signaling points in that cluster) will compare the actual status of the cluster with that indicated in the message. If the status of the cluster is not prohibited or restricted, the home STP will send a TCA back to the originator of the SRST message. The originator of the SRST then updates its status indicator for the cluster as available, and allows traffic to be routed to the concerned STP. This procedure prevents a cluster from erroneously being marked by a signaling point as unavailable or restricted when a TFA or TCA message is lost.

		If the cluster is not available and there are any signaling points within the cluster that are in danger of becoming congested, then the TCR message is sent to the originator of the SRST message. This prevents further congestion from forcing the signaling point into a busy condition.

		Transfer-controlled (TFC)

		The TFC message (Figure 6.35) is sent by a STP when it receives a MSU destined for a route that has been marked by the STP as congested. The TFC is addressed back to the originator of the MSU.

		In Figure 6.36, a signaling point has sent a message signal unit to a STP, to be routed over any available route to the destination addressed in the routing label. The STP determines that the route for that destination is congested and there are no other routes to the destination.

		Figure 6.35 The structure of the TFC message.

 

		Figure 6.36 The link between C and E has failed in this example. As a result, the link from C to D has become congested. MSUs sent by A to C are discarded, and a TFC is sent by C to A.

		When the MSU is received on a signaling link, level-three routing must determine which route to send the message out on. If the only route is congested, level-three network management will discard the message and send the transfer-controlled back to the originator of the MSU. The TFC should be generated by the link on which the message came in, rather than using the same processor showing the congestion. In other words, if resources are showing a congestion status, sending them additional work compounds the problem. Implementation of this procedure will differ from system to system, but the overall objective is the same. Reduce the traffic to the congested route.

		The reduction is accomplished by returning a congestion status code in the TFC message. The congestion status indicates the priority level a message must possess before it will be routed over the congested route. Only messages of a higher priority than indicated in the congestion status field will be allowed on the congested route.

		The priority is determined by the individual signaling point. Each signaling point must assign a congestion status level to a route. The status is a two-bit code, providing for a status level of 1, 2, or 3 (0 indicates no congestion). When a MSU is received by an STP and is routed to the congested route, the network indicator field of the service indicator octet is examined to determine what priority has been assigned to the received message.

		Priorities are assigned by the originating signaling point. This coding is implementation dependent. It can be an administrable value, or automatically assigned based on configuration of the signaling point. Regardless, in ANSI networks, this field determines whether or not a message will be allowed to pass through a congested route, based on the congestion level of the route.

		If we examine the network indicator field, there are two spare bits associated with the national network indicator. They can have values of 0, 1, 2, or 3 (which correspond with the congestion-level values). The MSU must have a priority value equal to or greater than the current congestion level of the congested route.

		In addition to indicating the affected destination point code (the affected point code is the one that is adjacent to the STP and the congested route) is the current congestion status of the route. This allows the signaling point that originated traffic towards the destination to determine which type of messages it can send. If it has any messages to transmit that have a priority less than the congestion status indicated in the TFC, then the messages are not sent. This prevents the STP from receiving unnecessary messages that will have to be discarded.

		Messages received by the STP for a congested route are not processed and are not returned. They are simply discarded, and the TFC message is sent in the backward direction to indicate that they have been discarded. The only time the TFC is sent is when a message has been discarded because of a congested route. If the MSU has a priority equal to or higher than the congestion level, the message is allowed to pass through the route to its destination and no TFC message is created.

		It should also be noted that if a signaling point received a TFC message, and it determined that another route is available to the same destination, than it can choose another route to the destination. In this case, the signaling point would mark the route on which it received the TFC message as congested, and would invoke routing management procedures.

		The TFC message is sent on a regular basis to update the originating signaling point of the congestion status. If timer T15 expires within the originator of a MSU, and no TFCs have been received within timer T15, the signaling-route-set-congestion-test procedure is invoked to determine if the route is still congested.

		The signaling-route-set-congestion-test procedure is explained in full detail in the next section. The concept is to send a message (the test message) with a priority value one less than what the originator thinks the congestion status is. If the route is still congested, the receiving STP will send a new transfer-controlled message indicating the congestion level.

		If the signaling-route-set-congestion-test message gets through and a timer T16 expires, then the route is considered congested but at a lower congestion level than the test message. The signaling-route-set-congestion-test (RCT) message is sent again with a lower priority, and the procedure is repeated until the route is found to be at level 0 (no congestion).

		Signaling-route-set-congestion-test (RCT)

		In the event that a signaling point receives the TFC message, it needs to periodically verify that the indicated route is still under TFC procedures. There are no indications sent by the originator of the TFC message that the route is no longer under TFC procedures.

		If we look at the big picture of what is happening during this procedure, we can see multiple tiers of network management. Procedures have been invoked at the link level, which only involves two signaling points directly adjacent to one another.

		Traffic management is diverting traffic away from the affected signaling link, but, again, only between two adjacent signaling points. This sometimes may trigger the routing management procedure, which involves adjacent signaling points of an STP undergoing any one of the previous procedures.

		The TFC procedure, on the other hand, is sent to any signaling point which originates a MSU and is received by the concerned signaling point. Without keeping track of every TFC message sent and the destination of each message, it is not feasible for a signaling point to inform another signaling point that it is not adjacent to of the changed congestion status during the TFC procedure. For this reason, the responsibility is placed on the receiver of the TFC message to continuously monitor the congestion status of a route to determine when the status has changed. This is accomplished through the use of the RCT message.

		The receiver of the transfer-controlled must send out the RCT message at the expiration of level-three timer T15. This timer is set when the TFC message is first received. When the RCT message is sent, the timer is reset.

		The message is sent using the structure shown in Figure 6.37. The test message provides only the H0/H1 heading code, indicating the type of test message. The MSU, however, carries the priority level of the concerned congested link. In other words, the congested route is considered congested at a specific level, which is determined by the concerned signaling points.

		This congestion level, as discussed before, corresponds to the priority of a MSU. In ANSI networks, the priority of an MSU is indicated in the service indicator octet subservice field.

		The idea is that the MSU should be sent at the same priority level as the congestion status of the concerned route. If the test message is passed through the concerned signaling point towards the affected destination, then, obviously, the status of the route has changed. However, there is no indication as to what the current congestion level is (Figure 6.38).

 

		Figure 6.37 In this example, signaling point C is under congestion. Signaling point A has already been notified by a TFC message of the congestion status. The SRCT message is sent with a priority one less than the actual status of the route.

		Figure 6.38 The SRCT was received, but because the congestion level has not changed, the SRCT was discarded. A TFC is returned to the originator (A) indicating the current congestion level.

		If the congestion status has not changed, and the MSU carrying the RCT message is received, the message will be discarded by the receiving STP and a TFC message will be returned to the originator of the test message indicating the present congestion status level towards the affected destination.

		Remember that the MSU must have a priority equal to or more than the congestion status level. With every transmission of the RCT message, the MSU priority is set one less than the perceived value of the concerned route. For example, if the congestion status is determined to be at level three, only MSUs with a priority of three will be passed through. The message is sent with a priority that is one less than what the originator thinks the congestion level is, based on the last TFC message received.

		If the congestion level has not changed, the test message is discarded, and a TFC message is returned. If the congestion status has changed, the MSU is passed on to the destination. There is no indication or acknowledgment that the message was received and routed to the affected signaling point.

		To determine when a test message has been allowed to pass through the concerned route, the originating signaling point of a RCT message sets timer T16. At the expiration of timer T16, if no TFC message has been received, it can be assumed that the test message has been passed on to the affected signaling point, and the congestion level has changed.

		There is still no indication of what the new congestion level is. When the timer T16 expires, another RCT message is generated, with a priority one less than the previous test message. This new test message is sent once every T15, until the congestion status has changed, and the timer T16 expires with no receipt of a TFC message (see Figure 6.39).

		This procedure continues until the congestion status has abated and the route is considered at congestion level zero. The congestion level is not defined by Bellcore, but by each individual signaling point. This means that the congestion levels are implementation dependent, and there are no rules as to what constitutes a level-three congestion status versus a level-one congestion status.

		The ANSI and Telcordia standards do indicate what type of messages should be allowed during the various congestion levels. These can be found in Telcordia publication T1.111.5. The rules state that any network management messages sent by level three should always have a priority of three. This, of course, is the highest priority available, and ensures that network management messages always reach the affected destinations, despite the congestion status.

		Any messages that are related to future connections, that is, voice circuit connections which have not yet been established, must have less priority than those messages related to existing connections. This is done to ensure that present connections are maintained properly, and any messages related to present connections can be routed through the network. Any new connections would then be based on the network's ability to route those requests through the congested route.

		Figure 6.39 When the congestion level has decreased, eventually an SRCT will be accepted. The timer T15 triggers the transmission of SRCT messages.

 

		These messages should carry a priority of zero or one, being of a much lower priority than the existing one. This prevents new connections from being established during congestion periods, requiring more processing than what is available. This, of course, only impacts the congested route and does not prevent these connections from being established using other available routes, if any are available.

		Any message sent in response to another previously received message, such as an acknowledgment, should be of the same priority as the request. For example, if a request was sent to a signaling point for information relating to an existing connection, the response should have the same priority as the request. This also ensures proper maintenance of existing connections and prevents messages from being lost and affecting these connections.

		Any large messages should also be given low priorities. A large message requires additional processing resources, which adds to the congestion level of the route. This should be avoided whenever possible. What constitutes a "large" message is implementation specific.

		The entire concept is to prevent additional processing requirements on a congested route from taking the link out of service. The route needs to be able to finish processing the connections it is already servicing, and should be able to return to a normal state within a reasonable time if network management is successful in controlling the traffic flow to this route.

		Network Maintenance Procedures

		The procedures previously described are used by the network to maintain the reliability of the SS7 network. Usually, there is very little that can be done by service personnel during any of these procedures, because the network is maintaining the status and invoking these procedures autonomously. There are occasions, however, when the network may not be successful in returning routes and links to service, requiring the intervention of service personnel.

		This section will explain the big picture in network management, showing a variety of events taking place at all levels. The objective of this section is to show all the events that may take place during a failure or congestion, so that readers may have a better understanding of what is taking place and what to watch for in their own networks.

		It is not the purpose of this section to prescribe any procedures that should be taken in the event that a failure or congestion is experienced, because this will be dependent on your own company's maintenance procedures and the equipment used with the network. Understanding what is happening will assist you, however, in determining the next course of action.

		Congestion Management

		At the physical layer, maintenance will depend on the type of interface used. For example, if the interface for a link is a V.35, the testing procedures will be different than for a DS0 interface. Regardless of the interface type, this is usually the best place to start troubleshooting any transmission troubles.

		The use of various test tools can aid in troubleshooting a link and can help determine what type of tests need to be run. The types of test equipment vary, depending on the type of interface and the sophistication required. A transmission analyzer looks at the transmission from the perspective of the physical layer and does not perform any protocol analyzing.

		When a high-level view is needed, a protocol analyzer can aid in detecting both transmission problems and protocol problems. A protocol analyzer will decode all layers of the protocol, and allows a maintenance technician to determine at which level the error occurred. Since most troubles in the SS7 network are at the physical layer, the protocol analyzer will not be of much use to someone in the field or in the central office. The protocol analyzer is best suited for the remote maintenance center, where messages can be monitored from and to all points in the network.

		At the various exchanges, a transmission tester is best suited for troubleshooting link troubles under the direction of the remote maintenance center. When a transmission test is performed, the technician is testing the facility for its ability to send and receive bit streams to the other end of the link without error.

		No addressing or other protocol functions are needed with this type of testing because the test is being performed between two entities. The purpose of such a test is to check the integrity of a signaling link. The SS7 protocol will also be checking the link integrity whenever the link is active.

		In the event that the protocol takes a link out of service, maintenance personnel may be required to test the link and isolate the fault. This is not always the case, however, since most failures on digital facilities such as DS0s are clock oriented and can be resolved through the diagnostics of the protocol.

		The procedures used for testing at this level are company dependent. The only suggestion here is to check each link before placing it into service, to alleviate any obvious problems that may occur when turning up a signaling point for the first time. Once the link has been placed into service, there should be a minimal amount of problems.

		The SS7 protocol, as we have already seen, uses a hierarchical approach to network management. As we have discussed all through this chapter, there are three levels of network management:

		Link management

		Traffic management

		Route management

		Even though we have already discussed these procedures in full detail, we haven't looked at the whole picture during a link failure or during congestion of a route. Let's look first at a congested route and what events could take place.

		In Figure 6.40, the signaling point D has been notified of a busy condition on one or more of the links towards signaling point F. One of the links at signaling point F has experienced a busy condition. This occurs when too much traffic is sent over one link, and the processor used by that link cannot handle all of the traffic. When this occurs, the link management software initiates a LSSU with a condition of busy. The LSSU is sent by level two under the direction of level-three link management. The LSSU is sent every T5 (level-two timer), for a period of T6.

		During the period in which this link is under congestion, it can still send MSUs, but it will not accept any from its adjacent signaling point. In fact, signaling point F, in this example, will hold all acknowledgments and negative acknowledgments until the congestion subsides.

		Timer T6 prevents the link from remaining in a busy condition for too long. When this timer expires, the link is removed from service and the alignment procedure is started. In this example, the link was still in congestion mode when T6 timed out. The link was failed and the level-three link management software began the alignment procedure (recovery).

		Figure 6.40 This figure shows a couple of activities. Congestion has occurred on the linkset from D to F. In this figure, the single line represents multiple links. A TFC is sent to indicate congestion. Meanwhile, one of the other links has become busy, prompting the LSSU with status indication of busy (SIB).

 

		Because there are only two links to signaling point F, the failure of one of these links has created a problem. Traffic must now be diverted away from the failed link onto the adjacent link within the same linkset. However, this link is already near capacity and adding the load of another link will possibly create a congestion condition on this link as well.

		Level-three link management places the link out of service by initiating the LSSU of ''out-of-service" towards signaling point D. This is done to ensure that signaling point D does not send any traffic onto the failed link. The link may be very capable of sending traffic, but signaling point F cannot process it. In fact, the link, in this case, must be able to carry traffic, because the LSSU is sent on the same link for which it represents status.

		This brings up a good point. When a link is failed, the link is not always at fault. When we speak of a link failure, the link processor at either end is included as part of the link. So even though the link itself is perfectly fine, the processor at either end or the interface card at either end could be at fault.

		The LSSU is used at level two to inform the adjacent signaling point of the status of the link at the other end, so that both signaling points can be in synch during the diagnostics phase. Once the link has been removed from service (by transmission of the LSSU "out-of-service"), the signaling point F sends another LSSU with a status of out-of-alignment. This indicates that the link is no longer aligned and cannot be used to carry messages, other than level-two messages.

		The next LSSU to be sent carries the status of "normal alignment," indicating that the processor at signaling point F has begun the normal alignment procedure and signaling point D should do the same.

		During the proving period, Fill-In Signal Units (FISUs) are sent from signaling point F to signaling point D. These FISUs are monitored for errors using the alignment error rate monitor (AERM) during the proving period, which is usually around two or three seconds.

		If there are more than four errors during the proving period, the link is failed and the alignment procedure begins all over again, beginning with the LSSU of out-of-service. This procedure will continue until the link has been returned to service, or until level-three link management removes it from service entirely.

		While the FISUs are being sent between the two adjacent signaling points, traffic must be diverted away from the failed link. This actually begins before the link begins the alignment procedure. This is initiated by level-three traffic management. The purpose is to notify the adjacent signaling point that all traffic that was destined for the failed link must be rerouted to a new link. The traffic management message will also instruct signaling point D which link to use.

		Normally, this would not be necessary. However, both ends of the link have a transmission and receiving buffer. These buffers hold transmitted and received MSUs until an acknowledgment is sent or received. In the case of the transmission buffer, these MSUs have been sent but have not yet received any acknowledgments.

		The traffic management at level three will first instruct signaling point F to move the contents of the failed link's transmit buffer to another link. The other link is either a link within the same linkset, or of another route to the same destination. Once the MSUs have been moved to the new buffer, traffic management initiates the changeover procedure.

		The changeover order is sent on the newly selected link, indicating the signaling link code of the failed link. This means that the link code table within the signaling point must also be modified. Every signaling point maintains a signaling link code table, which identifies the link code assignment for every link in the system. Remember that the link code is a logical assignment and does not necessarily correspond to the physical link code.

		The signaling link code (SLC) allows every link to have multiple codes. When a link is failed, the link must be removed from this table so that it is not selected by the routing function of level three. All of the signaling link codes are then reassigned accordingly.

		The receiver of the changeover message must mark the indicated link as failed, remove it from its own signaling link code table, and transfer the contents of the transmit buffer to the link on which the changeover order was received. When this has been accomplished, the link alignment procedure is able to start on the failed link. Signaling point D sends a changeover acknowledgment to signaling point F to indicate completion of the changeover procedure within itself.

		All unacknowledged MSUs can now be re-sent from the transmission buffer, and newly generated MSUs can be sent via the new link as well. This will continue until the failed link has been returned to service.

		At this point, network management has controlled the traffic between two adjacent signaling points and initiated a recovery procedure to return a link to service. No other signaling points have been informed of these activities. Unless the failed link creates congestion of the entire route, there is no need for further action. Let's see what would happen, however, if the condition did not change and congestion was to occur on the route.

 

		Figure 6.41 In this example, a link to signaling point F has become congested. Since this link is part of a route to F, the route congestion procedure is invoked.

		In Figure 6.41, signaling point D has been diverting traffic under the direction from signaling point F to another link. However, signaling point D only has two links in its route to signaling point F. With one link carrying all of the traffic, signaling point D has become congested over that route. This does not mean that signaling point D is under congestion and cannot accept messages, but that messages destined for signaling point F cannot be sent through signaling point D without some method of controlling the throughput of these messages.

		There are two methods used for controlling messages in this situation. Route management is primarily responsible for rerouting traffic away from a congested signaling point (or signaling point with congestion on one of its routes). At the same time, route management can also throttle the amount and type of MSUs sent to a specific destination. We will look at both of these procedures.

		When signaling point D determines that the route has reached a predetermined threshold (usually determined by some configurable percentage, assigned at deployment time), the signaling point sends a TFR message to all adjacent signaling points. The TFR indicates a congestion condition to a given destination. Only the destination point code is given in this message. The receiving signaling points (signaling points B and C in this example) must then determine which alternate routes they will use to route messages to destination F.

		Remember that signaling point D is not the affected signaling point. Signaling point D is simply a relay station for messages destined to signaling point F. The signaling point is not congested just its route to signaling point F. Only messages destined for F are affected. All other messages can be sent to signaling point D with no impact, since they are not routed over the congested route.

		The TFR indicates that messages destined to signaling point F should not be routed through signaling point D. This does not stop signaling point D from receiving messages destined for F. If no other alternate routes are available, messages can still be routed through signaling point D to signaling point F. This could compound the problem of congestion if too many messages were being routed to D.

		When signaling point D receives a MSU addressed to signaling point F, it must examine the congestion level of the affected link. We are no longer talking about the failed link, since it is still tied up in the alignment procedure. The link that all traffic was diverted to has now become the problem. Signaling point D must determine the congestion level (0, 1, 2, or 3) for the link and notify the originator of any MSUs.

		Congestion levels are also implementation dependent, and can be configurable parameters based on network performance and number of links to a given destination. In this example, we will say that the signaling link has reached a congestion level of two. Level three is the most severe.

		Signaling point D will use the congestion level of the link to determine which type of messages to allow through. For example, if the congestion level is level two, only MSUs with a priority of two or above will be permitted to route through signaling point D to signaling point F. All other MSUs are discarded, and a TFC is sent to their originator.

		The TFC message is sent by signaling point D to the originator of the received MSU. Only MSUs received and discarded can trigger the TFC message. The TFC message carries with it the current congestion level and the destination of signaling point F.

		The receiver of this message then stops generation of all MSUs with a priority less than two. As discussed in the section about TFC procedures, there are certain types of messages which are allowed during this congestion status, and each type of message receives a particular priority. To review those priorities, refer to the discussion on the TFC procedure.

		To determine when the route has become available again, the receiver of the TFC message must periodically send the signaling-route-set-congestion-test (RTC) message. This message contains a priority of one in our example (since the TFC indicated that congestion status at level two). This message is re-sent every T15, until the congestion abates.

		We can now see that network management has been performed at various levels: the link level, the traffic level, and even the message-origination level. As the severity increases, so does the role of network management. In Figure 6.42, the failed link has been returned to service, and the congestion is subsiding.

 

		Figure 6.42 After testing a previously failed link by sending an SLTM, signaling point F sends a changeback declaration (CBD), which is then acknowledged (CBA). Traffic is returned to normal.

		Let's start by looking at the link again. The failed link has been through the alignment procedure and has successfully passed the alignment procedure. Before the link is returned to normal service, level three sends a signaling link test message (SLTM). This message is also configured at deployment time and carries with it a predetermined test pattern. The purpose is to ensure the ability of the link to carry level-four traffic and not just Fill-In Signal Units (FISU).

		Once the signaling link test message has been sent and successfully received, the link is returned to service. Level two does not send any more LSSUs, but does allow MSUs through the link. Actually, level three is the driver here and initiates the transmission of MSUs again. Before this can happen, a few procedures must be initiated internally.

		First, the link must be reassigned its signaling link code, so that level-three routing can select this link for transmission. Once the link has been restored in the link code table, level-three traffic management sends a changeback declaration (CBD) message to signaling point D. The buffers do not need to be transferred this time, because normal processing can continue on both links.

		To indicate the success of the CBD, signaling point D sends a changeback acknowledgment on any available link. No other action is necessary. The failed link has now been restored and traffic has been diverted back to the link. Both links are now operational. This means that the congestion condition should also be corrected.

		As the congestion level subsides, the signaling link begins processing messages of a lower priority. No indication is sent by signaling point D of the new congestion level. However, any receivers of a TFC are still sending messages. This is their only means of determining the current status of the link.

 

When the congestion level has abated, and the route is now free of congestion, the congestion level should be at level zero. Any signaling points sending messages will find they no longer receive a TFC when they send a test message with a priority of zero. They then mark the destination in their routing tables as available and begin normal transmission of signaling again.

		Throughout this whole series of events, there has been no human intervention. In fact, this whole scenario may have taken only a few minutes to complete. By the time the events were detected by personnel at the remote maintenance center, the condition could have been repaired. This is what makes the SS7 network such a robust network.

		Failure Management

		In the preceding section, we talked about the procedures that would be used to correct a congestion condition. Now let us talk about the events which could occur during a network failure. We will start at the link level and watch as the failure migrates to an entire route.

		In Figure 6.43, signaling point D has detected a failure at one of the links to signaling point F. This failure appears to be at the processor level. Level two is operational, level three is functional, but level four cannot be reached by level-three message discrimination.

		This failure affects only one link in a two-link linkset. The first event to occur is the initiation of the LSSU by level-three link management. Level-three link management instructs level two to send the LSSU with a status of "processor outage" to signaling link F. Signaling link F thinks all is well until it receives the LSSU on the failed link. When it receives this message, it holds all MSUs to prevent transmission over the failed link. Level two has done its job.

		Level-three link management must now begin the recovery procedure on the link. This entails marking the link as out of service, which initiates changing the signaling link code and beginning the changeover procedure.

		Figure 6.43 In this example, one link has failed in a two-link linkset. Level-two LSSUs are sent on the failed link, while the changeover procedure begins on the other link.

 

		Level two sends the LSSU with a status of "processor outage" to signaling point F, indicating the processor failure at signaling point D. This should be followed by the LSSU of normal alignment. However, before normal alignment can begin, the traffic must be diverted away from the failed link.

		The changeover procedure is invoked by level-three traffic management. All unacknowledged messages in the transmit buffer of the link at signaling point D are transferred to the new link (in this example, the adjacent link within the same linkset).

		When this procedure has been completed, the changeover order is sent to signaling point F providing the failed signaling link code. The changeover order, as seen in the illustration, is sent on the new link. When received, signaling point F transfers the MSUs still in the transmit buffer of the failed link to the new link. The MSUs are then retransmitted over the new link in both directions.

		To acknowledge completion of the buffer transfer and receipt of the changeover order, signaling point F sends the changeover acknowledgment message to signaling point D. This signifies that all is completed and MSUs can now be diverted to the new link.

		Now that the messages have been retransmitted and the buffers have been transferred, the link management recovery procedure can begin. This entails sending the LSSU of normal alignment over the failed link and beginning the alignment procedure. All timers and counters are set to zero, and the alignment procedure begins.

		During the diverting of traffic, the processor outage problem has migrated to the new link. This means that both links to signaling point F are now inaccessible. Levels two and three are operational, but level four is not. This requires the link management procedures to be reported on the other signaling link.

		The failure of both links has now isolated signaling point F from the rest of the network. While there is still another route available (through signaling point E), failure of E could cause a major outage.

		The link management procedure on the last link of the linkset works a little differently than it did before. Now the emergency alignment procedure is used. This is virtually the same as the normal alignment procedure, except the time is much shorter (0.6 seconds) and only one error is allowed during the proving period.

		Traffic management must now divert traffic away from the failed link and choose another alternate link. But this time, the links in this linkset are all out of service. This means that link management must choose a link within another linkset going to the same destination.

 

In this example, the other linkset is to signaling point C. The changeover order is sent to signaling point C on the linkset from D to C. All MSUs received by D for signaling point F will now be routed through C. Since we have already discussed what events occur during the changeover order, we will not go through them again here.

		Traffic is now diverted away from the failed links and rerouted to the linkset from D to C. However, signaling point D is still receiving messages destined for signaling point F. To stop messages from being sent to D for F, signaling point D route management sends a TFP message to signaling points B and C. This will prevent either signaling point from sending an MSU destined for signaling point F through D.

		Both signaling points B and C must now search for an alternate route. If there are no alternate routes, then the TFP message is sent to their adjacent signaling points to indicate that they can no longer reach the destination of signaling point F.

		Notice that signaling point B does not need to send a changeover order to signaling point C. In essence, signaling point B is diverting traffic away from one route to an alternate route. This is done through routing table states.

		In the event that either signaling point B or C becomes congested, they may enter into a TFC procedure. Hopefully, this will not occur, if both signaling points have ample links in their alternate routes.

		Now let's see what happens when the links all return to service. The failed links between signaling points D and F are restored. This means they have successfully passed the alignment procedure, and they are capable of processing level-four messages again. This is determined by level-three message distribution.

		The links must first be assigned the signaling link codes so level-three routing may select them during the routing function. Once this has been completed, MSUs can be sent over the affected links.

		The changeback declaration message must be sent between signaling points D and C. This is to indicate to signaling point C that the traffic should now be diverted back to their old routes, and all MSUs destined for signaling point F can now be routed through signaling point D. At the same time, since the route to signaling point F through D is now accessible, a TFA message is sent by signaling point D to its adjacent signaling points (B and C) to indicate the accessibility of the route.

		To prevent signaling point D from routing messages destined to signaling point F through signaling point C, both signaling points B and C may send a TFP message to signaling point D to prevent circular routing. Circular routing could occur if the route from signaling point C to F suddenly became unavailable. Messages would then be routed from D to C and then back up to signaling point B.

		Once again, very little or no human intervention is required in such procedures. Remote maintenance personnel may redirect traffic through alternate networks, especially if a two-tiered network is used. In networks of this nature, the second tier allows routing through regionally located signaling points to route around clusters or regions that may be experiencing difficulty.

		The rules for network outages in the RBOC networks are stringent. Any one interface should not be "down" more than three minutes per year. The user interface is the access from level four to level three. This means that a processor outage (which indicates the failure of the interface to level four) should not render the user part inaccessible for longer than three minutes.

		A network access unit should not be down more than two minutes per year. This includes the access to signaling points from the central office, such as the Service Switching Point (SSP). These must remain accessible all the time. Failure at any of the access points (end nodes) means telephone calls cannot be made.

		TCP/IP Networks

		When using TCP/IP for the transport of SS7, network management functions provided by level three operate somewhat differently. First of all, the network devices themselves have no visibility to MTP level three. In IP networks, these devices are routers and hubs, which use their own protocols for maintaining network reliability.

		So MTP level three network management becomes a tool for the signaling nodes themselves, to maintain virtual link reliability, and to provide alternative routing schemes should the IP network fail.

		At least one protocol used for the transport of SS7 over IP networks provides some level three functionality: the Transport Adaptation Layer Interface (TALI) developed by Tekelec and implemented by many vendors as a de facto standard. The purpose of this protocol is to emulate the network management functions of MTP level three in an IP environment, providing a much more robust alternative to IP networking than what has been proposed by other working committees (M2UA and M3UA).

		Another rather unique approach of TALI is to incorporate some of the inherent features of the IP network into signaling nodes. When devices are connected to the signaling network, they automatically "register" with other devices in the network (provided they are running TALI as well). This registration is actually analogous, with many of the IP routing protocols that routers use to update their routing tables.

		The purpose of this registration is to support network routing management in the IP environment and provide a means to route traffic around failed nodes within an IP network. The TALI protocol continually sends test messages to adjacent devices. Should an adjacent device fail to acknowledge within a specific time (determined by an administrable timer), the routing table of the node sending the test message flags the node as failed. Alternate routes are then used until the failed node becomes available again and sends a registration to all of its adjacent nodes.

		The functions of MTP level three (and in some cases even MTP level two) are still just as important when using IP links because IP networks do not have the same reliability and guaranteed service delivery that dedicated point-to-point channelized links provide. However, IP facilities do bring considerable advantages over channelized facilities, providing an equitable trade. As the standards evolve, the functions of MTP level two and three will be incorporated into IP protocols (TALI, M2UA, and M3UA).