vCSCF Upgrade Information from 1.7.x to 1.11.0

Call Session Control Function

1	Introduction
1.1	Prerequisites
2	Upgrade Overview
2.1	Impact of Upgrade
2.2	Impact of Rollback
3	Attribute Change

1 Introduction

This document contains information needed when planning an upgrade of the Virtual Call Session Control Function (vCSCF) software. For the "from" and "to" states of the vCSCF, see Table 1.

Table 1 From and To Software Versions
From State vCSCF Version	To State vCSCF Version
vCSCF 1.7.0 CXP 903 4345/1 R8A07	vCSCF 1.11.0 CXP 903 4345/1 R12A08

In this document, the term "vCSCF" refers to the product and the term "CSCF" refers to the CSCF application.

This document is to be used when planning upgrades on customer sites.

1.1 Prerequisites

This section describes the prerequisites which must be fulfilled before the vCSCF can be upgraded. For the "from" and "to" states of vCSCF, see Table 1.

For upgrading with network redundancy, there are additional prerequisites, see Section 1.1.1 Additional Prerequisites for Upgrade with Network Redundancy.

It is recommended to migrate the traffic to one or more redundant S-CSCF nodes and to perform the upgrade with Network Redundancy. This is because of the need to perform a cluster reboot after the upgrade for configuration changes to take effect.

Network Element Version

This instruction applies to the following Network Element (NE):

vCSCF 1.7.0 CXP 903 4345/1 R8A07

Note:: This document also applies for all subsequent Emergency Package (EP) releases made on top of vCSCF 1.7.0. Correction mapping and merging have been done up to and including vCSCF 1.7.1.

Hardware Configurations

The vCSCF can run on any hardware supported by the hypervisor.

From State of Software Configurations

The required software and version are as follows:

vCSCF 1.7.0 CXP 903 4345/1 R8A07

1.1.1 Additional Prerequisites for Upgrade with Network Redundancy

The following prerequisites must be fulfilled before upgrading the vCSCF with network redundancy:

It is recommended that the Serving Call Session Control Function (S-CSCF) Restoration Procedure is enabled in the IP Multimedia Subsystem (IMS) network to minimize disturbances for users during the Shutting Down of an S-CSCF. To enable the S-CSCF Restoration Procedure, see CSCF Configuration Management.
At least one redundant S-CSCF node is required so all traffic can be migrated to the redundant S-CSCF nodes before activating the upgrade package.
Verify that the intended redundant S-CSCF nodes are operational by checking the CSCF system health. For more information, see CSCF Health Check.

2 Upgrade Overview

This section describes the upgrade, and a possible rollback, from an impact point of view.

Lead Time

Table 2 Overall Lead Time for CSCF Upgrade with Network Redundancy
Upgrade Step	Hardware Configuration	Pre Upgrade	Upgrade	Post Upgrade
From vCSCF 1.7.0 CXP 903 4345/1 R8A07 to vCSCF 1.11.0 CXP 903 4345/1 R12A08	Any hardware supported by the hypervisor	40 minutes⁽¹⁾	65 minutes ⁽¹⁾⁽²⁾	50 minutes ⁽¹⁾

(1) This lead time is valid for a 2+8 system.

(2) This time does not include any time needed to migrate traffic for network redundancy. See CSCF Configuration Management for more information about the timing for migrating traffic to redundant S-CSCF nodes.

Table 3 Overall Lead Time for CSCF Upgrade without Network Redundancy
Upgrade Step	Hardware Configuration	Pre Upgrade	Upgrade	Post Upgrade
From vCSCF 1.7.0 CXP 903 4345/1 R8A07 to vCSCF 1.11.0 CXP 903 4345/1 R12A08	Any hardware supported by the hypervisor	40 minutes⁽¹⁾	125 minutes ⁽¹⁾	50 minutes ⁽¹⁾

(1) This lead time is valid for a 2+8 system.

Downtime for Upgrade with Network Redundancy

During the upgrade with network redundancy, the following downtimes are expected:

Time without Service Accessibility: No downtime
Time without Session Retainability: No downtime

Downtime for Upgrade without Network Redundancy

During the upgrade without network redundancy, the following downtimes are expected when the cluster reboot is running:

Time without Service Accessibility: < 10 minutes
Time without Session Retainability: < 10 minutes

Traffic Loss for Upgrade with Network Redundancy

During the upgrade with network redundancy, the following traffic loss is expected:

Rejected session traffic: < 10%
Registration rejections: < 10%

Traffic Loss for Upgrade without Network Redundancy

During the upgrade without network redundancy, the following traffic loss is expected during the " Activate Configuration through a Cluster Reboot"step:

Rejected session traffic: 100%
Registration rejections: 100%

2.1 Impact of Upgrade

This section describes the impact of the upgrade.

Detailed Lead Time

Table 4 Estimated Lead Time for Upgrade with Network Redundancy
	Hardware
	Any Hardware Supported by the Hypervisor
	Outside Window	Inside Window
Total Backup	~ 10 minutes
Pre Upgrade Steps	~ 30 minutes
Migrate traffic to redundant S-CSCF nodes for upgrading with network redundancy⁽¹⁾		~ 50 minutes
vCSCF Upgrade		~ 65 minutes
Post Upgrade Health Check		~ 15 minutes
Post Upgrade Steps	~ 35 minutes
Subtotal:	~ 1 hour and 15 minutes	~ 2 hours and 10 minutes
Total time (outside + inside):	-	~ 3 hours and 25 minutes⁽²⁾

(1) See CSCF Configuration Management for more information about the timing for migrating traffic to redundant S-CSCF nodes.

(2) This lead time is valid for a 2+8 system.

Table 5 Estimated Lead Time for Upgrade without Network Redundancy
	Hardware
	Any Hardware Supported by the Hypervisor
	Outside Window	Inside Window
Total Backup	~ 10 minutes
Pre Upgrade Steps	~ 30 minutes
vCSCF Upgrade		~ 125 minutes⁽¹⁾
Post Upgrade Health Check		~ 15 minutes
Post Upgrade Steps	~ 35 minutes
Subtotal:	~ 1 hour and 15 minutes	~ 2 hours and 20 minutes
Total time (outside + inside):	-	~ 3 hours and 35 minutes⁽²⁾

(1) This lead time is valid for a 2+8 system.

(2) This lead time is valid for a 2+8 system.

Characteristics

For information on how the upgrade affects the system capacity and other characteristics, see vCSCF Network Impact Report from 1.7.x to 1.11.0.

Operation and Maintenance

The upgrade has the following impact on the operation and maintenance of the system:

Note:: All maintenance and troubleshooting activities must be stopped or ended properly before starting the upgrade activity, including log and trace collections. For troubleshooting purposes, and only under the instruction of Ericsson support personnel, a limited set of logging and tracing could be turned on during the upgrade.
The Operation and Maintenance (O&M) configuration must be frozen during the upgrade. Configuration changes made during the upgrade can be lost, or cause the upgrade to fail.

Alarms and Notifications
Several alarms and notifications can be seen during the upgrade and are automatically cleared after the upgrade procedure.
Capsule Abortions
During the upgrade, some capsule abortions can be observed. Some of these capsule abortions occur on the old software when it is terminating and are considered harmless. The type and number of capsule abortions depend on several factors, for example on the traffic scenario and intensity.

Provisioning

Not Applicable.

Charging

No impact.

Security

No impact

End Terminals

Not Applicable.

Database Handling

No impact.

Dependencies to Other Nodes

This subsection describes the impact on the dependencies to other nodes during the upgrade.

The upgrade has no impact on the external interfaces.

The upgrade has no impact on the backward compatibility.

2.2 Impact of Rollback

This section describes the impact of a possible rollback, in case the upgrade is not concluded in a satisfactory manner.

Lead Time

Table 6 Lead Time for Rollback of The vCSCF 1.11.0
Hardware Configuration	Any Hardware Supported by the Hypervisor
Test Conditions
Test Conditions
Steps	Activities	Duration	Total duration
Pre Rollback	NA	NA	NA
Rollback of NE	Cluster reload	~10 minutes	10 minutes
Post Rollback	NA	NA	NA

Traffic Loss

The traffic is lost during Cluster Reload.

Service Disturbances

The service is unavailable during Cluster Reload.

Characteristics

The rollback has the following impact on the capacity and other characteristics of the system:

Rejected traffic: 100%
Disconnected traffic: 100%

Operation and Maintenance

The rollback has the following impact on the operation and maintenance of the system:

No access during Cluster Reload

Provisioning

The rollback has the following impact on the provisioning of the system:

No access during Cluster Reload

Charging

The rollback has the following impact on the Charging capability of the system:

No impact

Security

The rollback has the following impact on the security of the system:

No impact

End Terminals

The rollback has the following impact on the end terminals:

The end terminals behavior is affected because of lost registration state in the vCSCF, the end terminals have to register themselves through normal procedure before working.

Database Handling

This subsection describes the impact on the database handling during the rollback and how data is migrated.

The database is changed as follows by the rollback:

No impact

The data is migrated as follows by the rollback:

No impact

Rollback Dependencies on Interaction with Other Nodes

This subsection describes the impact on the dependencies to other nodes during the rollback.

The rollback has the following impact on the external interfaces:

No impact

The rollback has the following impact on the backward compatibility:

No impact

Note:: Also roll back any attribute modification performed on other nodes, that is, the Home Subscriber Server (HSS), in preparation for the upgrade, to prevent possible conflicts.

Other Impacts

The rollback has the following other impacts on the system:

No impact

3 Attribute Change

For information about the new, changed, deprecated, obsolete, and deleted attributes, see vCSCF Network Impact Report from 1.7.x to 1.11.0.