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.

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.

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
0	Management (MGMT) messages
	Error message	0
	Notify message	1
3	ASP State Maintenance (ASPSM) messages
	ASP Up	1
	ASP Down	2
	Heartbeat	3
	ASP Up Acknowledge	4
	ASP Down Acknowledge	5
	Heartbeat Acknowledge	6
4	ASP Traffic Maintenance (ASPTM) messages
	ASP Active	1
	ASP Inactive	2
	ASP Active Acknowledge	3
	ASP Inactive Acknowledge	4
6	MTP2 User Adaptation (MAUP) messages
	Data	1
	Establish Request	2
	Establish Confirm	3
	Release Request	4
	Release Confirm	5
	Release Indication	6
	State Request	7
	State Confirm	8
	State Indication	9
	Data Retrieval Request	10
	Data Retrieval Confirm	11
	Data Retrieval Indication	12
	Data Retrieval Complete Indication	13
	Congestion Indication	14
	Data Acknowledge	15
10	Interface Identifier Management (IIM) messages
	Registration Request	1
	Registration Response	2
	Deregistration Request	3
	Deregistration Response	4

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.

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.

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.

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
	User Data	1
	Link Status	2

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."