What is the OCSS7 TCAP Stack ?

The OCSS7 TCAP Stack is a Java component that is embedded in the CGIN Unified RA and the IN Scenario Pack to provide OCSS7 support. The TCAP stack communicates with the SGC via a proprietary protocol.

Tip 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 Connectivity

After the CGIN Unified RA is activated the OCSS7 TCAP stack uses one of two procedures to establish communication with the SGC stack:

  1. The newer, and recommended, ocss7.sgcs registration process, introduced in release 1.1.0.

  2. The legacy ocss7.urlList registration process, supported by releases up to and including 3.1.

ocss7.sgcs Connection Method

This connection method:

When correctly configured, all TCAP stacks in the Rhino cluster will be connected to all available SGCs in the OCSS7 cluster simultaneously, with every connection servicing traffic. This is sometimes referred to as the Meshed Connection Manager because of the fully meshed network topology it uses.

Load Balancing

Dialogs are load balanced across all active connections between the SGCs and the TCAP stacks. An SGC that receives traffic from the SS7 network will round-robin new dialogs between all TCAP stacks that have an active connection to it. Similarly, each TCAP stack will round-robin new outgoing dialogs between the SGCs it is connected to.

If a configured connection is down for any reason the TCAP stack will attempt to re-establish it at regular intervals until successful.

In some OA&M or failure situations an SGC may have no TCAP stack connections. When this happens the SGC will route traffic to the other SGCs in the cluster for forwarding to the TCAP stacks. Traffic will remain balanced across the TCAP stacks.

If a new SGC needs to be added to the cluster with a new connection address then the TCAP stack configuration will need to be adjusted. This adjustment can be done either before or after the SGC is installed and configured, and the cluster will behave as described above. Updates to the TCAP stack ocss7.sgcs list can be done while the system is active and processing traffic — existing connections will not be affected unless they are removed from the list, and the TCAP stack will attempt to establish any newly configured connections.

Dialog Failover

Dialog failover occurs for in-progress dialogs when an SGC becomes unavailable to a TCAP stack.

Warning This feature does not provide failover between Rhino nodes when a Rhino node becomes unavailable. Failover between Rhino nodes is not available in CGIN {cgin-version} with any TCAP stack because CGIN itself does not provide replication facilities.

Under normal operating conditions a TCAP dialog continues to use the same connection between the TCAP stack and the SGC for the lifetime of that dialog. If that connection becomes unavailable (i.e. the SGC is unreachable or down) then the Dialog Failover feature is used to migrate the dialogs associated with that connection (and by extension, the SGC) to an alternative SGC in the same cluster. In this way it is possible to continue sending and receiving messages on those dialogs.

For example, TCAP stack A is connected to SGCs 1 and 2 with connections C1 and C2 respectively. If SGC 2 terminates unexpectedly, all dialogs associated with connection C2 will begin to use connection C1 instead. All traffic received by the SGCs for those dialogs will now be sent to the TCAP stack via connection C1, hosted on SGC 1.

It is important to note that dialogs failover between SGCs, not TCAP stacks. For dialog failover to work there must be an existing connection between the original TCAP stack and at least one substitute SGC which is capable of accepting a failed over dialog. Dialogs which cannot be failed over to a replacement SGC will be dropepd and any in-flight messages lost.

Note Failure recovery can never be perfect — network messages currently being processed at the time of failure will be lost — so some dialogue failure must be expected.

Legacy ocss7.urlList Connection Method

Warning This connection method is deprecated and should not be used for new installations. Existing installations are strongly recommended to migrate to the ocss7.sgcs connection method.

In this method the TCAP stack:

  1. Is configured with the ocss7.urlList property populated with the address of each SGC’s node manager ( stack-http-address:stack-http-port).

  2. When activated:

    1. The TCAP stack connects to the first SGC node manager in that list.

    2. On successful connection to a node manager the node manager responds with the address of an SGC’s data socket.

    3. The TCAP stack then connects to the indicated data socket.

    4. On failure to either connect to a node manager, the indicated data socket, or later failure of that established connection the process is repeated with the next node manager.

This connection method is not recommended because:

  • It does not provide dialog failover capability.

  • It only has a partial load-balancing implementation: in the event that one SGC fails the TCAP nodes will reconnect to another SGC in the cluster. Over time this can result in all TCAP stacks being connected to a single SGC. Should this occur manual rebalancing of the TCAP stack connections will be required.

Rebalancing TCAP Stack Data Transfer Connections
Tip The need to rebalance TCAP stack connections can be completely avoided by using the recommended ocss7.sgcs connection method.

When an SGC node joins a running SGC cluster (for example, after a planned outage or failure), the existing TCAP stack connections are not affected. That is, the TCAP stack connections remain connected to whichever SGCs they were previously connected to. The newly joined SGC will have no TCAP stack connections until the next time a TCAP stack reconnects.

In the worst case scenario this can result in a single SGC servicing all of the TCAP stacks whilst the other SGCs service none.

This can be mitigated by performing a rebalancing procedure as described next.

Example rebalancing procedure
Note 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:

  1. 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.

  2. Deactivate the CGIN Unified RA entity on one of the Rhino nodes.

  3. Wait for the deactivated CGIN Unified RA entity to become STOPPED.

  4. Activate the previously deactivated CGIN Unified RA entity,

Tip
Per-node activation state

For details of managing per-node activation state in a Rhino Cluster, please see 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 OCSS7 TCAP Stack.

Parameter

Usage and description

Active
Reconfig?

Values

Default

stack

Short name of the TCAP stack to use.

✘

for the OCSS7 TCAP Stack, this value must be ocss7

tcap-variant

TCAP variant to use.

✘

ITU or ANSI

ITU

default-tcap-version

The TCAP version to use where this has not been specified (outbound dialogs) or cannot be automatically derived from the ProtocolVersion field of the DialoguePortion (inbound dialogs).

This affects some encoding choices, such as use of ParamSet when encoding Reject components, bounds on private operation and error codes, and whether to use a Response or an Abort package when a dialog must be aborted.

✘

1988 (ANSI TCAP only) or 2000

2000

ocss7.schThreads

Maximum number of threads used by the scheduler. Number of threads used to trigger timeout events.

✘

in the range 1 - 100

10

ocss7.schNodeListSize

Number of events that may be scheduled on a single scheduler thread.

✘

in the range 1000- 41943040 or 0 (autosize)

ocss7.schNodeListSize * ocss7.schThreads should be directly proportional to
(maxExpectedConcurrentInvokeTimers + 1) * ocss7.trdpCapacity (the maximum number of open dialogs).

If this value is set too low, then some invoke and activity timers may not fire, potentially leading to hung dialogs.

The higher this value is, the higher the memory requirements of the TCAP stack.

0

ocss7.taskdpCapacity

Maximum number of inbound messages and timeout events that may be waiting to be processed.

✘

in the range 1000 - 41943040 or 0 (autosize)

ocss7.taskdpCapacity should be directly proportional to
ocss7.trdpCapacity (the maximum number of open dialogs)

0

ocss7.trdpCapacity

Maximum number of opened transactions (dialogs).

✘

in the range 1000 - 2097152

100000

ocss7.wgQueues

Number of threads used by the worker group to process timeout events and inbound messages.

✘

in the range 1 - 100

100

ocss7.wgQueuesSize

Maximum number of tasks in one worker queue.

✘

in the range 1000 - 41943040 or 0 (autosize)

ocss7.wgQueues * ocss7.wgQueuesSize should be directly proportional to
2 * ocss7.taskdpCapacity (the maximum number of triggered timeout and inbound messages)

0

ocss7.senderQueueSize

Maximum number of outbound messages in the sender queue.

✘

in the range 1000 - 41943040 or 0 (autosize)

(if less than default value the default value is silently used)

ocss7.senderQueueSize is directly proportional to
ocss7.trdpCapacity (the maximum number of open dialogs)

0

ocss7.sgcs

Comma-separated list of SGCs to connect to. Only one of ocss7.sgcs or ocss7.urlList may be configured at a time, and this is the recommended one - see TCAP Stack and SGC Stack connectivity for details.

If both ocss7.sgcs and ocss7.urlList are unset, then a configuration of ocss7.sgcs is assumed with no configured connections.

✔ *

comma-separated list in the format address:port,
pointing to the listening addresses of SGC data ports within the SGC stack cluster

unset

ocss7.urlList

Comma-separated list of URLs used to connect to legacy TCAP Manager(s). Only one of ocss7.sgcs or ocss7.urlList may be configured at a time, and ocss7.sgcs is the recommended one - see TCAP Stack and SGC Stack connectivity for details.

✔ *

comma-separated list in the format address:port,
pointing to the listening addresses of TCAP Managers within the SGC Stack cluster

unset

ocss7.urlList.retrySleep

Wait interval in milliseconds between subsequent connection attempts for the ocss7.urlList.

✔

in the range 0 - 600000

not related to single URLs on the list (but the whole list)

1000

ocss7.local-ssn

SSN number used when the local-sccp-address property does not provide a SSN (for example, if set to auto).

✘

in the range 2 - 255

ocss7.heartbeatEnabled

v1.0.0 protocol variant only - 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. v2.0.0 protocol variant - heartbeat is always enabled.

✘

true or false

true

ocss7.heartbeatPeriod

The period between heartbeat sends in seconds. Heartbeat timeout is also a function of this value, as described in Stack Originated Heartbeat Configuration. The value configured here must be smaller than the value of com.cts.ss7.commsp.server.recvTimeout given to the SGC.

✘

2 or larger

5

* 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.

ANSI TCAP

Starting with SGC version 2.2.0 and CGIN version 2.0.0, the SGC and OCSS7 TCAP stack support ANSI TCAP (T1.114-2000, T1.114-1988).

Requirements for use of ANSI TCAP:

  • The TCAP stack must be configured to use the ocss7.sgcs connectivity method.

  • The SGC must be at least version 2.2.0.0. Older SGCs do not support ANSI TCAP.

The SGC does not require any specific configuration to use ANSI TCAP; it is able to support both ITU TCAP and ANSI TCAP clients simultaneously.

To configure the TCAP stack to use ANSI TCAP:

  • Set the CGIN configuration property tcap-variant. A value of ITU indicates ITU TCAP, and a value of ANSI indicates ANSI TCAP.

  • Set the CGIN configuration property default-tcap-version. This specifies the TCAP version to use where CGIN is unable to determine this from the ProtocolVersion field of the DialoguePortion (inbound dialogs), or where it has not been specified for outbound dialogs.

See Configuring the TCAP stack for further information.

ANSI SCCP

From SGC version 2.1.0.x and CGIN version 1.5.4.3, the SGC and OCSS7 TCAP stack support both ITU and ANSI SCCP.

SCCP Variant

The TCAP stack’s choice of SCCP variant is configured via the local-sccp-address CGIN configuration property. A value of C7 indicates ITU SCCP, and a value of A7 indicates ANSI SCCP.

To configure the SGC, please see SCCP variant configuration.

The TCAP stack and the SGC must be configured for the same SCCP variant. Furthermore, use of ANSI SCCP also requires use of the ocss7.sgcs connectivity method as the legacy ocss7.urlList method does not support the advanced feature negotiation required to successfully configure for ANSI SCCP.

The table below shows the supported configurations:

SGC sccp-variant

TCAP Stack local-sccp-address Type

C7

A7

ITU

ocss7.urlList, ocss7.sgcs

✘

ANSI

✘

ocss7.sgcs

ANSI Point Codes

Tip
ANSI SCCP point code configuration recommendations

Care must be taken when configuring ANSI SCCP point codes via the simple integer format supported by CGIN and the SGC as CGIN parses this value according to ANSI SCCP encoding standards. The SGC parses this value according to ANSI MTP/M3UA standards. The two standards differ in the order in which they process the network, cluster and member fields.

Both CGIN and the SGC support specification of ANSI SCCP point codes in N-C-M format and it is recommended that this format is used in preference to the simple integer format.

Connection Heartbeat

The data connection between the TCAP stack and the SGC supports a configurable heartbeat consisting of:

  1. A heartbeat request/response message pair

  2. TCAP stack side timeout detection

  3. SGC side timeout detection

The heartbeat configuration method and behaviour depends on the combination of the CGIN and SGC version. The table below summarizes how the heartbeat must be configured according to these:

CGIN 1.5.2.x CGIN 1.5.3.x and newer

SGC 1.0.1.x

legacy

legacy

SGC 1.1.0.x and newer

legacy

stack

stack

This heartbeat configuration method requires CGIN 1.5.3 or newer, plus SGC 1.1.0 or newer.

The heartbeat period is configured in the TCAP stack by setting the TCAP stack ocss7.heartbeatPeriod to the desired value (in ms). This value is automatically communicated to the SGC. As a result the heartbeat is configured per RA entity and may be different for different entities.

The TCAP stack sends a heartbeat ping message at the configured interval. On receipt of a ping the SGC will respond with a pong.

If the SGC does not receive the ping within 2 * ocss7.heartbeatPeriod ms of the previous ping or connection establishment it will mark the connection as failed and close it.

If the TCAP stack does not receive a pong before sending its next ping (i.e. within ocss7.heartbeatPeriod ms) it will mark the connection as failed and close it.

legacy

This heartbeat configuration method must be used if either of CGIN 1.5.2 or SGC 1.0.1 is being used.

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.

Warning 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.