You are here: CSP Developer’s Guide: Common Channel Signaling > 2 Introduction to SS7 > TCP/IP with SS7
Overview
Transmission Control Protocol/Internet Protocol (TCP/IP) provides communication between an SS7 card and a host. The SS7 card, enabled with a local host, communicates directly with the host by using Ethernet technology. The local host uses TCP/IP over a direct Ethernet connection to communicate with the host. An Ethernet connection for each SS7 card is required and each SS7 card must be on the same network as the Matrix Controllers. The communication scheme for a local host is similar to the way the Matrix Controller communicates with a host. Physically, the local host can be on the same computer as the Matrix Controller host or it can be on a separate host computer, depending on the user’s hardware setup.
SS7 TCAP/SCCP Local Host Connection
The direct connection between an SS7 local host and a host is configured by using the SS7 SCCP/TCAP Configure (0x77) message. Once configured, SCCP/TCAP traffic is routed to and from the SS7 local host. Only the PPL Event Request, PPL Event Indication, and Poll messages are sent over this connection. All other messages must go through the standard host-Matrix Controller connection or they will be rejected.
Each SCCP/TCAP stack/subsystem can be configured to use an SS7 local host using the SS7 SCCP/TCAP Configure message. The default host for each stack/subsystem is the primary Matrix Controller. Whether you use a SS7 local host or Matrix Controller host, configuration is performed on a per stack/subsystem basis. You can query the current host configuration using the SS7 SCCP/TCAP Query (0x78) message.
A Matrix Controller card switchover or reset will not impact TCAP transactions over the SS7-host connection.
A TCAP direct host connection is implemented by adding a thin layer on top of the current TCAP message routing function. TCAP/SCCP software is modified to keep track of the host information when receiving a PPL event request from the host. Configuration and query options are provided for the TCAP direct host routing. Whether you use a SS7 local host or Matrix Controller host, configuration is performed on a per stack/subsystem basis. See figure below for the architecture overview.
Figure 2-7 Architecture Overview
The SS7 TCAP/SCCP Local Host Connection is supported with redundant SS7 cards. When an SS7 card switchover occurs, it is possible that some messages will get lost. Always send or receive the messages to the active card only when cards are in the active or standby mode. When the active card resets, the SS7 card switchover starts. Then, the host can communicate with the standby card directly. See Configuring SS7 Card Redundancy in the Configuration section.
Transmission Control Protocol (TCP) protocol messaging is used to optimize response time to and from the local host. A message must first be received from the host so that the port number can be stored for use in subsequent indications. Dialogic’s SS7 card design allows for a maximum of 65,536 sequence numbers on the card. The sequence numbers indirectly have an impact on the retry mechanism for CSP-based (service card) messages. The retry mechanism allows the service card to resend any unacknowledged messages to the host on a regular interval for a defined number of retry times. With the use of the direct TCP/IP link between the service card and the host, a high volume of messages can be processed in a given time period, which in turn will often result in a large number of unacknowledged messages outstanding. Two-hundred CSP-based messages can be saved.
A Poll (0xAB) message is sent to the host from each SS7 card every two seconds or whenever there is an SS7 card state change. The Poll Interval Configure and Poll Request messages, as well as the Host Link Failure Detection feature, are not supported in this implementation of the SS7 card-to-host polling.
The TCAP dialog timeout feature allows out-of-date dialogs to be aborted when the dialog does not get terminated correctly and the dialog ID is hanging. This may occur, for example, when messages get dropped during an SS7 card switchover. When a dialog timeout occurs, TCAP will try to abort the dialog using the abort reason defined in component, TCAP TUSI (TCAP User Interface - 0x70), using Config Byte 0x07. It will also send a new TCAP PPL event "Dialog timeout abort" to the host using PPL Event ID, 0x20, in the TCAP TUSI component. The TCAP dialog timeout timer is measured as "how long the dialog is idle." In other words, how long there are no messages exchanged for a dialog.
The TCAP dialog timeout feature is enabled with Config Byte 0x06 in component TCAP TUSI. The dialog timeout threshold timer is also configurable using the PPL Timer, 0x01, in component, TCAP DHA (TCAP Dialog Handling - 0x75).
The PPL information for both ANSI and ITU standards related to this feature is provided in SS7 PPL Information.