Signaling System No.7 Protocol Architecture And Sevices part 18 doc

Signaling Message Handling
MTP3 processes all incoming MSUs to determine whether they should be sent to
one of the MTP3 users or routed to another destination. The term "MTP3 user"
refers to any user of MTP3 services, as indicated by the Service Indicator in the
SIO. This includes messages generated by MTP3 itself, such as SNM, or those that
are passed down from the User Parts at level 4 of the SS7 protocol, like ISUP and
SCCP. The term "MTP User Part" is also used, but more specifically refers to the
User Parts at level 4. When a node generates an MSU, MTP3 is responsible for
determining how to route the message toward its destination using the DPC in the
Routing Label and the Network Indicator in the SIO. Figure 7-8
shows how MTP3
message processing can be divided into three discrete functions: discrimination,
distribution, and routing.
Figure 7-8. Signaling Message Handling
[View full size image]



D
iscrimination
Message discrimination is the task of determining whether an incoming message is
destined for the node that is currently processing the message. Message
discrimination makes this determination using both the NI and the DPC.
Each node's Point Code is defined as belonging to a particular network type. The
network types are those that are specified by the NI, discussed earlier in this
chapter. An ISC will have both a National network and International type, with
Point Codes in each. Nodes that do not function as an ISC are generally identified
as a National network with a single Point Code. In some cases, multiple Point
Codes can identify a national node; for example, a network operator might use
both National and National Spare network types at a network node, with Point
Codes in each network. The NI in an incoming message's SIO is examined to

determine the network type for which the message is destined.
Each time a node receives a message, it must ask, "Is it for me?" The node asks the
question by comparing the incoming DPC in the Routing Label to its own Point
Code. If the Point Codes match, the message is sent to Message Distribution for
p
rocessing. If the Point Codes do not match, the message is sent to the Routing
function if the node is capable of routing. A Signaling End Point (SEP), such as an
SSP or SCP, is not capable of routing messages; only an STP or an Integrated
N
ode with transfer functionality (SSP/STP) can forward messages.
D
istribution
When the discrimination function has determined that a message is destined for the
current node, it performs the distribution process by examining the Service
Indicator, which is part of the SIO in the Routing Label. The Service Indicator
designates which MTP3 user to send the message to for further processing. For
example, MTP3 SNM processes a message with a Service Indicator of 0 (SNM
messages), while a message with a Service Indicator of 5 is sent to ISUP for
p
rocessing. Within SS7 protocol implementations, the Service Indicator is a means
of directing the message to the next logical stage of processing.
R
outin
g

Routing takes place when it has been determined that a message is to be sent to
another node. There are two circumstances in which this occurs. The first is when a
node originates a message to be sent to the network. For example, an MTP3 user
(such as ISUP or SCCP) generates a message for MTP3 to send. The second is
when an STP has received a message that is destined for another node. The routing

function is invoked if the discrimination function has determined that the received
message is not destined for the STP. If a Signaling End Point (SSP or SCP)
receives a message and the discrimination function determines that the message is
not for that node, the message is discarded because these nodes do not have
transfer capability. A User Part Unavailable (UPU) is sent to the originating node
to indicate that the message could not be delivered. In other words, SEPs can only
route the messages they originate. A node examines one or more routing tables to
attempt to find a match for the DPC to which the message is to be routed.
In the case where a node transfers the message, the DPC from the incoming
message's Routing Label determines the route to the destination. MTP3 uses next-
hop routing so the destination can be an adjacent node, or simply the next node en
route to the final destination. The implementation of the routing tables is vendor
dependent; ultimately, however, the DPC must be associated with a linkset (or
combined linkset) for sending the message.
Figure 7-9
shows an example of a routeset table. The routeset table contains
routesets for all of the possible destinations that can be reached. The table is
searched to find a match for the DPC to be routed. If a match is found in the list of
routesets, a linkset is chosen from the available routes associated with the routeset.
After choosing a linkset, a link is selected from the linkset over which the message
will be transmitted. In the example, the discrimination function has determined that
Point Code 200-1-2 does not match the point code of the current STP, and has
therefore passed the message to the routing function. The routing table is searched
for a match for DPC 200-1-2, and a match is found at the second entry. The
routeset contains two routes: LS_1 and LS_3, which represent linkset 1 and linkset
3. In this example, a priority field with the highest priority number is the preferred
route, so linkset LS_3 is chosen to send the message to DPC 200-1-2. The priority
field used here should not be confused with the message priority field of MTP3.
Again, the actual implementation of routing tables is vendor specific, and a vendor
might choose to label this field differently.

Figure 7-9. Routing Table Lookup


ANSI Network and Cluster Routing
Routing is often performed in a hierarchical fashion. In ANSI networks, messages
can be routed by matching only part of the DPC. The match is done on a portion of
the Most Significant Bits of the DPC, allowing messages to be routed using fewer
entries in the routing tables. This saves on administration overhead and eliminates
the need for detailed information about node addresses. It is especially useful when
dealing with traffic that is destined for another operator's network. For example, it
is quite common to aggregate routes using network or cluster routing. With
network routing, a route is selected by matching only the network octet of the
DPC; when cluster routing is used, the network and cluster octet of the DPC must
be matched to a routing table entry, as shown in Figure 7-10
.
Figure 7-10. Example of ANSI Cluster Routing


Alias Point Code Routing
An alias Point Code is a secondary PC used, in addition to the unique primary
Point Code, for identifying a node. Another common name for an alias is a
Capability Point Code. Multiple nodes (usually two) share the alias PC; this allows
messages to be routed to either node using a common PC. The alias PC is typically
used to identify a pair of STPs. Its primary purpose is to allow the load sharing of
SCCP traffic across the STP pair. Because SMH discrimination at either STP will
accept a message with the alias PC, the message can be delivered to the SCCP
User Part, where GTT is performed. Figure 7-11
shows an example using an alias
PC. The PC for STP 1 is 200-1-1, and the PC for STP 2 is 200-1-2. The alias PC
200-1-10 is used to identify both STP 1 and STP 2. As a result, SSP A can route

messages requiring SCCP GTT to 200-1-10 while load sharing across STP 1 and
STP 2. Since STP 1 and STP 2 each must have a unique PC, SSP A cannot perform
load sharing of SCCP traffic to the STP pair using the unique PC of either STP.
However, the alias PC allows either node to accept and process the message.
Figure 7-11. Example of Alias Point Code Routing


M
essa
g
e Load Sharin
g

A properly designed SS7 network employs alternate message paths to create
network redundancy. User traffic is typically load-shared across different paths to
maintain a balanced load on network equipment. Load sharing also ensures that
p
roblems on each path are detected quickly because they are car
r
ying traffic. There
are two types of SS7 load sharing:
• Load-sharing across linksets in a combined linkset
• Load-sharing across links within a linkset
Link selection is done when a node originates messages for normal MTP3 user
traffic so that overall traffic distribution is even across the links. The actual
algorithm for generating the SLS code is not specified by the SS7 standards, but
the result should be as even a traffic distribution as possible. There are times when
load sharing is not desired, as outlined later in this section and in the section,
"Load sharing and MTP3 User Parts
."

When load sharing is used, the SLS field determines the distribution of messages
across linksets and links as they traverse the network. The originating node
generates an SLS code and places it into the Routing Label. At each node in the
message path the SLS is used to map the message to a specific link and, if using a
combined linkset, to a specific linkset.
Load Sharing and MTP3 User Parts
As previously mentioned, a general goal of SS7 routing is to attempt to distribute
traffic evenly across links as much as possible. However, there are special
considerations within the MTP3 user parts when the SLS codes are being
generated.
The SLS codes for messages related to a particular communications exchange,
such as an ISUP call, are generated with the same value. If different SLS values for
messages belonging to the same call were used, there would be an increased
chance of out-of-sequence messages because they could take different network
routes, affecting the order in which they are received. Figure 7-12
shows a phone
call being signaled between SSP A and SSP B using ISUP. SSP A generates the
same SLS code 0100 for all messages associated with this particular call. This
causes the same linkset and link to be chosen for each of the messages. The same
linkset/link selection algorithm is applied at subsequent network nodes, resulting in
the same choice of linkset and links each time. This ensures that all messages take
the same path through the network and minimizes the chance for messages within a
specific communications exchange to be mis-sequenced. Messages from SSP B
that are related to the same call use SLS code 0101 for all messages.
Figure 7-12. SLS Generation for In-Sequence Delivery


Of course, the possibility always exists that network failures can cause alternate
p
aths to be taken; this increases the chance for ou

t
-of-sequence delivery.
The previous example showed the SLS values for an individual phone call.
However, the same principle applies to other User Part communication exchanges,
such as SCCP. SCCP generates the same SLS values to be used by MTP when the
in-sequence delivery option is set within SCCP.
The least significant bits of the Circuit Identification Code (CIC) are placed in the
SLS field when the MTP3 user is the Telephone User Part (TUP). All messages
related to a particular call use the same CIC, resulting in the same SLS value in
each message. Chapter 8
, "ISDN User Part (ISUP)," explains the CIC.
Messages generated by MTP3 (SNM, SNT, and SNTS messages) replace the SLS
field with the Signaling Link Code (SLC). No load sharing is performed for these
messages. Although there are exceptions, the SLC usually specifies the signaling
link to be used when sending a message. The "Signaling Network Management
"
section discusses the SLC and its specific use.
SLS in ITU-T Networks
ITU-T networks use a four-bit SLS value. The SLS value remains the same as the
message travels through the network. If a combined linkset is being used, one bit
of the SLS code is used to select the linkset at each node. The remaining bits are
used to select the link within the linkset. If a combined linkset is not being used, all
bits can be used to select a link within the linkset. The ITU-T standards are not
explicit about which bits are used for link and linkset selection.
SLS in ANSI Networks
ANSI networks use an eight-bit SLS code. The SLS code was originally 5 bits, but
was later increased to 8 bits to provide better distribution across links.
At a SEP, the least significant bit of the SLS is used for linkset selection and the
remaining bits are used for link selection if the message is being routed over a
combined linkset. All bits are used to select the link when routing over a single

linkset.
The least significant bit is also used for linkset selection at an intermediate node
routing over a combined linkset; however, only the three most significant bits and
the second through fourth least significant bits are concatenated for link selection.
When routing over a single linkset at the intermediate node, the three most
significant bits are concatenated with the four least significant bits to form an SLS
code for choosing a link.
Using SLS bit rotation is the standard method of load sharing in ANSI networks.
The original SLS code is right bit-shifted before the message is transmitted onto
the link. The bit rotation occurs at each node, before the message is transmitted. An
exception to this scheme is that SLS rotation is not performed for messages
transmitted over C-Links. Bit rotation is only done on the five least significant bits
to maintain backward compatibility with five-bit SLS codes. Figure 7-13
shows an
example of SLS rotation for messages that originate at SSP A. The least significant
bit is used to choose the linkset from a combined linkset to STP 1 or STP 2. After
linkset and link selection and before message transmission, a right bit rotation is
p
erformed on the five least significant bits. At STP 1 and STP 2, a single linkset is
used to route the message to SSP B.
Figure 7-13. SLS Rotation


Comparing the IP and MTP3 Protocols
The MTP3 message handling is similar to the Internet Protocol (IP) in some
respects. For those who are familiar with IP, a comparison of the two protocols
helps to put MTP3 in perspective. This is not intended to suggest an exact
comparison; rather, to relate something that is known about one protocol to
something similar in the other. The main point is that both protocols are packet
based and designed to deliver messages to a higher layer service at a node in the

network. It is not surprising that there are a number of commonalities given that
the requirements are similar. In fact, studying a number of communications
transport protocols shows that many share a common functionality and structure,
with each diverging slightly to address its particular requirements. Table 7-3
lists
an association of key IP packet fields with their MTP3 counterparts.
Table 7-3. Comparison of IP and MTP3 Packet Fields
IP SS7
Source IP Address Originating Point Code
Destination IP Address Destination Point Code
Protocol Service Indicator
Precedence (part of TOS field) Priority
Data User Data

In addition to the similarity in the packet fields, the network nodes and their
functions also share common aspects. A typical IP network contains a number of
hosts that communicate with other hosts, sometimes in different networks. Routers
connect the different networks and allow hosts to communicate with each other.
The SS7 network's SSP and SCP nodes can be viewed in much the same way as
hosts in the IP network. The STP node in an SS7 network is similar to the IP
router. It is used to interconnect various hosts in a hierarchical fashion and to route
messages between different networks.
One important distinction in this analogy is that the STP only uses static routes; it
has no "routing protocols," such as those used in IP networks.
While network design varies greatly between the two different types of networks,
both networks employ a means of hierarchical address structure to allow for
layered network design. The IP network uses classes A, B, and C, which are
identified by the bit mask structure of the address. The hierarchical structure in
SS7 is created by dividing the Point Code bits into identifiers that specify a level
within the network. The identifiers are different in ITU-T and ANSI, but they

function in the same manner. For example, ANSI creates this hierarchy by dividing
the Point Code into network, cluster, and member. Both IP and SS7 have their own
uniqueness; no analogy is perfect, but they do share similarities.
M
TP3 Messa
g
e Handlin
g
Example
To better understand the entire process of Message Handling, consider the example
in Figure 7-14
. Here, SP A is a typical SSP with two linksets connecting it to the
SS7 network via an STP. Suppose that SSP A sends and receives ISUP traffic with
SSP B. There is no need to be concerned with the details of ISUP at the moment—
only the fact that an SSP A User Part (ISUP) needs to communicate via MTP3 with
an SSP B User Part (ISUP). SSP A is setting up a call to SSP B and needs to send
an ISUP message. It requests MTP3 to send a message (routing function). The
p
ayload (ISUP information) is placed in the MTP3 SIF User Info field. The
destination indicated by the user part is placed in the Routing Label's DPC field.
The Point Code of the node sending the message (SSP A) is placed in the OPC
field. The SLS is generated and placed in the Routing Label's SLS field. MTP3
attempts to find a routeset for the Destination Point Code in its routing table; it
finds a match and determines which route is associated with the routeset. The SLS
is examined and a link for transmitting the message is selected. The message
arrives at STP 1. Upon receiving the message, the STP examines the DPC and
compares it to its own Point Code (discrimination function). The comparison fails
because the DPC is the Point Code for SSP B. This causes the STP to attempt to
route the message. The STP searches its routing table to find a match for the DPC.
It finds a match, selects a linkset to route the message, and puts the SLS code into

the message, which is modified using bit rotation, if necessary (ANSI networks).
The message arrives at SSP B and is passed to MTP3 Signaling Message Handling.
SSP B compares the message's DPC to its own Point Code (discrimination
function) and determines that it matches. The SI is then examined to determine
which User Part should receive the message (distribution function). An SI of 5
identifies the User Info as ISUP, and the message is passed to the ISUP layer for
p
rocessing. This completes MTP3 message handling for this message.
Figure 7-14. Example of Message Handling
[View full size image]



