What is the SGC TCAP Stack ?
The SGC TCAP Stack is a Java component that is embedded in the CGIN Unified RA and the Scenario Simulator. The TCAP Stack communicates through a proprietary TCP/IP-based protocol with the SGC Stack.
|
For a general description of the TCAP Stack Interface defined by the CGIN Unified RA, please see Inside the CGIN Connectivity Pack. |
TCAP Stack and SGC Stack cooperation
Below is a high-level overview diagram, followed by descriptions, concentrating on components directly involved in TCAP Stack and SGC Stack cooperation. SGC Stack components are the items colored yellow; components colored blue (and similar) are provided by Rhino platform or are part of Operating System environment.
-
TCAP Manager is the software component that the TCAP Stack queries initially, to register within the SGC Stack and establish a data transfer connection.
-
TCAP Peer is the software component within the SGC Stack Node that manages the data transfer connection with the TCAP Stack.
|
|
The TCAP Manager listen address is configured as part of configuring the SGC Node. For details, please see the stack-http-address and stack-http-port attributes in General Configuration.
|
TCAP Stack registration process
After the CGIN Unified RA is activated, the SGC TCAP Stack goes through a two-phase process to establish communication with the SGC Stack:
-
Assigning to the connection to the TCAP Manager an SGC Node, where the data transfer connection should be established.
-
Connecting to SGC Stack Node, to register it within the SGC Cluster, and establish the data transfer connection.
Detailed Stack registration steps
Phase 1
-
The TCAP Stack connects to the first active TCAP Manager from a user-provided list of TCAP Manager addresses (corresponding to the nodes of the SGC Stack Cluster).
-
After the connection with the TCAP Manager is established, the TCAP Stack sends a request containing information about the SSN represented by the TCAP Stack.
-
The TCAP Manager selects an SGC Node within the cluster that will be responsible for managing the data transfer connection with the TCAP Stack.
-
The address where the selected SGC Node listens for data transfer connections is sent back as part of the response to the TCAP Stack.
Phase 2
-
The TCAP Stack connects to the selected SGC Node and begins registration by sending a handshake message containing its SSN and version of the data transfer protocol that it supports (this is a custom protocol used to exchange TCAP traffic between the TCAP Stack and the SGC Node).
-
The SGC Node assigns a TCAP local transaction prefix to the TCAP Stack,
-
The SGC Node creates a TCAP Peer responsible for managing the data transfer connection with the TCAP Stack, and updates the cluster state with information about the newly connected TCAP Stack.
-
The TCAP local transaction prefix is sent to the TCAP Stack as part of a successful handshake response.
At this stage, the TCAP Stack is operational and can both originate and receive TCAP traffic.
|
How the TCAP Manager selects an SGC Node
The goal of the node-selection process is to load balance the number of connected TCAP Stacks between SGC Nodes within an SGC Cluster. The TCAP Manager does that by following a very simple algorithm:
|
|
When Phase 2 registration fails…
The TCAP Stack can fail to register with the SGC Node. Possible reasons include:
To see why registration fails, check the log file. |
Data transfer connection failover
After the TCAP Stack detects data transfer connection failure, it repeats the registration process by attempting to establish a connection to one of the configured TCAP Managers. Connection attempts are in order of TCAP Manager addresses defined by the ocss7.urlList property. This process does not differ from the standard TCAP Stack registration process, as TCAP Manager selects one of the available SGC Nodes. For proper failover behaviour, the TCAP Stack should be configured with the TCAP Manager addresses of all nodes within the SGC Cluster.
Rebalancing TCAP Stack data transfer connections
When an SGC Node joins a running SGC Cluster (for example after a planned outage or failure), the already established TCAP Stack data transfer connections are NOT affected. That is, existing TCAP Stack data transfer connections are NOT rebalanced between SGC Nodes.
Example rebalancing procedure
|
|
This example uses a basic production deployment of an SGC Cluster, composed of two SGC Nodes cooperating with the CGIN Unified RA, deployed within a two-node Rhino cluster (as depicted above). |
Imagine the following scenario:
-
Due to hardware failure, SGC Stack Node 2 was not operational. This resulted in both instances of the CGIN Unified RA being connected to SGC Stack Node 1.
-
That hardware failure is removed, and SGC Stack Node 2 is again fully operational and part of the cluster.
-
To rebalance the data transfer connections of the CGIN Unified RA entity running within Rhino cluster, that entity must be deactivated and activated again on one of the Rhino nodes. (Deactivation is a graceful procedure where the CGIN Unified RA waits until all dialogs that it services are finished; at the same time all new dialogs are directed to the CGIN Unified RA running within the other node.)
You would do the following:
-
Make sure that the current traffic level is low enough so that it can be handled by a CGIN Unified RA on a single Rhino node.
-
Deactivate the CGIN Unified RA entity on one of the Rhino nodes.
-
Wait for the deactivated CGIN Unified RA entity to become
STOPPED. -
Activate the previously deactivated CGIN Unified RA entity,
|
|
Per-node activation state
For details of managing per-node activation state in a Rhino Cluster, please see 6 Per-Node Activation State in the Rhino Administration and Deployment Guide. |
TCAP Stack configuration
General description and configuration of the CGIN RA is detailed in the CGIN RA Installation and Administration Guide. Below are configuration properties specific to the SGC TCAP Stack.
Parameter |
Usage and description |
Active |
|---|---|---|
Values |
||
Default |
||
|
Short name of the TCAP stack to use. |
✘ |
for the SGC TCAP Stack, this value must be |
||
|
Maximum number of threads used by the scheduler. Number of threads used to trigger timeout events. |
✘ |
in the range |
||
|
||
|
Number of events that may be scheduled on a single scheduler thread. |
✘ |
in the range
|
||
|
||
|
Maximum number of inbound messages and timeout events that may be waiting to be processed. |
✘ |
in the range
|
||
|
||
|
Maximum number of opened transactions (dialogs). |
✘ |
in the range |
||
|
||
|
Number of threads used by the worker group to process timeout events and inbound messages. |
✘ |
in the range |
||
|
||
|
Maximum number of tasks in one worker queue. |
✘ |
in the range
|
||
|
||
|
Maximum number of outbound messages in the sender queue. |
✘ |
in the range (if less than default value the default value is silently used)
|
||
|
||
|
Comma-separated list of URLs used to connect to TCAP Manager(s). |
✔ * |
comma-separated list in the format |
||
|
||
|
Wait interval in milliseconds between subsequent connection attempts for the |
✔ |
in the range not related to single URLs on the list (but the whole list) |
||
|
||
|
SSN number used when the |
✘ |
in the range |
||
|
Enables or disables the OCSS7 to SGC connection heartbeat. N.B. if the heartbeat is enabled on the SGC it must also be enabled here. |
✘ |
|
||
|
||
|
The period between heartbeat sends in seconds. Heartbeat timeout is also a function of this value, as described in Data Connection Heartbeat Mechanism. The value configured here must be smaller than the value of |
✘ |
|
||
|
* If a TCAP data transfer connection is established, changing this property has no effect until the data transfer connection fails and the TCAP Stack repeats the registration process.
Data Connection Heartbeat Mechanism
The data connection between the TCAP stack and SGC supports a heartbeat mechanism that can be used to detect failed connections in a timely manner. This mechanism consists of three components:
-
A heartbeat request/response message pair
-
TCAP stack side timeout detection
-
SGC side timeout detection
The heartbeat request/response message pair is enabled by setting the TCAP stack ocss7.heartbeatEnabled property to true.
This configures the TCAP stack to send a heartbeat request. The SGC will respond to any heartbeat request with a
heartbeat response message, regardless of SGC configuration. The frequency with which the heartbeat request message is
sent (and therefore also the heartbeat response) is configured with the TCAP stack’s ocss7.heartbeatPeriod configuration
parameter.
If heartbeats are enabled in the TCAP stack, then the TCAP stack will automatically perform timeout detection. If a
heartbeat response message hasn’t been seen within a period of time equal to twice the heartbeat period (2 * ocss7.heartbeatPeriod)
the connection will be marked as defective and closed, allowing the TCAP stack to select a new SGC data connection.
The SGC stack may also perform timeout detection; this is controlled by the SGC properties com.cts.ss7.commsp.heartbeatEnabled and com.cts.ss7.commsp.server.recvTimeout. When the heartbeatEnabled property is set to true the SGC will close a connection if a heartbeat request hasn’t been received from that TCAP stack in the last recvTimeout seconds.
It is important to note that if the SGC stack is configured to perform timeout detection then every TCAP stack connecting to it must also be configured to generate heartbeats. If a heartbeat-disabled TCAP stack connects to a heartbeat-enabled SGC the SGC will close the connection after recvTimeout seconds, resulting in an unstable TCAP stack to SGC connection.
