In this section:

It is assumed that you have standard procedures for system maintenance and that the person performing the software upgrade is qualified to perform this procedure.

Maintenance Window Considerations

The following should be considered while planning a maintenance window:

  • network activities that are taking place during the software upgrade
  • soak time before beginning a new network change
  • service usage irregularities such as phone-in contests
  • availability of operations staff
  • availability of vendor’s support staff
  • availability of support staff in network operations centers (NOCs) that are connected to your system
  • seasonal issues such as Christmas brown-out periods of network changes
  • NOC expert staff vacation schedules
  • system configuration (mated pair Ribbon DSC Platform systems, see Upgrading Ribbon DSC 8000 in a Mated Pair Configuration)

Customer Support provides emergency support to customers who have a support agreement. However, it is recommended that you notify this group about one week prior to planning a maintenance window for a software upgrade. For contact information, refer to Customer Support.

It is recommended that the NOC tests its maintenance window procedures prior to the software upgrade. This process allows the NOC staff to test the maintenance window procedures and isolate any existing problems prior to the software upgrade. To perform this test in its entirety, notifications may have to be sent to the locations that are affected by the maintenance window. It is highly recommended that you run a pre-upgrade check prior to the maintenance window to identify and resolve any possible issues that could hinder the software upgrade. (Since a pre-upgrade check is enforced as part of the upgrade procedures, time will be saved by manually executing an additional pre-upgrade check prior to the maintenance window to rectify any issues that would otherwise be encountered once the upgrade has commenced).

If you have off-site systems for spare hardware purposes, you should consider upgrading these systems as disaster recovery, lab, and training sites. If such a system is available, the training for software upgrade and rollback should take place on this system. Make sure to note the required time for each process.

Example Procedure

The following is an example of a software upgrade document:

Ribbon DSC Platform Software Upgrade

CLLI: wesott234top

Maintenance Window Times:

  • Start: 31 October 2016 23:00 EST
  • Late Stop: 1 November 2016 03:00 EST
  • Expected Stop: 1 November 2016 00:30 EST
Note

Expected stop refers to the time when a software upgrade that is executed without any problems should be completed.

Late stop refers to the time when an aborted upgrade with software rollback to the previous software version is completed.

Example Schedule for a Software Upgrade

The following table provides an example schedule for a software upgrade.

Item Expected Completion
Approval of the maintenance window for software upgrade plan November 15
Notification to connected NOCs1 November 23
Notification to various departments affected by this event (Billing, Marketing, and so on) November 23
Perform dry-runs in lab Week of November 23
Pre-upgrade Check (on a live system) The pre-upgrade check should be executed several times a few days before the upgrade and immediately before the upgrade.
Back up system November 30, 22:00
Review system status November 30, 22:15
Call NOCs and connected networks2 November 30, 23:45
Perform software upgrade according to Ribbon instructions 00:00
Bring up SS7 links on standby Ribbon DSC 8000 in the mated pair configuration 00:15
Call NOCs and connected networks 00:30
Review system status and test service 01:00
Back up systems

1 Providing the NOCs and connected networks one week in advance to the software upgrade gives them an opportunity to advise you of any activities they may have that could hinder the software upgrade.

2 It is recommended that you contact the NOCs and connected networks prior to bringing down the SS7 links. Performing this task generates alarms.

Upgrading Ribbon DSC 8000 in a Mated Pair Configuration Licensed for PCE

If you have a system configuration that comprises a mated pair of DSC Platform which are licensed for PCE, these systems must be upgraded during the same maintenance window.

One of the DSC Platform in the mated pair configuration supports PCE Peer 1 and Peer 2, and the other DSC Platform supports PCE Peer 3 and Peer 4. The DSC Platform that supports PCE Peer 1 and 2 must be upgraded first.

Start

  1. SSH to the DSC Platform.

    ssh root@<ip address of the DSC 8000>

  2. Log onto the system.

    User ID: <root>
password: <root password>

  3. Enter the following command at the prompt:

    cat /etc/hosts

    The PCE peers and their respective IPs are listed at the end of this file.

    Example
    10.91.2.86  pce1_1
10.91.4.86  pce1_2
10.91.2.87  pce2_1
10.91.4.86  pce2_2
10.91.2.90  pce3_1
10.91.4.90  pce3_2
10.91.2.91  pce4_1
10.91.4.91  pce4_2
pce1_1 and pce1_2 are IPs for PCE peer1
pce2_1 and pce2_2 are IPs for PCE peer2
pce3_1 and pce3_2 are IPs for PCE peer3
pce4_1 and pce4_2 are IPs for PCE peer4