You configure the CGIN RA frontend for the Signalware ITU TCAP stack by managing resource adaptor entity properties.

Tip
Manage like any other resource adaptor entity

You can manage the CGIN RA configuration the same as you would any other resource adaptor entity configuration — for example, using rhino-console’s createraentity command.

The Signalware TCAP stack supports the following configuration properties:

Property
What it does

How to configure it

 
stack

Controls which TCAP stack the CGIN RA entity should use.

To use the Signalware TCAP stack, set stack=signalware.

Warning Changes to this property will only take effect when the RA entity is next activated. 
signalware.backends

Configures which backend processes to connect to.

Must be specified when the Signalware TCAP stack is used. The property is a comma-separated list of host:port values identifying the backend TCP ports to connect to. The host and port should correspond to the configured backend CE and -port values. Because the comma character has special meaning when entering configuration properties, the entire value should be quoted when more than one backend is configured.

Warning For correct operation, all backends configured for a particular RA entity should be equivalent — they should be configured for the same SS7 variant, logical SS7 node, and local SSN. 
signalware.base-weight

Specifies "full-rate" node weights per node.

Comma-separated list of items. One simple numeric value must be included — this is the weight used for nodes not otherwise specified. Optionally, additional {nodeID,..}weight values may be specified to provide different weights for different nodes. For example, the value 100,{101}50,{102,103}75 specifies a weight of 50 for node 101, a weight of 75 for nodes 102 and 103, and a default weight of 100 for all other nodes.

Each weight is a positive integer used to balance incoming load between nodes. The values have no particular unit other than relative to each other. A node will receive new dialogs in proportion to its weight; for example, two nodes with weights of 10 will receive about the same number of dialogs each, and a node with a weight of 20 will receive twice as many as a node with a weight of 10.

Tip One approach is to treat them as percentages and assign 100 to the busiest node, with smaller values for nodes that take less load.
Note The actual weight used for a particular node is the per-node weight specified here, modified by the function defined by signalware.weight-function below. By default, all nodes have weight 100, and will receive an even proportion of incoming load. 
signalware.weight-function

Defines the weight function applied to "full-rate" weights, to find the actual rate to use; can be used to gradually increase load on a newly-joined node without immediately swamping it with traffic.

The function is specified as a series of comma-separated values
S(1),T(1),S(2),T(2),…​,S(N-1),T(N-1),S(N) where:

  • S(i) is the multiplier (in the range [0.0 .. 1.0]) of the "full-rate" weight to use in state (i)

  • T(i) is the total number of dialogs that must be received on a particular node before moving to state (i+1).

For example, the default specification of

0.01,10,0.10,1000,0.50,5000,1.00

defines a function:

for dialogs state use a weight of
[ ] * per-node weight		 (= % of normal load) 
0-10
 
1
 
0.01
 
1%
 
11-1000
 
2
 
0.10
 
10%
 
1001-5000
 
3
 
0.50
 
50%
 
5000+
 
4
 
1.00
 
100%
Note If a node has a non-zero per-node weight, then the weight after applying the weight function is forced to be at least 1. Nodes with a zero per-node weight will always use a weight of 0. 
signalware.fiber-map-size

Specifies the number of fibers used to process incoming messages. Larger values may provide more concurrency, but also increase memory usage slightly.

This property should not need modification unless you are tuning the TCAP fiber pool configuration. In that case, this value must be at least as large as the value of the
tcap-fibers.queue-size common RA property.

Warning Changes to this property will only take effect when the RA entity is next activated. 
signalware.dialog-allocation-timeout

Specifies the maximum time, in milliseconds, an SBB will block when waiting to create an outgoing dialog.

Occasionally, creation of a new outgoing dialog requires waiting for the backend process to allocate a new dialog identifier. The SBB creating the dialog will block while this happens. To prevent SBBs from blocking indefinitely, this property controls how long the RA will wait for the allocation to complete before giving up and throwing an exception to the calling SBB.

 
signalware.dialog-pool-size

Specifies the size of the dialog pool used to satisfy dialog creation requests.

The frontend maintains a pool of preallocated dialog identifiers so that it can immediately satisfy requests from an SBB for a new outgoing dialog without needing to block. This property controls the size of the pool.

The pool is refilled asynchronously to dialog requests. If the pool becomes empty, requests for new outgoing dialogs must block while the backend allocates a new dialog.

The preallocated dialogs count towards the per-backend dialog limit that applies to both incoming and outgoing dialogs. Each Rhino node allocates one pool per backend, so each backend in an N-node cluster may have up to N * signalware.dialog-pool-size dialogs reserved by these pools.

Warning Increasing this value too much may cause backends to run out of available dialogs.
Previous page