This section of the manual covers the installation, basic configuration, and control of the SGC component of OCSS7.

Tip The Rhino-side component of OCSS7, the TCAP stack, is automatically installed with CGIN and has no special installation procedure or requirements beyond those of Rhino and CGIN. Information on configuring the TCAP stack component can be found in TCAP Stack configuration in the CGIN manual.

Checking prerequisites

Before installing OCSS7, make sure you have the required:

Before attempting a production installation please also see Network Architecture Planning.

Configuring network features

Before installing OCSS7, please configure the following network features:

Feature What to configure

IP address

Make sure the system has an IPv4 or IPv6 address and is visible on the network.

Host names

Make sure that the system can resolve localhost to the loopback interface.


Ensure that any firewall installed is configured to permit OCSS7 related traffic. The rules required will depend on the Hazelcast network configuration chosen. See the OCSS7 manual section Hazelcast cluster configuration and the Hazelcast 3.7 Reference Manual section Setting Up Clusters for more details on Hazelcast network configurations.

In its default configuration the SGC uses multicast UDP to discover other cluster members:

  • The default UDP port number is 14327

  • Multicast addresses are, by definition, in the range ( - or ff00::/8 for IPv6. OCSS7 by default uses address

Additionally, Hazelcast uses TCP to form connections between cluster members. By default it listens on all available network interfaces for incoming TCP connections. This uses ports in the range 5701 through 5799.

TCP is also used for intra-node communication (comm switch) and SGC to TCAP stack communication. The ports and addresses for these are user configurable and described in General Configuration.

SCTP is used by M3UA assocations. See M3UA Configuration.

IPv6 considerations
When using IPv6 addressing, remember to configure the PREFER_IPV4 property in the SGC_HOME/config/sgcenv file. For details, please see Configuring SGC_HOME/config/sgcenv.

User process tuning

Ensure that the user that OCSS7 will be running under has a soft limit of no less than 4096 user processes.

The number of permitted user processes may be determined at runtime using the ulimit command; for example ulimit -Su

This value may be changed by editing /etc/security/limits.conf as root, and adding (or altering) the line:

sgc_user soft nproc 4096

It may also be necessary to increase the hard limit:

sgc_user hard nproc 4096

SCTP tuning

For optimal performance, tune these kernel parameters:

Parameter Recommended value What it specifies



Default receive buffer size (in bytes)



Default send buffer size (in bytes)



Maximum receive buffer size (in bytes)

This value limits the so-rcvbuf parameter. For details, please see Listening for and establishing SCTP associations.



Maximum send buffer size (in bytes)

This value limits the so-sndbuf parameter. For details, please see Listening for and establishing SCTP associations.


40 < rto_min < 100

Minimum retransmission timeout (in ms)

This should be greater than the sack_timeout of the remote SCTP endpoints.


40 < sack_timeout < 100

Delayed acknowledgement (SACK) timeout (in ms)

Should be lower than the retransmission timeout of the remote SCTP endpoints.



SCTP heartbeat interval (in ms)

Kernel parameters can be changed
  • at runtime using sysctl command; for example: sysctl -w net.core.rmem_max=2000000

  • or set permanently in /etc/sysctl.conf file.

SGC Installation

Unpack and configure


The following instructions use SGC_HOME to represent the path to the SGC installation directory.

To begin the SGC installation and create the first node:


Unpack the SGC archive file



(replacing with the correct file name)

This creates the distribution directory, ocss7-X.X.X.X, in the current working directory.


Make sure that the JAVA_HOME environment variable is set to the location of the Oracle JDK installation. (for JDK installation, see the Operating System documentation and/or JDK vendor documentation).


Configure basic cluster / node information

If your installation will use more than a single node in a SGC cluster, then:

  • Customize the ss7.instance property in SGC_HOME/config/ to a value unique among all other nodes in the SGC cluster.

  • Define a cluster name through the property in SGC_HOME/config/ The value of this property must be the same for all nodes that form a particular cluster.

If you are planning to use more than one SGC cluster in the same local network then:

  • Set the property in SGC_HOME/config/ to a value unique among all other clusters in the same local network.

Creating additional nodes

After installing the first SGC node in a cluster, you can add more nodes by either:

  • copying the installation directory of an existing node, and changing the ss7.instance property in SGC_HOME/config/ to a value unique among all the other nodes in the cluster.


  • repeating the installation steps for another node,

  • setting the ss7.instance property in SGC_HOME/config/ to a value unique among all other nodes in the cluster,

  • setting the in SGC_HOME/config/ to the value chosen as cluster name, and

  • repeating any other installation customization steps.

Layout of the SGC installation

Example 1. Installation directory contents

A typical SGC installation contains these subdirectories:

Directory Contents


(SGC installation directory)

  • main SGC Java Archive


SGC management scripts


command line interface installation, including start scripts, configuration, and logs


configuration files which may be edited by the user as required


supplementary documentation included as a convenience, such as SNMP MIB files


Java libraries used by the SGC


third-party software licenses


log output from the SGC


persisted cluster configuration (sgc.dat) and temporary files used by the SGC management scripts

Running the SGC

SGC operations


The SGC script expects the JAVA_HOME environment variable to be set up and point to a valid JVM version 11 (expects executable file JAVA_HOME/bin/java).

The SGC is started and stopped using the SGC_HOME/bin/sgc script.

The sgc script runs SGC under a watchdog: if the SGC process exits for an unrecognized reason it is automatically restarted. Output from the SGC and from the watchdog script is redirected into a startup log file. The startup log files are in SGC_HOME/logs directory and are named startup.<startup-time>. If startup fails for any reason, details about the failure should be available in the startup file.

The sgc script is configured in SGC_HOME/config/sgcenv. The sgcenv file contains JVM parameters which cannot be provided in the file.

The sgc script can be run with the following arguments:

Command argument Optional arguments Description


--jmxhost <host>
--jmxport <port>

Starts the SGC using the configuration from SGC_HOME/config/sgcenv.

  • The --nowait argument specifies that the startup script does not verify if SGC has started successfully, but just initializes start and exits.

  • The --jmxhost and --jmxport arguments allow specifying different JMX listening sockets than the one defined in SGC_HOME/config/sgcenv.



Stops the SGC. Without the --immediate argument, a graceful shutdown is attempted. With --immediate, processes are killed.


--jmxhost <host>
--jmxport <port>

Equivalent of stop, then start.


--jmxhost <host>
--jmxport <port>

Runs the SGC in test mode. In test mode, SGC runs in the foreground; and logging is configured in log4j2.test.xml, which prints more information to the console.


--jmxhost <host>
--jmxport <port>

Runs the SGC in foreground mode. SGC is not demonized.


Prints the status of SGC and returns one of these LSB-compatible exit codes:

  • 0 = the SGC is running

  • 1 = the SGC is dead and the SGC_HOME/var/ file exists

  • 3 = the SGC is not running

For example:

Start SGC

$SGC_HOME/bin/sgc start
$SGC_HOME/bin/sgc start --nowait --jmxport 10111 --jmxhost

Stop SGC

$SGC_HOME/bin/sgc stop
$SGC_HOME/bin/sgc stop --immediate

Check SGC status

$SGC_HOME/bin/sgc status

Configuring SGC_HOME/config/sgcenv

The SGC_HOME/config/sgcenv file contains configuration parameters for the sgc script. The following settings are supported:

Variable name Descriptions Valid Values Default


Location of the JVM home directory.


Host that SGC should bind to in order to listen for incoming JMX connections.

IPv4 or IPv6 address


Port where SGC binds for incoming JMX connections.

It is not recommended to use a port in the emphemeral range as these are used for short-lived TCP connections and may result in the SGC failing to start if the port is in use by another application. The emphemeral port range may be queried with cat /proc/sys/net/ipv4/ip_local_port_range.




Whether or not the JMX connection should be secured with SSL/TLS.

true, false



Whether or not the SGC should require a trusted client certificate for an SSL/TLS-secured JMX connection.


Path to the configuration file with properties used to secure the JMX management connection.


Password used during generation of the key store and trust store used to secure the JMX management connection.



Maximum size of the JVM heap space.

For details, please see Configuring the Java Heap.


Initial size of the JVM heap space.


The size (minimum and maximum) of the JVM new generation.



Full override of default garbage collections settings.


Additional JVM parameters.

Modifications should add to the existing JVM_PROPS rather than overriding it. For example: JVM_PROPS="$JVM_PROPS -Dsome_option".


The log4j2 configuration file to be used in normal mode (start/restart/foreground).


The log4j2 configuration file to be used in test mode.


Location of the SGC properties file.


Whether or not the watchdog is enabled. Disabling the watchdog may be required if the SGC is run under the control of some other HA systems.

0 = watchdog is enabled
1 = start SGC in background without watchdog script


Enables additional script information.

0 = no additional debug information
1 = additional information enabled


Prefers using IPv4 protocol. Set value to false to enable IPv6 support.

true = use only IPv4
false = use both IPv4 and IPv6



On NUMA architecture machines, this parameter allows selecting specific CPU and memory bindings for SGC.


On non-NUMA architecture machines, this parameter may be used to set SGC affinity to specific CPUs.

JMX Connector configuration variables

SGC_HOME/config/sgcenv contains additional variables used to configure a secure JMX management connection. For details, please see Securing the SGC JMX management connection with SSL/TLS.

Configuring the Java Heap

The Java Virtual Machine’s MAX_HEAP_SIZE must be appropriately configured for the SGC. If insufficient heap is configured, then the result may be:

  • Frequent and/or prolonged garbage collections, which may have a negative impact on the SGC’s performance.

  • SGC restarts caused by the JVM throwing OutOfMemoryError.

The main factors affecting the selection of an appropriate value are:

  • The base SGC requires a certain amount of heap.

  • The size of the configuration MML.

  • The configured maximum concurrent TCAP transactions (sgc.tcap.maxTransactions)

MAX_HEAP_SIZE is no longer dependent on the number of connected TCAP peers or migrated prefixes.

Factor Recommendation

Base SGC


This value allows for an SGC configured for 1 million sgc.tcap.maxTransactions with a bare minimum MML configuration, with only a node configured and no signalling links or global title configuration.

The amount required is platform and JVM dependent. An estimation of the base SGC requirements may be obtained by loading a minimal MML configuration into a test SGC, and then using the jmap tool to print a heap summary. The resulting value should then be doubled or even tripled to allow for efficient garbage collection.

Configuration MML Size


Each create-X configuration MML instruction requires heap storage, both to store the configuration data and to enable the configuration.

As each configuration differs substantially it is not possible to provide generic guidelines. An estimation of a configuration’s minimum requirements may be obtained by loading the full MML configuration into a test SGC, and then using the jmap tool to print a heap summary.

Maximum concurrent TCAP transactions

1 million transactions requires no additional heap allowance as this is included in the base SGC figure above.

10 million transactions requires approximately 250MB additional heap.

100 million transactions requires approximately 2.5GB additional heap.

The maximum number of concurrent TCAP transactions is configured in sgc.tcap.maxTransactions. See Static SGC configuration.

Installing SGC as a service

To install SGC as a service, perform the following operations as user root:


Copy SGC_HOME/bin/sgcd to /etc/init.d .

# copy $SGC_HOME/bin/sgcd /etc/init.d


Grant execute permissions to /etc/init.d/sgcd:

# chmod a+x /etc/init.d/sgcd


Create the file /etc/sysconfig/sgcd. Assuming that the SGC is installed in /opt/sgc/PC1-1/PC1/current as user sgc, the file would have the following content:



Activate the service using the standard RedHat command:

# chkconfig --add sgcd
Previous page Next page