TX device drivers implement the message-passing interface between the host and the TX processor (CP). The physical interface between the host and the CP (shared dual-port RAM or DPR) is subdivided into a set of virtual channels to support communication between processes on the host and on the TX board. The channel concept enables multiple processes on the host and the CP to exchange messages without interfering with each other. The TX board currently supports 256 channels numbered 0 through 255. To minimize conflicts, NMS recommends the following channel usage:
Channel |
Usage |
0 through 31 |
Reserved |
32 through 127 |
Available for use by applications |
128 through 255 |
Reserved |
A process on either the host or the CP wanting to receive messages registers with the driver for a specific channel number. For a host-resident process, the channel registration can be implicit with the device open request, or it can be a separate operation. Channel numbers are assigned statically at compile time. There is no built-in facility to dynamically learn the channel assigned to a particular function. Only one process can receive messages for a particular channel. Each message contains a header supplied by the sender of the message that identifies the destination board and channel, the source board and channel, and the length of the message.
Each application must have a unique entity and instance ID to route messages between the processes in the system. Entity IDs are single byte values in the range of 0x00 through 0xFF. Allocate entity IDs as follows:
Range |
Usage |
0x00 through 0x1F 0x80 through 0xFF |
Reserved for system utilities, configuration utilities, and management utilities. |
0x20 through 0x7F |
Reserved for applications. |
Instance IDs identify the processor on which the entity executes. The host is always processor 0 (zero). All host-resident MTP 2 applications must be coded to zero. All tasks on TX board 1 receive an instance ID of 1, all tasks on TX board 2 receive an instance ID of 2, and so on.
Each process on the CP and on the host in an SS7 implementation registers for the channel that corresponds to that layer's (or application's) entity ID. MTP 2 registers for channel 0x16. To send a message to the MTP 2 task on board n, the destination channel is set to 0x16, the destination board is set to n, and the source channel and board are set to the sender's entity ID and board number.
Call the TX driver through the CPI library. Call cpi_init before issuing any other CPI calls. Issue a call to cpia_open for each board with which the application wants to communicate. Then call cpi_send (synchronous interface) or cpia_send (asynchronous interface) and cpi_get_data (synchronous interface) or cpia_get_data (asynchronous interface) to send and retrieve data packets to and from the board. See the CPI Library Developer's Reference Manual for more details.
The following table describes the format of messages passed between the MTP 3 task on the host and the MTP 2 task on the CP through the TX driver:
Octet |
Message format |
0 |
Source channel (source entity ID) |
1 |
Source board (source instance ID). The source entity and instance IDs define the sender of the message. |
2 |
Destination channel (destination entity ID) |
3 |
Destination board (destination instance ID). The destination entity and instance IDs define the intended recipient of the message. |
4 and 5 |
Message length (2 octets). Contains the byte length of the entire message, including headers, filler, and parameters. |
6 and 7 |
Message start offset (2 octets). Contains the number of octets of filler included following the message end offset before the message type parameter. Include at least four bytes of filler on messages sent to MTP 2 to guarantee MTP 2 has room to prepend its header to the actual data portion of a message without having to copy the data to a new buffer. On messages received from MTP 2, the layer 3 application must use this parameter to determine where in the buffer the actual message content (the message type field) begins. |
8 and 9 |
Message end offset (2 octets) |
10..i |
Filler |
i + 1 |
Message type |
i + 2 |
... |
... |
MTP 2 message parameters |
n |
... |
The MTP 2 demonstration programs mtp2app and mtp2itu provide include files containing structures for message formats. For further details on the MTP 2 messages, see MTP 2 message summary.