Contents

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.5 CXP 902 3140/2 R7E01	vCSCF 1.6.0 CXP 903 4345/1 R7A04

In this document, the term "vCSCF" refers to the product and the term "CSCF" refers to the CSCF application, independent of being deployed in a native or virtualized environment.

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.

Note:  

This upgrade must be performed with no traffic running in the node. It is recommended to migrate the traffic to one or more redundant S-CSCF nodes and to perform the upgrade with Network Redundancy.

Network Element Version

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

• vCSCF 1.5 CXP 902 3140/2 R7E01

Note:  

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

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.5 CXP 902 3140/2 R7E01

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, refer to 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, refer to CSCF Health Check.

2   Upgrade Overview

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

Lead Time

For information about lead time, see Table 2.

Table 2    Overall Lead Time

Upgrade Step	Hardware Configuration	Pre Upgrade	Upgrade	Post Upgrade
From vCSCF 1.5 CXP 902 3140/2 R7E01 to vCSCF 1.6.0 CXP 903 4345/1 R7A04	Any hardware supported by the hypervisor	40 minutes(1)	65 minutes (1)(2)	50 minutes (1)

(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

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:

• Time without Service Accessibility: 80 minutes
• Time without Session Retainability: 80 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:

• Rejected session traffic: 100%
• Registration rejections: 100%

2.1   Impact of Upgrade

This section describes the impact of the upgrade.

Detailed Lead Time

For information on the lead time for upgrading the vCSCF, see Table 3.

Table 3    Estimated Lead Time for Upgrade

		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(1)			~ 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)   Refer to CSCF Configuration Management for more information about the timing for migrating traffic to redundant S-CSCF nodes.

Characteristics

This upgrade does not affect the capacity and other characteristics of the system.

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.

Other Impacts

No impact.

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

For information on the lead time for the rollback of the vCSCF 1.6.0, see Table 4.

Table 4    Lead Time for Rollback

Hardware Configuration	Any Hardware Supported by the Hypervisor
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

This section describes the attributes which are new, changed, deprecated, obsolete, or deleted during the upgrade.

3.1   New Attributes

The following attributes are new:

• cscfProactiveMonitoredSipInterfaceEntry
• cscfProactiveMonitoringInterval
• cscfSipMonitoringSuppressDestinationEntry

For more information about the new attributes, refer to vCSCF Network Impact Report from 1.5 to 1.6.0

3.2   Changed Attributes

The following attribute is changed:

• cscfSipOverloadControlReactingTrafficPriorities

3.3   Deprecated Attributes

There are no deprecated attributes.

3.4   Obsolete Attributes

There are no obsolete attributes after the upgrade.

3.5   Deleted Attributes

There are no deleted attributes after the upgrade.