The MTP 2 interface consists of messages that govern communications between an application on the host and the MTP 2 task on the TX board.
MTP 2 messages perform the following tasks:
The binding phase establishes the host application (MTP 3) as the user of the MTP 2 interface. The application sends a single bind request message to MTP 2, for which there is a bind confirmation response. The application must send separate bind request messages to MTP 2 for each link on each TX board that it wants to use.
The application establishes a connection by sending a connect request message and attempting to bring up the link and initiate link alignment procedures with the far exchange. MTP 2 sends a connect confirmation message back to the application when link alignment is successfully established. The application requests connections separately for each SS7 link.
No data packets are transferred until the application receives the connect confirmation message. The following illustration shows the message flow for establishing a connection:
After the MTP 2 task returns a connect confirmation message to the application, the application can begin transferring data.
The application sends a data request message to MTP 2 to request transmission of an SS7 packet on a particular link. When a message or messages are acknowledged by the far exchange there is no corresponding notification sent to the application. The following illustration shows the message flow for an outgoing data transfer:
MTP 2 sends a data indication message to notify the application of an incoming data packet. The application does not respond to MTP 2. The following illustrates an incoming data packet notification:
During data transfer, the application can send a flow control request to apply flow control to a link (or to stop flow control). MTP 2 does not respond to the application. MTP 2 can also send an unsolicited flow control indication message to the application to indicate that congestion started or ended on a link.
The MTP 2 status request provides the following functions that help MTP 3 implement link and traffic management procedures:
Retrieves the current BSN (last acknowledged sequence number) for a link. This function is useful in implementing changeover procedures.
Retrieves all MSUs (message signal units) transmitted on a link but not yet acknowledged. This function is useful in implementing changeover procedures.
Requests MTP 2 to drop all queued messages.
Notifies MTP 2 of an emergency on or off condition on a link.
Notifies MTP 2 of a local processor up or down condition (passed on to the far exchange).
MTP 2 returns a status confirmation message containing the current BSN for a link to the application in response to a retrieve BSN status request. MTP 2 can also return a status confirmation message in response to a retrieve messages status request, but only if there are no unacknowledged messages to be retrieved. If there are unacknowledged messages to be retrieved, a data confirmation message indicating a status of unacknowledged [more|last] is sent to the application for each message. The last message indicates that it is the last. In this case, no status confirmation message is returned to the application. The following illustration shows how to use retrieve status requests to implement link changeover:
The application can send a disconnect request message to MTP 2 to disable the link. MTP 2 does not respond to a disconnect request message. MTP 2 can send an unsolicited disconnect indication message to the application to notify it that a link disconnected and the reason for the disconnect.
MTP 2 sends unsolicited status indication messages to the application to notify it of changes in the link status (up or down).
Refer to the MTP 2 message summary for additional information