Signaling System No.7 Protocol Architecture And Sevices part 54 ppt

As noted, the M2UA layer supports the MTP Level 2 to MTP Level 3 primitive boundary, including support for link alignment, message retrieval during link changeover, remote and local proc

MTP Level 2 User Adaptation (M2UA)

The M2UA protocol defines the layer split between MTP Level 2 and MTP Level

3 M2UA is defined by RFC 3331 [140] The M2UA protocol can be used between

a SG, which is called a Signaling Link Terminal (SLT), and an MGC

The SG would terminate standard SS7 links using MTP Level 1 and MTP Level 2

to provide reliable transport of MTP Level 3 messages to the SEP or STP The SG also provides reliable transfer of MTP Level 2 primitives over IP, using SCTP as the transport protocol

Figure 14-18 shows an example of an SG to the MGC application of M2UA The SEP is a SEP in the SS7 network Just as it does for M3UA, NIF stands for Nodal Interworking Function It is the software in the SG that provides the SS7 to IP network interworking

Figure 14-18 Example of M2UA Between SG and MGC

Although not discussed, M2UA can be used between two SGs, but not in a peer-to-peer arrangement One SG would terminate the SS7 links and backhaul the MTP Level 3 messages to the other SG, which would terminate MTP Level 3

As noted, the M2UA layer supports the MTP Level 2 to MTP Level 3 primitive boundary, including support for link alignment, message retrieval during link changeover, remote and local processor outage, and link congestion notifications

Messages and Formats

M2UA uses the common header and TLV format for parameters that were defined

in the M3UA section In addition, M2UA introduces an M2UA specific header that

is required because an Application Server can support more than one Interface Identifier

Figure 14-19 shows the M2UA specific header, which is placed between the

common message header and message-specific parameters Note that it follows the TLV format The Interface Identifier can be an integer-based or text-based (ASCII) value If it is integer-based, the length is always equal to eight If it is text-based, the length is based on the length of the ASCII string, up to a maximum of 255 octets

Figure 14-19 M2UA Specific Message Header

Table 14-3 lists the message classes and message types for M2UA

Table 14-3 M2UA Message Classes and Types

Msg Class

Value Message Class and Type Names

Msg Type Value

3 ASP State Maintenance (ASPSM) messages

ASP Down 2 Heartbeat 3

4 ASP Traffic Maintenance (ASPTM)

messages

ASP Inactive Acknowledge 4

6 MTP2 User Adaptation (MAUP) messages

Data Retrieval Indication 12 Data Retrieval Complete Indication 13

10 Interface Identifier Management (IIM)

messages

MTP2 User Adaptation (MAUP) Messages

The MAUP messages support the interface boundary to MTP Level 3

The Data message is an MAUP message that contains MTP Level 3 protocol data, beginning with SIO—except in the case of the Japanese TTC [153] variant For the TTC variant, the protocol data begins with the Length Indicator (LI) because its first two bits are used for priority information

The Data message can contain an optional Correlation Identifier that is generated

by the sender This parameter is included to request an acknowledgement that the M2UA peer has received the protocol data

The following is a list of MAUP messages:

• Data Acknowledge

The Data Acknowledge message confirms the receipt of the Data message that is specified by the Correlation Identifier

• Establish Request and Confirm

The ASP sends an Establish Request message to request the alignment of an SS7 link The mode of the alignment defaults to Normal and can be changed with the State Request message When the link is aligned, the SGP sends an Establish Confirm message

• Release Request, Indication, and Confirm

The ASP sends a Release Request message to request that an SS7 link be taken out of service When the SS7 link transitions to out of service, the SGP

sends a Release Confirm message If the SS7 link transitions to out of

service asynchronously (the SEP takes the link out of service), the SGP sends a Release Indication message to notify the ASP

• State Request, Indication, and Confirm

The ASP sends a State Request message to request an action, such as setting link alignment state to emergency, clearing congestion, or flushing buffers for the specified SS7 link The SGP sends the State Confirm message to confirm receipt of the State Request The SGP sends the State Indication message to indicate a local or remote process state change for the specified SS7 link

• Congestion Indication

The SGP sends the Congestion Indication to the ASP when there has been a change in the congestion or discard status of the specified SS7 link The message accommodates those MTP variants that support multiple congestion levels

• Retrieval Request, Indication, Complete Indication, and Confirm

These messages are used for the link changeover procedure The ASP starts the procedure by using the Retrieval Request message to request the BSN for the failed SS7 link The SGP responds with the Retrieval Confirm

message If there are any user data messages to retrieve, the MTP Level 3 on the ASP can choose to retrieve them Again, the Retrieval Request message

is used for this purpose The SGP sends the user data messages in the

Retrieval and Retrieval Complete Indication messages

MGMT Messages

The messages are the same as those described under M3UA However, there are some errors that are specific to M2UA The "Invalid Interface Identifier" error might indicate a misconfiguration between the SGP and ASP

ASPSM and ASPTM Messages

As with the MGMT messages, the ASPSM and ASPTM messages are the same as those described under M3UA However, instead of Routing Context, Interface Identifier is an optional field in the ASPTM messages

Interface Identifier Management (IIM) Messages

The IIM messages provide a means of supporting the MTP Level 3 procedures for automatic allocation of Signaling Terminals and Signaling Data Links The

Registration Request requests that an Interface Identifier be assigned to a Signaling Data Terminal and Signaling Data Link Identifier pair The Registration Response provides a result (success or fail) for the registration and, if successful, the

assigned Interface Identifier The ASP can deregister the Interface Identifier (in other words, give it back to the pool) using the Deregistration Request message The SGP confirms this request using the Deregistration Response message

SS7 Variant Specifics

Like the other UAs, M2UA provides support for all SS7 variants There is one parameter that is specific to the Japanese TTC [153] variant A TTC-specific

Protocol Data parameter provides the means of carrying priority information This Protocol Data parameter differs from the generic Protocol Data parameter by

starting with the Length Indicator (the Japanese TTC variant uses the spare bits of this octet for priority information), rather than the SIO The Congestion Indication message also accommodates MTP variants that support multiple congestion levels Message Flow Examples

Figure 14-20 shows a message flow example for an SGP that supports an

Application Server containing IIDs 1 and 2 The ASP brings the Application

Server to the AS-ACTIVE state by sending the appropriate ASPSM and ASPTM messages It then decides to align the first SS7 link (identified by IID 1) in-service using emergency alignment Then, it requests to align the second SS7 link

(identified by IID 2) using normal (the default) alignment

Figure 14-20 M2UA Message Flow Example

MTP Level 2 Peer Adaptation (M2PA)

Similar to the M2UA layer, the MTP Level 2 Peer Adaptation (M2PA) layer

transports SS7 MTP Level 2 user (MTP Level 3) signaling messages over IP using

SCTP However, in addition, M2PA supports full MTP Level 3 message handling and network management between two SS7 nodes that communicate over an IP network An ID [141] defines an M2PA, which is in the process of becoming an RFC

M2PA supports the following features:

• Seamless operation of MTP Level 3 protocol peers over an IP network

• Support for the MTP Level 2 to MTP Level 3 primitive boundary

• Support for the management of SCTP associations as IP links

• Support for reporting asynchronous status changes to layer management

M2PA can be used between a SG and a MGC, between a SG and an IPSP, and between two IPSPs In any scenario, both sides of the M2PA protocol must be assigned an SS7 point code Two IPSPs can use M2PA IP links and standard SS7 links simultaneously to send and receive MTP Level 3 messages

Figure 14-21 shows an SG to MGC application of M2PA

Figure 14-21 Example of M2PA Used Between a SG and a MGC

M2PA can also be used between two SGs This configuration would be useful for long-haul SS7 link replacement Figure 14-22 shows an example of such a

configuration

Figure 14-22 Example of M2PA Used Between Two SGs

[View full size image]

M2PA and M2UA Comparison

M2PA and M2UA are similar in that they both support the MTP Level 2 primitive boundary to MTP Level 3, and they both transport MTP Level 3 data messages However, they also have some significant differences

The differences arise from the treatment of the MTP Level 2 primitive boundary interface M2UA "backhauls," or transports, the boundary primitives by way of M2UA messages between the M2UA peers M2PA processes the boundary

primitives, in effect replacing MTP Level 2 without necessarily repeating all of the MTP Level 2 functionality Therefore, M2PA provides an IP-based SS7 link This requires that the M2PA SG is an SS7 node with a point code The M2UA SG does not have such a requirement; rather, it shares the MGC or IPSP's point code

M2PA Differences from Other UAs

M2PA does share the same common message header with the other UA layers, but

it is different in many ways Because M2PA is a peer-to-peer with a single "IP link" that is defined by a single association, there is no need for Routing Keys or Interface Identifiers Further, M2PA does not support the concepts of Application Servers, ASPs, or SGP M2PA's redundancy model is based on SS7 The peer-to-peer connection based on a SCTP association supports a single SS7-based IP-link SS7 link sets support redundancy

Messages and Formats

As noted, M2PA does support the common message header In addition, M2PA has a M2PA specific header that is used with each message Figure 14-23 shows the M2PA specific header

Figure 14-23 M2PA Specific Message Header

As with MTP Level 2, Backward Sequence Number (BSN) is the Forward

Sequence Number (FSN) that was last received from the peer FSN is the sequence number of the user data message being sent

Table 14-4 lists the message classes and message types for M2PA

Table 14-4 M2PA Message Classes and Types

Msg Class Value Message Class and Type Names Msg Type Value

11 M2PA messages

MTP2 Peer Adaptation Messages

The following are M2PA messages:

• User Data— The User Data message carries the MTP Level 3 Payload's SIO and Signaling Information Field (SIF) It also contains a LI field to support the Japanese TTC variant that requires two bits in the LI field to be used for priority However, the LI field is not used for any other purpose (such as to indicate message length) and is set to zero

• Link Status— The Link Status message is similar to the Link Signal Status Unit (LSSU) in MTP Level 2 It is used to indicate the state of the "IP link." The possible states are: Alignment, Proving Normal, Proving Emergency, Ready, Processor Outage, Process Recovered, Busy, Busy Ended, and Out of Service The Proving message can contain optional filler to enable the SCTP send window size to be increased (in other words, to move beyond the SCTP slow start threshold) before the "IP link" is aligned

Message Flow Example

Figure 14-24 shows a message flow example for aligning a link by using normal proving between two SGs supporting M2PA In this diagram, the timer information

is only shown for SG1 When alignment is complete, the M2PA peers inform their respective MTP Level 3 stacks that the link is in-service; MTP Level 3 messages can then be sent across the "IP link."

Figure 14-24 M2PA Message Flow Example