CGIN Installation and Administration Guide

This document tells you how to install and administer the OpenCloud CGIN resource adaptor.

See the CGIN Statement of Compliance for a list of supported protocols and the CGIN Compatibility Guide for details on compatible platforms and software.

Topics

Configuring the Deployment File

Adding variables to deploy.properties

Deploying the CGIN RA

Manually or automatically deploying the RA

Administering the CGIN Resource Adaptor Entity

Setting the CGIN RA’s configuration properties.

CGIN Alarms

An overview of the alarms that CGIN may raise.

Appendix A. Cluster upgrade procedures

Upgrading a cluster using the CGIN Signalware TCAP stack

Appendix B. Migrating to CGIN 2.0.x

Adapting to API and schema changes in CGIN 2.0.x.

Appendix C. Support Requests

Gathering logging for support requests.

This book does not cover stack-specific configuration — for information on OpenCloud’s OCSS7, see the OCSS7 SGC TCAP Stack documentation, or for other stacks, see Using the Mavenir Signalware TCAP Stack, and Using the Simulated TCAP Stack.

Other documentation for CGIN can be found on the CGIN product page.

Configuring the Deployment File

The first step to installing the CGIN resource adaptor is to configure the deployment file.

Modify deploy.properties

Modify the file $CGIN_CONNECTIVITY_PACK_HOME/deploy.properties, using the following variables:

Variable	Variable usage and description	Example
client.home	absolute path to a Rhino client installation; by default, this is set to assume that the CGIN connectivity pack was unpacked within an installed Rhino instance	client.home=${user.home}/RhinoSDK/client
cginra.properties	properties to use when deploying the CGIN RA; by default, this uses a simulated TCAP configuration	cginra.properties=stack=signalware,signalware.backends=turbine2:20146

Variable

Variable usage and description

Example

 client.home

absolute path to a Rhino client installation; by default, this is set to assume that the CGIN connectivity pack was unpacked within an installed Rhino instance

 client.home=${user.home}/RhinoSDK/client

 cginra.properties

properties to use when deploying the CGIN RA; by default, this uses a simulated TCAP configuration

 cginra.properties=&#x200B;stack=&#x200B;signalware,&#x200B;signalware.&#x200B;backends=turbine2:20146

Both properties must be set.

The default deployment properties are:

# Configuration settings for deployment done by ant script deploy.xml

# client.home is the absolute path to the Rhino client installation.
# As released, this assumes that the CGIN connectivity pack has been
# installed as a subdirectory of the Rhino install.
# If that assumption is not correct, change this property to the right path.
client.home=${cgin.basedir}/../client

# The entity name used by the CGIN RA.
cginra.entityname=cginra

# cginra.properties contains the resource adaptor entity configuration properties
# that should be used to initialize the CGIN RA.
#
# Examples are provided for the OCSS7, Signalware and Simulated TCAP stacks.
#
# Only one of the following is required.

# The Simulated TCAP stack.
cginra.properties=stack=tcapsim,tcap-variant=ITU,local-sccp-address="type=C7,ri=pcssn,pc=2,ssn=102",\
  tcapsim.listen-addresses=localhost:10102,tcapsim.remote-addresses=localhost:10101,tcapsim.sctp-stack=tcp

# The Signalware TCAP stack.
#cginra.properties=stack=signalware,tcap-variant=ITU,\
#  signalware.backends=turbine2:20146

# The OCSS7 TCAP stack.
#cginra.properties=stack=ocss7,tcap-variant=ITU,local-sccp-address="type=C7,ri=pcssn,pc=2,ssn=102",\
#  ocss7.sgcs=localhost:12201

Deploying the CGIN RA

Install the CGIN RA automatically by running the deployment script.

Run deploy.xml, under $CGIN_CONNECTIVITY_PACK_HOME/. For example:

$> ant -f deploy.xml

If this is the first time you create and activate a CGIN RA entity for this installation of Rhino, the TCAP stack may require additional configuration or installation steps — please see the OCSS7 SGC TCAP Stack documentation, Using the Simulated TCAP Stack, or Using the Mavenir Signalware TCAP Stack.

Administering the CGIN Resource Adaptor Entity

To administer the CGIN resource adaptor entity, set the CGIN RA’s configuration properties.

For example:

$rhino-console> updateraentityconfigproperties cginra local-sccp-address=auto

Most configuration properties may be changed at any time, and will take immediate effect if the resource adaptor entity is active. A few properties, such as the type of TCAP stack used, will not take immediate effect if changed while the resource adaptor entity is active. In this case, an alarm will be raised to warn that changes will only take effect when the entity is next activated.

The RA has a set of universal properties that apply to all CGIN RA entities, and stack-specific properties that depend on the stack that a particular entity is using:

Information on specific configuration properties for each TCAP stack is available for:

For universal configuration properties, see below.

Universal configuration properties

These are the CGIN RA universal configuration parameters:

Parameter Default Value Usage and description

 stack

 signalware

Short name of the TCAP stack to use. Can be one of

ocss7 - for the OpenCloud OCSS7 TCAP stack
signalware - for the Signalware TCAP stack
tcapsim - for the simulated TCAP stack.

Changes to this property will only take effect when the entity is next activated.

 enabled-protocols

etsi_inap_cs1,cap_v1,
cap_v2,cap_v3,cap_v4,
map

The list of protocols enabled in the RA; for example:

etsi_inap_cs1,cap_v1,cap_v2,cap_v3,cap_v4,map

 default-activity-timeout

The default dialog activity timeout, measured in milliseconds. This specifies the initial dialog activity timeout used for newly created dialogs.

 default-invoke-timeout

The default TCAP Invoke Timeout, measured in milliseconds. This specifies the invoke timeout for operations where the service has not provided an invoke timeout value.

 tcap-variant

ITU

The TCAP variant to use: ITU or ANSI

 default-tcap-version

The TCAP version to assume when this cannot be automatically determined. This may be the case for:

Inbound dialogs where the Dialogue Portion is absent, or there is no Protocol Version field in the Dialogue Portion. For example, MAP phase 1.
Outbound dialogs where a TCAP version has not been specified in the issueOpenRequest API call.

Valid options are:

ITU TCAP: 2000
ANSI TCAP: 2000 and 1988

When in 1988 mode, ANSI TCAP will:

Use Reject-in-Response to report transaction portion problems.
Format Reject components using the 1988-style formatting. i.e. ParamSet instead of ParamSequence
Dialog.sendUserAbort will send a Response without pending components instead of an Abort package.

 local-sccp-address

 auto

Used for outgoing TC-BEGIN messages if no local SCCP address is explicitly provided by an SBB.

The address should be formatted in the format that com.opencloud.slee.resources.cgin.SccpAddressParser expects.
If this property has the value auto, then the TCAP stack will automatically determine an address to use.

SCCP Address Format

Below are mandatory, point code — SSN, and global title parameters for the CGIN RA local-sccp-address configuration property.

Mandatory parameters

An SCCP address string must be formatted as comma-separated name/value pairs. The following parameters are mandatory:

Parameter Description Valid values

Parameter	Description	Valid values
type	SCCP address type	`A7`, `C7`, `CH7`, or `J7`
ri	Routing indicator	`gt`, `pcssn`, or `ssn` (`pcssn` and `ssn` are equivalent.)

 type

SCCP address type

A7, C7, CH7, or J7

ri

Routing indicator

gt, pcssn, or ssn (pcssn and ssn are equivalent.)

Point code — SSN parameters

Parameter Description Valid values

Parameter	Description	Valid values
pc	Point code	Formatted as either: a single decimal value in the range `0-16777215 (= 0xffffff)`, which supports all addressing formats up to 24-bits long expressed as a single number a `-` separated triple: If `type=C7` has been specified, an x-y-z triple is taken to mean the 3-8-3 bit fields of the zone-area-signal point address format. If `type=A7` or `type=CH7`, an x-y-z triple is taken to mean the 8-8-8 bit fields of the network-cluster-member address format. Note the reversed order when compared with the `/` separated format. a `/` separated triple: If `type=C7` has been specified, an x/y/z triple is taken to mean the 3/8/3 bit fields of the zone/area/signal point address format. If `type=A7` or `type=CH7`, an x/y/z triple is taken to mean the 8/8/8 bit fields of the member/cluster/network address format.
ssn	Subsystem number	in the range `0`-`255`

pc

Point code

Formatted as either:

a single decimal value in the range 0-16777215 (= 0xffffff), which supports all addressing formats up to 24-bits long expressed as a single number
a - separated triple:
- If type=C7 has been specified, an x-y-z triple is taken to mean the 3-8-3 bit fields of the zone-area-signal point address format.
- If type=A7 or type=CH7, an x-y-z triple is taken to mean the 8-8-8 bit fields of the network-cluster-member address format. Note the reversed order when compared with the / separated format.
a / separated triple:
- If type=C7 has been specified, an x/y/z triple is taken to mean the 3/8/3 bit fields of the zone/area/signal point address format.
- If type=A7 or type=CH7, an x/y/z triple is taken to mean the 8/8/8 bit fields of the member/cluster/network address format.

ssn

Subsystem number

in the range 0-255

Global title parameters

Parameter Description Valid values

Parameter	Description	Valid values
digits	Global title address digits
nature	Global title nature of address indicator	`unknown`, `international`, `national`, `subscriber`, or a decimal value in the range `0`-`15`
numbering	Global title number plan	`unknown`, `isdn`, `generic`, `data`, `telex`, `maritime-mobile`, `land-mobile`, `isdn-mobile`, `private`, or a decimal value in the range `0`-`15`
tt	Global title translation type	in the range `0`-`255`
national	Global title national indicator	`true` or `false`
gti	Global title indicator	If not included, this parameter will be calculated automatically. If present, this parameter will be validated against the expected value (based on the other parameters in the address).

 digits

Global title address digits

 nature

Global title nature of address indicator

unknown, international, national, subscriber, or a decimal value in the range 0-15

 numbering

Global title number plan

unknown, isdn, generic, data, telex, maritime-mobile, land-mobile, isdn-mobile, private, or a decimal value in the range 0-15

tt

Global title translation type

in the range 0-255

 national

Global title national indicator

true or false

gti

Global title indicator

If not included, this parameter will be calculated automatically.
If present, this parameter will be validated against the expected value (based on the other parameters in the address).

Global title rules

When specifying global titles, the following rules apply:

Global title parameters are only included in the returned address if digits is specified.
The global title indicator used depends on the SCCP address and parameter values, as follows:

For these SCCP addresses: If these values are specified: This global title indicator is used:

For these SCCP addresses:	If these values are specified:	This global title indicator is used:
`C7`, `J7`, and `CH7`	`nature` only	GT_0001
`tt` only	GT_0010
`numbering` and `tt`	GT_0011
`nature` and either or both of `numbering` and `tt`	GT_0100
unspecified	The number plan defaults to `unknown` and the translation type defaults to `0`.
`A7`	`tt` only	GT_0010
`tt` and `numbering`	GT_0001

C7, J7, and CH7

nature only

 GT_0001

tt only

 GT_0010

numbering and tt

 GT_0011

nature and either or both of numbering and tt

 GT_0100

unspecified

The number plan defaults to unknown and the translation type defaults to 0.

A7

tt only

 GT_0010

tt and numbering

 GT_0001

For example:

type=c7,ri=pcssn,pc=4012,ssn=123

type=c7,ri=pcssn,pc=1/245/7,ssn=123

type=c7,ri=gt,digits=34607012345,nature=national,national=true

CGIN Alarms

This document provides a list of the alarms that may be raised by CGIN:

CGIN Resource Adaptor
OpenCloud OCSS7 stack
Mavenir Signalware stack
Simulated TCAP stack

Core CGIN Alarms

Alarm Instance ID Level Description

Alarm	Instance ID	Level	Description
`activationFailed`		`CRITICAL`	This alarm is raised when the CGIN RA entity cannot be activated. It is automatically cleared when the CGIN RA entity is deactivated.
`reconfigurationFailed`	`stack`	`MAJOR`	This alarm is raised when active reconfiguration fails. See the raised alarm for the reason why active reconfiguration failed. Once the reason for the reconfiguration failure is resolved the alarm will be automatically cleared.

activationFailed

CRITICAL

This alarm is raised when the CGIN RA entity cannot be activated.

It is automatically cleared when the CGIN RA entity is deactivated.

reconfigurationFailed

stack

MAJOR

This alarm is raised when active reconfiguration fails. See the raised alarm for the reason why active reconfiguration failed.

Once the reason for the reconfiguration failure is resolved the alarm will be automatically cleared.

Stack Specific Alarms

OpenCloud OCSS7 Stack

Alarm Instance ID Level Description

Alarm	Instance ID	Level	Description
`ocss7.connectivity`	the resource adaptor entity name	`MAJOR`	This alarm is raised when a TCAP stack configured via the legacy `ocss7.urlList` method is unable to connect to the SGC cluster. It is cleared when a connection is succesfully made to the cluster.
`ocss7.noconnection`	the address of the affected connection	`MAJOR`	This alarm is raised when a TCAP stack configured via `ocss7.sgcs` is unable to connect to a configured peer. It is cleared the connection has been successfully reestablished.
`ocss7.trData`	`invokeTimer`	`WARNING`	This alarm is raised when the OCSS7 TCAP stack is unable to schedule an invoke timer. This usually occurs when `ocss7.schNodeListSize` is insufficient for the TCAP throughput. If this alarm is raised, there is a risk that some invoke timeouts may not occur. This alarm must be manually cleared as it indicates a configuration problem that must be resolved.
`ocss7.trData`	`activityTimer`	`WARNING`	This alarm is raised when the OCSS7 TCAP stack is unable to schedule an activity timer. This usually occurs when `ocss7.schNodeListSize` is insufficient for the TCAP throughput. If this alarm is raised, there is a risk that activities may be leaked if not ended through normal means (receipt/send or TC-END/ABORT). This alarm must be manually cleared as it indicates a configuration problem that must be resolved.

ocss7.connectivity

the resource adaptor entity name

MAJOR

This alarm is raised when a TCAP stack configured via the legacy ocss7.urlList method is unable to connect to the SGC cluster.

It is cleared when a connection is succesfully made to the cluster.

ocss7.noconnection

the address of the affected connection

MAJOR

This alarm is raised when a TCAP stack configured via ocss7.sgcs is unable to connect to a configured peer.

It is cleared the connection has been successfully reestablished.

ocss7.trData

invokeTimer

WARNING

This alarm is raised when the OCSS7 TCAP stack is unable to schedule an invoke timer. This usually occurs when ocss7.schNodeListSize is insufficient for the TCAP throughput. If this alarm is raised, there is a risk that some invoke timeouts may not occur.

This alarm must be manually cleared as it indicates a configuration problem that must be resolved.

ocss7.trData

activityTimer

WARNING

This alarm is raised when the OCSS7 TCAP stack is unable to schedule an activity timer. This usually occurs when ocss7.schNodeListSize is insufficient for the TCAP throughput. If this alarm is raised, there is a risk that activities may be leaked if not ended through normal means (receipt/send or TC-END/ABORT).

This alarm must be manually cleared as it indicates a configuration problem that must be resolved.

Mavenir Signalware Stack

Alarm Instance ID Level Description

Alarm	Instance ID	Level	Description
`noconnection`	the address of the affected connection	`MAJOR`	This alarm is raised when an existing connection to a backend is lost, or the initial connection cannot be established. It is automatically cleared when the connection is successfully established.
`noheartbeat`	the address of the affected connection	`WARNING`	This alarm is raised when a connection’s heartbeat is lost. This indicates that TCP/IP traffic is not flowing between CGIN and the backend. This can occur for multiple reasons, including network failure, stop-the-world activity in either CGIN or the backend, or CPU overload in either the CGIN or backend hosts. It is automatically cleared when the heartbeat is reestablished.

noconnection

the address of the affected connection

MAJOR

This alarm is raised when an existing connection to a backend is lost, or the initial connection cannot be established.

It is automatically cleared when the connection is successfully established.

noheartbeat

the address of the affected connection

WARNING

This alarm is raised when a connection’s heartbeat is lost. This indicates that TCP/IP traffic is not flowing between CGIN and the backend. This can occur for multiple reasons, including network failure, stop-the-world activity in either CGIN or the backend, or CPU overload in either the CGIN or backend hosts.

It is automatically cleared when the heartbeat is reestablished.

Simulated TCAP Stack

Alarm Instance ID Level Description

Alarm	Instance ID	Level	Description
`noconnection`	the address of the affected connection	`MAJOR`	This alarm is raised when a TCAP stack configured via `tcapsim.remote-addresses` is unable to connect to a configured peer. It is cleared the connection has been successfully reestablished.

noconnection

the address of the affected connection

MAJOR

This alarm is raised when a TCAP stack configured via tcapsim.remote-addresses is unable to connect to a configured peer.

It is cleared the connection has been successfully reestablished.

Appendix A. Cluster Upgrade Procedures

This page includes instructions for doing a live upgrade from an existing Rhino cluster that is receiving traffic through CGIN, to a new cluster that has the same configuration but different software versions (such as a new Rhino or CGIN version, or new service version if it can’t be done in a single cluster).

These procedures refer specifically to upgrading the CGIN component. They do not cover upgrading the underlying OpenCloud OCSS7 SGC stack or Mavenir Signalware stack.

Below are general information about and then instructions for performing upgrades using STP redirection, OCSS7 In-place upgrade and Signalware In-place upgrade.

About cluster upgrades with CGIN

Below is a table of possible upgrade paths for clusters using the CGIN OCSS7 TCAP stack or Signalware TCAP stack:

Old version	New version	Upgrade using STP redirect?	Upgrade in-place (Signalware)?	Upgrade in-place (OCSS7)?
1.5.x	2.0.x	Yes	Yes	Yes
2.0.x	2.0.x	Yes	Yes	Yes

Old version

New version

Upgrade using STP redirect?

Upgrade in-place (Signalware)?

Upgrade in-place (OCSS7)?

 1.5.x

 2.0.x

Yes

 2.0.x

 2.0.x

Yes

A warning about ETC/ARI dialog correlation

ETC/ARI dialog correlation arranges for inbound ARI dialogs to be directed to the same cluster node that sent the corresponding ETC. In general, dialog correlation can only happen within a single cluster. During an upgrade, there are two clusters present and receiving traffic.

If an ARI dialog is received by the "wrong" cluster (a cluster that did not send the corresponding ETC), then correlation will fail, and the ARI will not be directed to the correct cluster node. If dialog correlation is used, then care should be taken to ensure that ARI dialogs are directed to the correct cluster — for example, by configuring the service deployed in the new cluster to send ETCs that direct the ARI dialogs to an SCP address associated with the new cluster only.

Upgrades using STP redirection

This approach manages the upgrade externally to Rhino and OCSS7 or Signalware, and requires support from the STP and surrounding network, and in some configurations, support in the existing service.
It can be used for all types of upgrade.

Prerequisites

Before upgrading using STP redirection, make sure that:

Inbound TC-BEGINs are addressed to a "logical" GT. The STP translates this GT to one-of-N "physical" addresses using a load-balancing mechanism. These "physical" addresses route to a particular cluster.
Optionally, the STP may rewrite the "logical" called party address in the TC-BEGIN to the "physical" address.
The STP needs the ability to reconfigure the translation addresses in use at runtime.
The old and new clusters are assigned different "physical" addresses.
If the STP did not rewrite the "logical" called party address in the TC-BEGIN to the "physical" address, then the service must ensure that the initial responding TC-CONTINUE provides an SCCP Calling Party Address that is the "physical" address for the cluster that is responding.
Subsequent traffic uses the "physical" address using normal TCAP procedures.

Upgrade process

To upgrade using STP redirection:

1	Set up the new cluster with a new "physical" address.
2	Configure and activate the new cluster.
3	Reconfigure the STP to include the new cluster’s physical address when translating the logical GT.
4	Verify that traffic is processed by the new cluster correctly.
5	Reconfigure the STP to exclude the old cluster’s physical address when translating the logical GT.
6	Wait for all existing dialogs to drain from the old cluster.
7	Halt the old cluster.

OCSS7 In-place upgrade procedure

This upgrade process supports upgrades where the service in use may initiate outbound CGIN dialogs.
It is supported when using OCSS7 for upgrades from CGIN 1.5.x to 2.0.x and from 2.0.x to 2.0.x
The existing CGIN RA entity must be configured to connect to the SGCs using the ocss7.sgcs connection method.

1

Set up the new cluster

Install the new cluster. Ensure that the cluster ID used is different to that of the old cluster, and that files, databases, and ports used by the new cluster don’t overlap with the old cluster.
Boot the new cluster.
Ensure that Rhino is in the STOPPED state
Deploy and configure RAs and services. Configure CGIN RA entities in the same way as on the "old" cluster, pointing to the same SGC addresses.

A Rhino export from the old cluster may be useful for this step.

Now you should have the "new" cluster configured, but STOPPED, so that it is not receiving traffic.

To roll back this step, just discard your new cluster install. (No traffic is being processed by the new cluster yet.)

2

Start the new cluster

To start the "new" cluster, change the SLEE state to RUNNING. The new cluster RAs will connect to the same SGCs as the old cluster. New incoming traffic will be load balanced between the old and new clusters.
Verify that the new cluster is processing calls correctly.

To roll back this step:

Reconfigure each CGIN resource adaptor entity in the new cluster to set the RA property ocss7.sgcs to an empty string. For example:
```
updateraentityconfigproperties entityname ocss7.sgcs=
```
Wait for all dialogs in the new cluster to end.
Stop the new cluster — change the SLEE state to STOPPED.

3

Drain calls from the old cluster

For each CGIN RA entity in the old cluster, reconfigure the RA entity to set the ocss7.sgcs configuration property to be an empty string. For example:
```
updateraentityconfigproperties entityname ocss7.sgcs=
```

If upgrading the cluster from CGIN 1.5.x.y the old cluster’s ocss7.sgcs property may not be set to empty. In this case it should be set to an address that does not correspond to a live SGC or other TCP service. For example: ocss7.sgcs=invalidhost:11111. The old CGIN RA will emit warnings and alarms about not being able to connect to that address. These are expected and can be ignored.

At this point, all new dialogs will be directed to the new cluster only. The old cluster will only continue to process existing dialogs established before the draining process started.

Wait for all dialogs in the old cluster to end.

Once all dialogs have ended the connections to the SGC cluster will terminate automatically. No traffic is handled by the old cluster.

To roll back this step, for each CGIN RA entity in the "old" cluster, reconfigure the RA entity to restore the original value of ocss7.sgcs.

4

Stop the old cluster

Stop the SLEE using the stop management command.
Wait for the SLEE to reach the STOPPED state.

To roll back this step, start the SLEE.

5

Shut down the old cluster

Shut down the old cluster using the shutdown management command.

To roll back this step, restart the "old" cluster processes.

6

Schedule an upgrade of the SGC to the new version

(if needed)

Signalware In-place upgrade procedure

This upgrade process supports upgrades where the service in use may initiate outbound CGIN dialogs.
It is supported when using Signalware for upgrades from CGIN 1.5.x to 2.0.x and from 2.0.x to 2.0.x

1

Set up the new cluster

Install the new cluster. Ensure that the cluster ID used is different to that of the old cluster, and that files, databases, and ports used by the new cluster don’t overlap with the old cluster.
Boot the new cluster.
Ensure that Rhino is in the STOPPED state
Deploy and configure RAs and services. Configure CGIN RA entities in the same way as on the "old" cluster, pointing to the same backend addresses.

A Rhino export from the old cluster may be useful for this step.

Now you should have the "new" cluster configured, but STOPPED, so that it is not receiving traffic.

To roll back this step, just discard your new cluster install. (No traffic is being processed by the new cluster yet.)

2

Start the new cluster

To start the "new" cluster, change the SLEE state to RUNNING. The new cluster RAs will connect to the same backends as the old cluster. New incoming traffic will be load balanced between the old and new clusters.

Initially, not much traffic will be load balanced to the new cluster. With the default settings, initially only 1% of traffic will be allocated to the new cluster; so at low call rates, it may take some time before traffic is processed by the new cluster.

Verify that the new cluster is processing calls correctly.

To roll back this step:

Reconfigure each CGIN resource adaptor entity in the new cluster to set the RA property signalware.base-weight to 0. For example:
```
updateraentityconfigproperties entityname signalware.base-weight=0
```
Wait for all dialogs in the new cluster to end.
Stop the new cluster — change the SLEE state to STOPPED.

3

Drain calls from the old cluster

For each CGIN RA entity in the old cluster, reconfigure the RA entity to set the RA property signalware.base-weight to 0:
```
updateraentityconfigproperties entityname signalware.base-weight=0
```

At this point, all new dialogs will be directed to the new cluster only. The old cluster will only continue to process existing dialogs established before the draining process started.

Wait for all dialogs in the old cluster to end.

Now the old cluster should be still connected to the CGIN backends, but completely idle — no traffic is being handled by the old cluster.

To roll back this step, for each CGIN RA entity in the "old" cluster, reconfigure the RA entity to restore the original value of signalware.base-weight, by default 100.

4

Stop the old cluster

Stop the SLEE using the stop management command.
Wait for the SLEE to reach the STOPPED state.

To roll back this step, start the SLEE.

5

Shut down the old cluster

Shut down the old cluster using the shutdown management command.

To roll back this step, restart the "old" cluster processes.

6

Schedule upgrade of old backends to the new version

(if needed)

Appendix B. Migrating to CGIN 2.0.x

Here are some things to note when migrating to CGIN 2.0.x:

When… Do this:

When…	Do this:
Upgrading from a CGIN older than 1.5.x	First upgrade to 1.5.0 using the process described in Appendix B of the CGIN 1.5 Installation and Configuration Guide.
Using the API	Review the revised service code to the 2.0.x API. For an informal summary of API changes, please see the Changelog. For details of the new API, see the Javadoc. CGIN now provides two event models; the old component based model and a new message based model. See CGIN Overview and Concepts for further information.
Migrating Scenario files to the current schema version	Note that the Scenario Simulator IN Scenario Pack’s schema has changed for this release. The Scenario Editor provides support for automatically migrating scenarios to the latest IN Scenario Pack schema version, please see the `--migrate` option under Command-line options in the Scenario Editor User Guide.

Upgrading from a CGIN older than 1.5.x

First upgrade to 1.5.0 using the process described in Appendix B of the CGIN 1.5 Installation and Configuration Guide.

Using the API

Review the revised service code to the 2.0.x API. For an informal summary of API changes, please see the Changelog. For details of the new API, see the Javadoc.

CGIN now provides two event models; the old component based model and a new message based model. See CGIN Overview and Concepts for further information.

Migrating Scenario files to the current schema version

Note that the Scenario Simulator IN Scenario Pack’s schema has changed for this release. The Scenario Editor provides support for automatically migrating scenarios to the latest IN Scenario Pack schema version, please see the --migrate option under Command-line options in the Scenario Editor User Guide.

Appendix C. Support Requests

This document provides guidance on material to include with CGIN support requests.

Gathering Supporting Data

Unless specifically requested otherwise:

Logging should be gathered from all Rhino nodes in the cluster.
By default the required logs are $RHINO_HOME/$NODE_ID/work/log/rhino.log*
Include more logging than might be obviously required; not just the time of the incident. Triggering events can occur hours or even days before. At a minimum include logging for:
- At least 2 days prior to the incident, preferably 7.
- During the incident.
- And for at least 2 hours following the incident (if this much time has passed).
Additionally, preserve all logging currently on the systems against the possibility that older logging may be requested.

The standard logging location for the CGIN RA entity is $RHINO_HOME/$NODE_ID/work/log/rhino.log. However, this may differ if the cluster is using a non-default logging configuration. Please refer to that logging configuration for location of tracer logs.

Enabling additional logging on test systems

When the issue occurs on a test system, or can be replicated on a test system, please set CGIN tracers to finest prior to replication and log gathering.

settracerlevel resourceadaptorentity <entityname> root finest

No additional logging configuration is required for individual TCAP stacks as their logging is configured as part of the CGIN RA entity root logger.

When replication is complete, logging may be set back to info or any other preferred level:

settracerlevel resourcesadaptorentity <entityname> root info

finest level tracing should not be used on a production system unless instructed otherwise. This produces large quantities of logging which can quickly fill up disk partitions when used in conjunction with non-trivial call volumes.