This approach manages the upgrade externally to Rhino and OCSS7, 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 clusters (Rhino and SGC) with a new "physical" address. Ensure that the new Rhino cluster has a different clusterID to the existing Rhino cluster. Similarly, the new SGC cluster must have a different Hazelcast cluster ID to the existing SGC cluster.

  2. Configure and activate the new clusters.

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

  7. Halt the old clusters.

Previous page Next page