Octet	Message Format
0	Source Channel (Source Entity ID)
1	Source Board (Source Instance ID)
2	Destination Channel (Destination Entity ID)
3	Destination Board (Destination Instance ID)
4 5	Message Length (2 octets)
6 7	Message Start Offset (2 octets)
8 9	Message End Offset (2 octets)
10..i	Filler
i + 1	Message Type
i + 2	...
...	MTP 2 Msg Parameters
n	...

2.6 Byte Ordering Considerations

Please note the following byte ordering conventions for 16-bit and 32-bit parameters in the messages to/from MTP 2. This is not the same byte ordering used for short and long integers on Intel 80x86 machines. The host application is responsible for converting between network and host byte order, if necessary, in both the send and receive directions. Note: The Message Length field is part of the DPR header interface between the host application and the host device driver, and must be passed in host native byte order, not the byte order shown in this section. The Message Start and End offsets, on the other hand, are part of the interface between the host application and the MTP 2 process, and must be passed in the network byte order shown below.
16-Bit Fields:
32-Bit Fields:
The following nomenclature is used for data types: Data Type Description U8 Unsigned 8-bit quantity S16 Signed 16-bit quantity U32 Unsigned 32-bit quantity

Data Type	Description
`U8`	Unsigned 8-bit quantity
`S16`	Signed 16-bit quantity
`U32`	Unsigned 32-bit quantity

2.7 Layer 2 Interface Procedures

This section describes the procedures (the sequence of messages) used to interface to the SS7 MTP 2 process on the TX board. The SS7 layer 2 interface consists of several distinct phases: binding, connection establishment, data transfer, connection clearing, and status/control.

2.7.1 Binding

The binding phase establishes the host application (MTP layer 3) as the user of the layer 2 interface. Binding consists of a single BIND request from the application to layer 2, for which there is no response. A separate bind request must be sent to MTP 2 for every link on every TX board that the application wishes to use.

2.7.2 Connection Establishment

The layer 2 user requests layer 2 to establish a "connection" by sending a CONNECT request packet. This causes the SS7 layer 2 to attempt to bring up the link and initiate link alignment procedures with the far exchange. Layer 2 sends a CONNECT CONFIRMATION message back to the user when link alignment has been successfully established. Connection establishment is requested separately for each SS7 link. Note: No data packets may be transferred until the CONNECT CONFIRMATION message has been received by the user application. Figure 3. Message Flow for Connection Establishment

2.7.3 Data Transfer

The data transfer phase is entered on a particular link once the MTP 2 process has returned a CONNECT CONFIRMATION message to the application.
The layer 2 user application requests a SS7 packet to be transmitted on a particular link by sending a DATA REQUEST to layer 2. Layer 2 returns a DATA CONFIRMATION message back to the user application when the message has been acknowledged by the far exchange. The application may send multiple DATA REQUEST(s) to MTP 2 before receiving a DATA CONFIRMATION. The DATA CONFIRMATION message contains a credit field indicating the number of data requests being acknowledged by the data confirm. Figure 4. Message Flow for an Outgoing Data Transfer
Layer 2 notifies the user application of an incoming data packet by sending a DATA INDICATION packet. There is no response to this packet from the user application back to layer 2. Figure 5. Notification of an Incoming Data Packet
During data transfer, the user application may request layer 2 to apply flow control to a link (or to stop flow control) by sending a FLOW request. There is no response from layer 2 back to the user application for this request. Layer 2 may also send an unsolicited FLOW INDICATION message to the user application to indicate that congestion has started or ended on a link.

2.7.4 Status/Control

The MTP 2 status request supports a number of functions which help layer 3 implement link and traffic management procedures. The layer 3 application may use the status request to perform the following functions. Retrieve the current BSN (last acknowledged sequence number) for a link (useful in implementing changeover procedures). Retrieve all MSUs transmitted on a link but not yet acknowledged (also useful in implementing changeover procedures). Request MTP 2 to drop all queued messages. Notify MTP 2 of an emergency on or off condition on a link. Notify MTP 2 of a local processor up or down condition (passed on to far exchange).
MTP 2 returns a STATUS CONFIRMATION message containing the current BSN (last acknowledged sequence number) for a link to the application in response to a "retrieve BSN" status request. MTP 2 may 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 indicates that it is the last). In this case, no STATUS CONFIRMATION message is returned to the application. Figure 6. Use of "Retrieve" Status Requests to Implement Link Changeover

2.7.5 Connection Clearing

The user application may request that the link be disabled by sending a DISCONNECT request to layer 2. There is no response from layer 2 to a DISCONNECT request. Layer 2 may send an unsolicited DISCONNECT INDICATION message to the user application to notify it that a link has been disconnected and the reason for the disconnect.
Layer 2 will send unsolicited STATUS INDICATION messages to the user application to notify it of changes in the link status (up or down).

2.8 MTP 2 Messages

The following messages comprise the interface to the SS7 layer 2 task. All messages contain a message type and a link ID in addition to the parameters listed below. Actual message layouts are specified in Appendix A. Message Direction Parameters Description BIND REQUEST MTP 3 -> MTP 2 Service User ID Service Prov. ID User Entity ID User Instance ID Binds user application as sole user of SS7 layer 2 link. CONNECT REQUEST MTP 3 -> MTP 2 Status Requests layer 2 to bring up a physical link. Status parameter may be used to specify status to bring link up in (normal, emergency, power on only, etc.) CONNECT CONFIRM MTP 2 -> MTP 3 None Notifies user application that link connect has successfully completed (link is aligned). DATA REQUEST MTP 3 -> MTP 2 Data buffer Requests layer 2 to transmit data buffer on a particular link. DATA CONFIRM MTP 2 -> MTP 3 Status Credit Acknowledges transmission of a data request back to user application; Status parameter indicates whether more DATA rqsts may be issued, Credit parameter indicated how many requests are being acknowledged. DATA INDICATION MTP 2 -> MTP 3 Data buffer Indicates received data packet to user application. DISCONNECT REQUEST MTP 3 -> MTP 2 Reason Requests layer 2 to disconnect a link. DISCONNECT INDICATION MTP 2 -> MTP 3 Reason Notifies user application that a link is disconnected. FLOW REQUEST MTP 3 -> MTP 2 Action Requests layer 2 to start or stop flow control on a link. FLOW INDICATION MTP 2 -> MTP 3 Action Notifies user application that congestion has started or stopped on a link. STATUS REQUEST MTP 3 -> MTP 2 Action Status Requests special status/control function. STATUS CONFIRM MTP 2 -> MTP 3 Action Status Response to status request for certain status/control functions. STATUS INDICATION MTP 2 -> MTP 3 Status Notifies user application that a link has gone up or come down.

Message	Direction	Parameters	Description
`BIND REQUEST`	MTP 3 -> MTP 2	Service User ID Service Prov. ID User Entity ID User Instance ID	Binds user application as sole user of SS7 layer 2 link.
`CONNECT REQUEST`	MTP 3 -> MTP 2	Status	Requests layer 2 to bring up a physical link. Status parameter may be used to specify status to bring link up in (normal, emergency, power on only, etc.)
`CONNECT` `CONFIRM`	MTP 2 -> MTP 3	None	Notifies user application that link connect has successfully completed (link is aligned).
`DATA REQUEST`	MTP 3 -> MTP 2	Data buffer	Requests layer 2 to transmit data buffer on a particular link.
`DATA CONFIRM`	MTP 2 -> MTP 3	Status Credit	Acknowledges transmission of a data request back to user application; Status parameter indicates whether more DATA rqsts may be issued, Credit parameter indicated how many requests are being acknowledged.
`DATA INDICATION`	MTP 2 -> MTP 3	Data buffer	Indicates received data packet to user application.
`DISCONNECT REQUEST`	MTP 3 -> MTP 2	Reason	Requests layer 2 to disconnect a link.
`DISCONNECT INDICATION`	MTP 2 -> MTP 3	Reason	Notifies user application that a link is disconnected.
`FLOW REQUEST`	MTP 3 -> MTP 2	Action	Requests layer 2 to start or stop flow control on a link.
`FLOW INDICATION`	MTP 2 -> MTP 3	Action	Notifies user application that congestion has started or stopped on a link.
`STATUS REQUEST`	MTP 3 -> MTP 2	Action Status	Requests special status/control function.
`STATUS CONFIRM`	MTP 2 -> MTP 3	Action Status	Response to status request for certain status/control functions.
`STATUS INDICATION`	MTP 2 -> MTP 3	Status	Notifies user application that a link has gone up or come down.

(Page 1 of 1 in this chapter) Version

tech_support@nmss.com