This page describes steps required to prepare for a major upgrade from 4.1.

They can be performed before the upgrade, outside of a maintenance window. However, the prerequisites might reveal the need for additional maintenance windows, so confirm the prerequisites prior to making a detailed upgrade plan.

Important

We recommend that you upgrade to the latest available minor release of RVT 4.2.

1. Check prerequisites

1.1. Preparation steps

Before starting the upgrade, check the following:

  • All RVT nodes need to be on version at least 4.1-3-1.0.0. If not, perform an upgrade of the RVT nodes to the latest available version of RVT 4.1 first. This requires you to plan a separate maintenance window before starting the upgrade to RVT 4.2.

  • The TSN nodes need to be running Cassandra 4.1 container. If they are running Cassandra 3.11 container, then perform a Cassandra Switch procedure to Cassandra 4.1 first.

  • You have deployed a SIMPL VM, version 6.15.3 or later. Output shown in this document is correct for version 6.15.3 of the SIMPL VM; it may differ slightly on later versions.

If it is still on a lower version, upgrade it as per the SIMPL VM Documentation. SIMPL VM upgrades are out of scope for this document.

  • You have deployed a MDM VM version 3.8.0 or later.

If it is still on a lower version, refer to MDM Upgrade to upgrade it.

  • Confirm all other node types are running compatible software versions (MDM etc).

  • You have access to the SSH keys used to access the SIMPL VM.

  • You have access to the SIMPL and MDM documentation.

1.2. VM health checks

Before starting the upgrade, check the health of the VMs.

Important

Any unhealthy VMs should be fixed before proceeding with the upgrade. Failure to do so will likely cause the upgrade to fail.

  • Follow the VNF validation checks and tests here for each RVT node type.

  • Confirm that MDM and SIMPL are currently healthy. Refer to each product’s set of documentation for instructions on checking node health.

    • Additionally, confirm the certificates for MDM are valid, and will not expire before the upgrade.

1.3. Prepare SIMon for upgrade

If you use SIMon to monitor your system health, then get the latest VoLTE Solution Bundle from your Customer Care Representative and follow this document to prepare your SIMon for the upgrade: Managing SIMon configuration files when upgrading VoLTE Solution components.

If you do not use SIMon to monitor system health then please consider integrating this into your deployment by following this doc: Integrating RVT 4.1+ with SIMon - MOP. It is not an upgrade requirement to have SIMon integration, but it is recommended for monitoring and alarming purposes.

2. Upload uplevel CSARs

Your Customer Care Representative will have provided you with the uplevel TSN, MAG, ShCM, MMT CDMA, and SMO CSARs. Use scp to copy these to /csar-volume/csar/ on the SIMPL VM.

Once the copy is complete, for each CSAR, run csar unpack /csar-volume/csar/<filename> on the SIMPL VM (replacing <filename> with the filename of the CSAR, which will end with .zip).

The csar unpack command may fail if there is insufficient disk space available. If this occurs, SIMPL VM will report this with instructions to remove some CSARs to free up disk space. You can list all unpacked CSARs with csar list and remove a CSAR with csar remove <node type>/<version>.

Backout procedure

Remove any unpacked CSARs using csar remove <node type>/<version>. Remove any uploaded CSARs from /csar-volume/csar/ using rm /csar-volume/csar/<filename>.

3. Update the configuration files for RVT 4.2

3.1. Prepare the downlevel config directory

If you keep the configuration hosted on the SIMPL VM, then the existing config should already be located in /home/admin/current-config (your configuration folder may have a different name, as the folder name is not policed e.g. yours may be named rvt-config, if this is the case then rename it to current-config). Verify this is the case by running ls /home/admin/current-config and checking that the directory contains:

  • The downlevel configuration files

  • The Rhino license.

  • The current SDF for the deployment (in the format used by SIMPL 6.13). This is the SDF titled 'sdf-rvt.yaml' which you will previously have used to manage the RVT 4.2 VMs.

  • Any certificates and private key files for REM, BSF, and/or XCAP: <type>-cert.crt and <type>-cert.key, where <type> is one of rem, bsf, or xcap.

If it isn’t, or you prefer to keep your configuration outside of the SIMPL VM, then create this directory on the SIMPL VM:

mkdir /home/admin/current-config

Use scp to upload the files described above to this directory.

3.2. Create directories for RVT 4.2 configuration and for rollbacks

To create the directory for holding the uplevel configuration files, on the SIMPL VM, run:

mkdir /home/admin/uplevel-config

Then run

cp /home/admin/current-config/* /home/admin/uplevel-config

to copy the configuration, which you will edit in place in the steps below.

Note
At this point you should have the following directories on the SIMPL VM:

  • /home/admin/current-config, containing the downlevel configuration files (i.e. the unmodified files you copied off of the downlevel SIMPL VM).

  • /home/admin/uplevel-config, containing a copy of the current-config files. These files will be modified and used for the RVT 4.1 upgrade.

3.3. Make product-specific changes to the SDF for RVT 4.2

Open the /home/admin/uplevel-config/sdf-rvt.yaml file using vi. Find the vnfcs section, and within that every RVT VNFC (tsn, mag, shcm, mmt-cdma, or smo). For each of them, make changes as follows :

  • Update the VM versions for all the VM types (tsn, mag, shcm, mmt-cdma, or smo). Find the vnfcs section, and within each VNFC, locate the version field and change its value to the uplevel version, for example 4.2-8-1.0.0.

type: mag
-      version: 4.1-7-1.0.0
+      version: 4.2-8-1.0.0
       vim-configuration:

Save and close the file.

3.4. Identify if any RVT nodes are misordered

Inside /home/admin/uplevel-config, check the files mag-vmpool-config.yaml, mmt-gsm-vmpool-config.yaml and smo-vmpool-config.yaml. Within each of these files, confirm that the first occurrence of rhino-node-id: xxx is set to the smallest value of all occurrences of rhino-node-id: yyy in that particular file. If not, contact your Customer Care Representative to adjust the upgrade steps in this MOP.

3.5. Backout procedure

To undo the changes in this section, remove the created configuration directories:

rm -rf /home/admin/uplevel-config

4. Validate the new configuration

4.1. Validate the configuration

We now check that the uplevel configuration files are correctly formatted, contain valid values, and are self-consistent.

For each node type tsn, mag, shcm, mmt-cdma, or smo, run the command /home/admin/.local/share/csar/<node type>/<uplevel version>/resources/rvtconfig validate -t <node type> -i /home/admin/uplevel-config

For example …​ /home/admin/.local/share/csar/mag/4.2-X-1.0.0/resources/rvtconfig validate -t mag -i /home/admin/uplevel-config

A successful validation with no errors or warnings produces the following output.

Validating node type against the schema: <node type>
YAML for node type(s) ['<node type>'] validates against the schema

If the output contains validation errors, fix the configuration in the /home/admin/uplevel-config directory and refer to the previous steps to fix the issues.

If the output contains validation warnings, consider whether you wish to address them before performing the upgrade. The VMs will accept configuration that has validation warnings, but certain functions may not work.

4.2. Carry out a csar update dry run

The csar update dry run command carries out more extensive validation of the SDF and VM states than rvtconfig validate does.

Carrying out this step now, before the upgrades are due to take place, ensures problems with the SDF files are identified early and can be rectified beforehand.

Note

The --dry-run operation will not make any changes to your VMs, it is safe to run at any time, although we always recommend running it during a maintenance window if possible.
Note

The major upgrade from 4.1 to 4.2 version does not support csar udpate for SMO node, so it is not passed to the list of nodes under the --vnf parameter.

Please run the following command (replacing mmt-gsm with mmt-cdma if your deployment uses CDMA) to execute the dry run.

csar update --sdf /home/admin/uplevel-config/sdf-rvt.yaml --vnf shcm,tsn,mmt-gsm,mag --sites <site name> --skip force-in-series-update-with-l3-permission --dry-run

Confirm the output does not flag any problems or errors. The end of the command output should look similar to this.

You are about to update VMs as follows:

- VNF shcm:
    - For site grsite1:
      - update all VMs in VNFC service group gr1-shcm/4.1-7-1.0.0:
        - gr1-shcm-1 (index 0)
        - gr1-shcm-2 (index 1)

- VNF tsn:
    - For site grsite1:
      - update all VMs in VNFC service group gr1-tsn/4.1-7-1.0.0:
        - gr1-tsn-1 (index 0)
        - gr1-tsn-2 (index 1)
        - gr1-tsn-3 (index 2)

- VNF mmt-gsm:
    - For site grsite1:
      - update all VMs in VNFC service group gr1-mmt-gsm/4.1-7-1.0.0:
        - gr1-mmt-1 (index 0)
        - gr1-mmt-2 (index 1)
        - gr1-mmt-3 (index 2)

- VNF mag:
    - For site grsite1:
      - update all VMs in VNFC service group gr1-mag/4.1-7-1.0.0:
        - gr1-mag-1 (index 0)
        - gr1-mag-2 (index 1)
        - gr1-mag-3 (index 2)

Please confirm the set of nodes you are upgrading looks correct, and that the software version against each service group correctly indicates the software version you are planning to upgrade to.

If you see any errors, please address them, then re-run the dry run command until it indicates success.

Previous page Next page
Rhino VoLTE TAS VMs Version 4.2