9.1 APPENDIX A - TCP/IP APPLICATION MESSAGES
9.1.1 Message Types Supported
The following TCP/IP Message Types must be supported (see the following table).
Table 9-1. Application Messages
|
Message Code |
Message Type |
Description |
|
01 |
Good Day |
This message is used to request the Identification of peer NodeName, or to test if session is still alive. |
|
05 |
Good Night |
This message is used to notify the peer that the sending process is shutting down immediately. |
|
06 |
Good Bye, Disconnect Request |
This message is used to invite the peer to disconnect the current session. Graceful disconnect. |
|
09 |
Error |
This message is used to indicate a protocol error. |
|
19 |
Data (UPL Header/UPL Data) |
This message is used to facilitate the transfer of administrative messages and operational data. This message contains the application layer UPL header with the application message UPL data. |
9.1.2 Connect / Disconnect Sequence Example
The following figure illustrates which side of the interface usually initiates the message type, although it does not depict the Symmetric Peer-to-Peer relationship that TCP/IP supports.
Figure 9-1. Connect/Disconnect Sequence Example
9.1.2.1 Connect/Disconnect Dialogue
TCP connections are viewed as full duplex (i.e., two independent data paths, one in each direction). Once a TCP connection is requested and accepted, both sides are in “data transfer phase”. Both sides can send both data and Good Day messages.
For example, the software on one system (SMS/800) waits for a connect request while the other host (SCP) initiates the request. Once a TCP connection has been established, data can flow in both directions. During “data transfer phase”, data can be exchanged. Optional Good Day messages can be mixed with data messages. In the example, an SCP sends Good Day message with zero-length destNodeName, the receiving host (SMS/800) responds a Good Day message (with non- zero-length destNodeName).
After the sender has no more data to transmit and the TCP connection has been idle for a time determined by the idle timer, a goodbye (i.e., disconnect request) message may be initiated, but frequent use is not encouraged. In this example, the sender (SCP) can still receive data from SMS/800, but the SCP cannot send more data. Any new messages must be sent through a new connection. After reaching the next message boundary, the receiving host (SMS/800) must initiate a TCP disconnect (see Section 3.4.4.2, disconnect phase).
Under normal conditions, a graceful disconnect (Good Bye) should be used. While a good bye message is used to close the current session, a good night message is used to notify the peer that the sending process is shutting down for the night. It is usually followed by the transport layer disconnect (TCP Disconnect) message from the sending and receiving processes. Upon receipt of the TCP Disconnect message, the sending and receiving process should close the connection.
9.1.2.2 Good Day Message (mcommgdy)
The “mcommgdy” message must be supported to respond to the “mcommgdy” request, and it must adhere to the above-mentioned rules.
Good Day messages can be used by either side if verification of the other side’s identity is needed. Good Day messages can also be used to test if the session is still alive. Whenever the TCP connection between an SCP and SMS/800 is restored or whenever an SCP or SMS/800 is activated, it is recommended that at least one Good day message be exchanged; however, extensive use of this message is not advised.
The SMS/800 application layer will send a Good Day message each time the TCP connection request is accepted by an SCP. The initial Good Day message contains the application layer message header parameters with no application message data.
This message is to let the peer application know “who I am” and/or “who are you/are you there” This message can be sent anytime during a connected session. The following rules must be adhered to:
- “who are you/are you there”- If the destNodeName is null (zero length), the receiving side MUST return a “mcommgdy” or any message with both the destNodeName and the srcNodeName filled. For a process accepting TCP connection, it only knows the requester’s IP-address/TCP-port#. This message can be used to find out the Node Name of the peer.
- “who am I”- If the destNodeName and srcNodeName contains a non-zero-length value, the receiving side MUST NOT respond with a mcommgdy”. This is done to avoid infinite good-day handshakes. Although any side may send a “mcommgdy” to the other side at any time, it is recommended that the connect-requester send the “mcommgdy” immediately after the connection is accepted by the other side.
9.1.2.3 Good Night Messages (mcommgnt)
The good night message (mcommgnt) shall be supported for process termination.
This message is used to notify the peer that the sending process is “shutting down”. It is usually followed by a transport layer disconnect (i.e., TCP DISCONNECT). Upon receipt of this message, the receiving process should close the connection. When the SCP or SMS/800 is deactivated for such activity as periodic maintenance, the terminating application should send the peer application a good night message. The good night message contains the application message header parameter with no application message data. The source and destination node name for the good night message will be non-null (a valid CLLI™ code), with the source node name representing the receiving application.
9.1.2.4 Good Bye, Disconnect Request (mcommbye)
The “mcommbye” message shall be supported for graceful disconnection of the current session.
This message is used to invite the peer to disconnect the current session. The message could be sent after the connection has been idle for a time designated by the idle timer, and the sender has nothing to send. Note, to disconnect after idle time is not a requirement.
After sending the next message boundary, the receiving side must disconnect the TCP session. This message is needed to prevent a process from sending a disconnect while the other side starts sending new messages (i.e., prevents lost messages). The sending process should receive, but not send, more messages. The good bye sender should send the newly arrived messages, if any, through a new connection. The good bye message contains the application message header parameter with no application message data.
9.1.2.5 Data Message
The “mUPL” message shall be supported to facilitate the transfer of administrative messages and operational data between an SCP and SMS/800.
The UPL Header/UPL message is used to facilitate the transfer of administrative messages and operational data, in both directions, between the SMS/800 and the SCPs. The administrative and operations data to be exchanged are defined in this section. This document provides detailed descriptions of the following types of UPL Header/UPL messages that are required to be supported by the SMS/800 and SCPs.
The UPL Header/UPL Message contains the application layer message header parameter with the application message data portion as defined therein.
9.1.2.5 Message Error Processing
An application message sent between the SMS/800 and SCP may fail for one of the following reasons:
- Bad Source
- Bad Destination
- Bad Version.
Any one of these errors will result in the application message not being delivered to its destination. If an application message cannot be delivered to its destination, the application message will fail and be discarded. When an application message fails, an error message may be returned to the originator of the message. The error message should consist of the application message header with the appropriate error code. No data is returned.
The selection of the appropriate error code for an error message should correspond to the following guidelines:
- If the SCP receives an application message with an invalid Source Node name, the error code should indicate “bad source” (error code: 1).
- If the SCP receives an application message with an invalid destination node name, the error code should indicate “bad destination” (error code: 2).
- If the SCP receives an application message with an invalid version, the error code should indicate “bad version” (error code: 3).
- If the SCP receives an application message with an error not defined above, the error code should indicate “other” (error code: 9).
The MGI OS shall fail and discard any application message that cannot be processed.
9.2 APPENDIX B - REFERENCES
SCP-SMS/800 TCP/IP Interface Specification (SR-4959) by Telcordia Technologies (currently part of Ericsson Inc.) - this document is available for purchase, for a small fee, from Ericsson Inc. SR-4959 contains additional details about the SMS/800-SCP TCP/IP interface that are not described elsewhere. Appendix A contains an abbreviated version of the TCP/IP information available in SR-4959.
SMS/800 Service Turnup Guide (BR 780-004-212) published by Telcordia Technologies (currently part of Ericsson Inc.) - this document is used only by Software Support to provision an SCP in the SMS/800 platform, and therefore, this document should not be needed by an SCP Owner/Operator.
9.3 APPENDIX C - GLOSSARY
Acronym Explanation
ACG Automatic Call Gap
ALP Application Level Parameters
ASCII American Standard Code for Information Interchange
ASD Application Sample Data
ASPEC Application Specification file
ASR Application Sample Rate
ATT Application Transaction Timer
AUD Audit
CCITT International Telephone and Telegraph Consultative Committee
CCO Call Completion Option
CCS Common Channel Signaling
CMSDB Call Management Services Data Base
CPR Call Processing Record
CSD Customer Sample Data
CUC CMSDB Update Complete
DLT Delete
DTT Destination Threshold Table
EBCDIC Extended Binary Coded Decimal Interchange Code
EER Execution Error Report
ETT Exception Threshold Table
IC Interexchange Carrier
ID Identification
IPM Interruptions Per Minute
ISA Indicate Status Application
MCL Manual Control List
MER Misrouted Error Report
MNL Master Number List
MOD Modify
NCD Non-Customer Data
NLC Network List Change
NM Network Management
NMP NM Parameter
NSO Network SSP Overflow
OSD Overflow of Sample Data
POTS Plain Old Telephone Service
RCU Response to Updating Call Processing
Record REPT Report
RSP Response
RTRV Retrieve
SCP Service Control Point
SDR Scheduled Destination Report
SMS Service Management System
SNR Scheduled Non-purchased Area of Service Report
SPF Specification File
SS7 Signaling System Number 7
SSL Special Study List
SSP Service Switching Point
SSR Special Study Report
STP Signal Transfer Point
SVR Scheduled Vacant Code Report
TELL Tell (notify)
UAL User Application Layer
UCR Update Customer Record
UPD Update