Software Configuration Management in MCBSC

GSM/EDGE BSS, Rel.
RG30(BSS), Operating
Documentation, Issue 04
Administer
Software Configuration Management in

mcBSC and mcTC
DN0989007 DN0989007
Issue 01D
Approval Date 2012-03-13
Confidential
Nokia Siemens Networks is continually striving to reduce the adverse environmental effects of
its products and services. We would like to encourage you as our customers and users to join
us in working towards a cleaner, safer environment. Please recycle product packaging and
follow the recommendations for power use and proper disposal of our products and their compo-
nents.
If you should have questions regarding our Environmental Policy or any of the environmental
services we offer, please contact us at Nokia Siemens Networks for any additional information.
Software Configuration Management in mcBSC and
mcTC
The information in this document is subject to change without notice and describes only the
product defined in the introduction of this documentation. This documentation is intended for the
use of Nokia Siemens Networks customers only for the purposes of the agreement under which
the document is submitted, and no part of it may be used, reproduced, modified or transmitted
in any form or means without the prior written permission of Nokia Siemens Networks. The
documentation has been prepared to be used by professional and properly trained personnel,
and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes
customer comments as part of the process of continuous development and improvement of the
documentation.
The information or statements given in this documentation concerning the suitability, capacity,
or performance of the mentioned hardware or software products are given "as is" and all liability
arising in connection with such hardware or software products shall be defined conclusively and
finally in a separate agreement between Nokia Siemens Networks and the customer. However,
Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions
contained in the document are adequate and free of material errors and omissions. Nokia
Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which
may not be covered by the document.
Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO
EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTA-
TION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDI-
RECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED
TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY
OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION
IN IT.
This documentation and the product it describes are considered protected by copyrights and
other intellectual property rights according to the applicable laws.
The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark
of Nokia Corporation. Siemens is a registered trademark of Siemens AG.
Other product names mentioned in this document may be trademarks of their respective
owners, and they are mentioned for identification purposes only.
Copyright © Nokia Siemens Networks 2012. All rights reserved
f Important Notice on Product Safety

This product may present safety risks due to laser, electricity, heat, and other sources
of danger.
Only trained and qualified personnel may install, operate, maintain or otherwise handle
this product and only after having carefully read the safety information applicable to this
product.
The safety information is provided in the Safety Information section in the “Legal, Safety
and Environmental Information” part of this document or documentation set.
The same text in German:
f Wichtiger Hinweis zur Produktsicherheit

Von diesem Produkt können Gefahren durch Laser, Elektrizität, Hitzeentwicklung oder
andere Gefahrenquellen ausgehen.
Installation, Betrieb, Wartung und sonstige Handhabung des Produktes darf nur durch
geschultes und qualifiziertes Personal unter Beachtung der anwendbaren Sicherheits-
anforderungen erfolgen.
Die Sicherheitsanforderungen finden Sie unter „Sicherheitshinweise“ im Teil „Legal,
Safety and Environmental Information“ dieses Dokuments oder dieses Dokumentations-
satzes.
2 Id:0900d805809a705b DN0989007 DN0989007

Confidential
mcTC
Table of contents
This document has 86 pages.
Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2 Software Configuration Management . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1 Software configuration management . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.1 Software configuration information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.2 Software builds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.2.1 Software build subdirectories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1.2.2 Status of a SW build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.2.3 Disk file versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.3 Update deliveries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.3.1 New SW build deliveries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.3.2 Change deliveries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.3.3 Software update compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2 Preparing the system for software update . . . . . . . . . . . . . . . . . . . . . . . 22
2.3 Installing and deploying new software build. . . . . . . . . . . . . . . . . . . . . . 24
2.3.1 Creating directories and copying the SW build . . . . . . . . . . . . . . . . . . . 24
2.3.2 Converting and copying files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3.3 Creating a SW build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.4 Creating a trial configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3.5 Making necessary modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3.6 Cutting over to a new SW build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.7 Completing the update process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4 Installing and deploying a change delivery . . . . . . . . . . . . . . . . . . . . . . 36
2.5 Deleting old software builds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3 Software configuration management in mcTC. . . . . . . . . . . . . . . . . . . . 38

3.1 Software configuration management in mcTC. . . . . . . . . . . . . . . . . . . . 38
3.1.1 Software builds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.1.1.1 Recomended directories to copy software build . . . . . . . . . . . . . . . . . . 39
3.1.1.2 Software build directories. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.1.2 Update deliveries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.1.3 Embedded software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2 Software upgrade in mcTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3 Upgrading embedded software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.3.1 Overview of mcTC embedded software. . . . . . . . . . . . . . . . . . . . . . . . . 41
3.3.2 Retrieving the embedded software version . . . . . . . . . . . . . . . . . . . . . . 42
3.3.3 Upgrading embedded software of BCN-A and BOC-A add-in cards . . . 45
3.3.4 Upgrading embedded software of BDSP-A add-in cards. . . . . . . . . . . . 48
3.3.5 Upgrading embedded software of BSAC-A add-in card . . . . . . . . . . . . 54
3.3.6 Setting up LMP for commissioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.3.6.1 Configuring the general LMP settings . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.3.6.2 Configuring the BCM56820 main switch . . . . . . . . . . . . . . . . . . . . . . . . 65
3.3.6.3 Configuring the BCM56512 extension switch . . . . . . . . . . . . . . . . . . . . 70
3.3.6.4 Configuring the BCM56820 switch manually . . . . . . . . . . . . . . . . . . . . . 73
DN0989007 DN0989007 Id:0900d805809a705b 3

Confidential
mcTC
3.3.6.5 Configuring the BCM56512 switch manually . . . . . . . . . . . . . . . . . . . . . 77

3.3.6.6 Resetting the LMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.3.6.7 Restoring other Flexi Platform (FP) settings . . . . . . . . . . . . . . . . . . . . . . 79
3.4 Installing and activating mcTC software delivery using a system restart 80
3.5 Installing mcTC correction or patch delivery . . . . . . . . . . . . . . . . . . . . . . 83
3.6 Downgrading mcTC software using system restart . . . . . . . . . . . . . . . . 85
3.7 Deleting old mcTC SW builds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4 Id:0900d805809a705b DN0989007 DN0989007

Confidential
mcTC
List of figures
Figure 1 Directory structure of the hard disk as seen from the SW build management
point of view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Figure 2 Statuses of a created SW build . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Figure 3 The effects of a new SW build deployment on other SW builds . . . . . . 17
Figure 4 The effects of a change delivery deployment on other SW builds of the net-
work element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Figure 5 Cabling between laptop and mcTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
DN0989007 DN0989007 Id:0900d805809a705b 5

Confidential
mcTC
List of tables
Table 1 Subdirectories of WEBFIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Table 2 Creating a trial configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Table 3 mcTC SCLI command for software configuration management . . . . . . 38
Table 4 Embedded software (eSW) details of mcTC add-in cards. . . . . . . . . . . 41
Table 5 Internal network port mapping for BCM56820 main switch . . . . . . . . . . 74
Table 6 Parameters for deleting software deliveries . . . . . . . . . . . . . . . . . . . . . . 80
Table 7 Parameters for installing deliveries . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Table 8 Parameters for activating deliveries . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Table 9 Parameters for installing patch delivery . . . . . . . . . . . . . . . . . . . . . . . . . 83
Table 10 Parameters for downgrading to older software deliveries . . . . . . . . . . . 85
Table 11 Parameters for deleting old software deliveries . . . . . . . . . . . . . . . . . . . 86
6 Id:0900d805809a705b DN0989007 DN0989007

Confidential
Software Configuration Management in mcBSC and Summary of changes
mcTC
Summary of changes
Changes between document issues are cumulative. Therefore, the latest document
issue contains all changes made to previous issues.
Changes between issues 01D (2012/03/13, BSS15 RG20) and 01C (2011/12/14,
BSS15 RG20)
Added a note in Step 6 on specific file conversion steps in section Converting and
copying files in chapter Installing and deploying new software build.
Changes between issues 01C (2011/12/14, BSS15 RG20) and 01B (2011/10/19,
BSS15 RG20)
The following sections are added:
• Checking IUA connection is added as a procedure in trial configuration.
• Restoring other Flexi Platform settings is added under Setting up LMP for commis-
sioning.
Changes between issues 01B (2011/10/19, BSS15 RG20) and 01A (2011/09/30,
BSS15 RG20)
Updated section Ugrading embedded software of BSAC-A add-in card with simpler pro-
cedures to upgrade.
DN0989007 DN0989007 Id:0900d805809186ac 7

Confidential
Summary of changes Software Configuration Management in mcBSC and
mcTC
8 Id:0900d805809186ac DN0989007 DN0989007

Confidential
Software Configuration Management in mcBSC and Introduction
mcTC
1 Introduction
This document provides information on how to manage software configuration manage-
ment (SCM) for Multicontroller BSC (mcBSC) and Multicontroller Transcoder (mcTC)
Section Software configuration management covers an overall picture of how the
software build of a network element in BSS is managed and describes the existence for
several software builds in a network element, the default build, the purpose of different
software build statuses, and how to chang the statuses of different software build.
Section Software configuration management in mcTC covers an overall picture of how
the software build of mcTC is managed and describes the procedures to install and
activate software build or pactch delivery, upgrade a new mcTC build using SCLI
commands or downgrade to an older build. It also covers the procedures to upgrade the
embedded software of the add-in cards of the mcTC.
g The SCM for mcTC is managed separately and for details refer section Software config-
uration management in mcTC.
DN0989007 DN0989007 Id:0900d80580896dae 9

Confidential
Software Configuration Management Software Configuration Management in mcBSC and
mcTC
2 Software Configuration Management
2.1 Software configuration management

Software configuration management gives an overall picture of how the software build
of a network element is managed and describes the following:
• why there are several software builds in a network element
• what a default build is
• what purpose the different software build statuses have
• how the different software build statuses can be changed
The information given is on a general level. More detailed instructions for updating your
software is delivered with the new software build. Change deliveries also come with
detailed instructions on the installation and deployment of that particular change deliv-
ery. For more information, see instructions in Backup and Restore.
g Installing a software update requires extensive knowledge and long-term experience of

the system. In addition, the person must know the presentation mode of command
descriptions and parameters as used in the operating instructions. For more information,
see MML command syntax in MML User Interface.
g Software update is generally automatically done with an update macro which is run
using the HIT tool. The macro and the HIT tool are provided by Nokia Siemens Networks
with the software delivery.
2.1.1 Software configuration information
g Not all network elements have all of the following functionalities.
The system includes a software configuration management system which consists of

several files and programs. All software builds of a network element belong to the
system. By using the software configuration management functions, you can:
1. Manage software builds:
• create and delete software builds
• manage the statuses of software builds
• select the default software build
• make fallback copies of the software in the network element. For more infor-
mation, see instructions in Backup and Restore.
2. Install and deploy a new software build or update an existing build, and test new
software before deploying it:
• with trial configuration and cutover
• without trial configuration by restarting the network element
3. Obtain information on the software builds of the network element:
• a list of all builds
• all information on a specified build
• data on the versions of the program blocks loaded in the units
• verification of the build contents
• a list of differences between the builds
4. Manage and install change deliveries and deploy them either:
10 Id:0900d8058098f336 DN0989007 DN0989007

Confidential
Software Configuration Management in mcBSC and Software Configuration Management
mcTC
• by restarting the relevant units or

• by restarting the whole network element
MML programs for software configuration management

WN Change delivery handling
WQ Software package management
WS Software package status management
WR Software package deployment handling
These commands are needed in managing the deployment of those SW
build changes that need trial configuration in the network element.
WK Software package fallback handling
For more information, see instructions in Backup and Restore.
WX Software configuration resource handling
MML programs closely related to software configuration management

DE File conversion handling
DU Disk update handling
IW Disk file and directory handling
IB I/O file backup
DB Database handling
IP Batch Copy Handling
2.1.2 Software builds

A software build is a collection of programs and files (load modules) operating in a
required system. In the building system of the system software, identity data is defined
for both the SW build and the load modules. The identity data of the load modules is
explained in the software control list. The software compiles a MAFILE by using the data
stored in the control list. The MAFILE is transferred to the network element together with
the SW build. The identity data of the load modules are also shown in the disk file
header, from where the programs can read them and compare them with the data stored
in the MAFILE.
A new SW build brought into a network element can be either a new SW delivery, a
system-level upgrade, where the basic technology of the whole system is renewed with
regard to both hardware and software, or a software update. A software update can
again be either a delivery of a new SW build or a change delivery.
The software build stored on the disk of a network element can be:
• Running SW build
A running software build is the build that has been loaded into the unit. Usually, the
running software build has the backup build (BU) status; it is also the default
software build and has the active build status.
• Active SW build in the directory
In each directory, the active software build is the one whose load modules have the
default versions. For more information, see Disk file versions. If there is only one
software build in the directory, it is the active build. If there are two software builds
DN0989007 DN0989007 Id:0900d8058098f336 11

Confidential
mcTC
in the same directory, only one of them is active. The default software build and the
running software build are usually active.
g When installing a change delivery, if you give the WSS command (Switch Active
Package in Directory) without restarting the network element, the running SW build
is not active and not the default build.
• Default SW build
The default software build is loaded into the network element when the network
element is restarted. Thus, the default SW build is the one involved in the initial
loading. The status of the default software build must be BU, NW, or FB (see Status
of a SW build). Usually the default build has the BU status, but in the trial configu-
ration of a major software change, the default build is changed to NW build. During
the trial configuration, the NW build is set as the default build. Reference to the
default build is maintained on the disk in a directory file that is common to all SW
builds. After loading, all default disk operations are directed to the default SW build.
g After returning to a fallback copy, the SW build has the FB status.
Under normal conditions, the running SW build, the active SW build and the default SW
build are the same.
The memory disk of a network element can contain several SW builds at the same time.
Each SW build is stored in its own directory. In a normal situation, there are at least two
SW builds, the running SW build (BU) and the fallback copy (FB). When the system is
being updated, there is also a third SW build, the NW build.
There can be some SW builds in the UT status and UD status stored on the disk of a
network element also. Usually, these are old SW builds that have not been removed
from the system.
The UT build can also be a new one. When installing a change delivery, the new SW
build is stored into the same directory as the running SW build (usually the BU build),
and the new build is set in the UT status. After that, the activity and the status of the
builds have to be switched by using the WSS command.
A software build brought into a network element can be:
• Update SW build
An update SW build is used to update the existing software of a network element.
• Correction SW build
A correction SW build contains corrections of detected faults.
2.1.2.1 Software build subdirectories

A software build consists of several files stored in different subdirectories:
12 Id:0900d8058098f336 DN0989007 DN0989007

Confidential
mcTC
ROOT
DIRECTORY
SCMANA A B C
- SOMAFI (SW Config. Management file)

- files common to all SW builds
SCMANA TMPDIR BLCODE MMDIRE LFILES CONVPR ASWDIR CDTEMP WEBFIL
- only in FB
build
CGI SCRIPT APPS HTDOCS ICONS GRAPHICS
Figure 1 Directory structure of the hard disk as seen from the SW build management
point of view
A, B, and C
These SW build directories contain subdirectories of a SW build and build-specific data.
You can name the directories freely. However, it is not recommended to give them
names that contain SW build version data or delivery names. Usually, each directory
contains the data of one SW build. During a change delivery deployment, the files of
two SW builds are stored in the same directory.
g Do not change the names of the subdirectories in a SW build directory, such as the A
directory.
SCMANA
The Software Configuration Management Directory (SCMANA) contains the files that
are in common use in SW build management. In the normal directory architecture, SW
build directory does not contain SCMANA. The SCMANA only occurs in the FB build
when you take a fallback copy of the backup build.
TMPDIR
The Temporary Directory (TMPDIR) is an auxiliary directory for the SW build updating
procedure. The results of conversions are stored in the TMPDIR. When the update is
completed, the directory is deleted. The TMPDIR can be created within an old or a new
directory, depending on the current update situation. Usually, the TMPDIR is created in
a new directory. There can be several TMPDIR directories at the same time.
DN0989007 DN0989007 Id:0900d8058098f336 13

Confidential
mcTC
BLCODE
The Boot Loadable Code Directory (BLCODE) contains the program code and the
MAFILE of a SW build. It also contains some files specific to the system level.
MMDIRE
The Man Machine Interface System Directory (MMDIRE) contains the MML programs
(all MML programs of a SW build and their text files).
LFILES
The Loadable Files Directory (LFILES) contains the loadable delivery-specific files and
databases of a SW build.
CONVPR
The Conversion Program Directory (CONVPR) contains the conversion programs. The
conversion programs are needed for the conversion runs performed during SW
updates.
ASWDIR
The Application Specific Workfile Directory (ASWDIR) contains the work files of the
applications. Files created by the user or by the software are stored in this directory. The
use of this directory varies according to the network element. For example, the ASWDIR
stores the history data of change deliveries.
CDTEMP
The Change Delivery Temporary File Store (CDTEMP) directory is used during the
change delivery installation.
WEBFIL
This HTTP Server Root Directory and its subdirectories are used for Web Based Man-
agement of the network element. Some software configuration management actions can
be directed to these subdirectories. Do not change the names of these subdirectories.
The subdirectories of WEBFIL are as follows:
Directory Explanation
CGI Directory for CGI Applications
SCRIPT Directory for scripts related to web-based management
APPS Directory for applications related to web-based manage-
ment
HTDOCS Directory for HTML documents
ICONS Directory for icons used in web-based management
GRAPHICS Directory for graphics used in web-based management
Table 1 Subdirectories of WEBFIL
2.1.2.2 Status of a SW build

The hard disk of a network element can contain several SW builds at the same time.
Each SW build is stored in its own directory. In a normal situation, there are at least two
14 Id:0900d8058098f336 DN0989007 DN0989007

Confidential
mcTC
SW builds, the running SW build (BU) and the fallback copy (FB). When the system is
being updated, there is also a third SW build, the new (NW) build.
There can also be some SW builds in the UT status and UD status stored on the disk of
a network element. Usually, these are old SW builds that have not been removed from
the system.
The UT build can also be a new one. When installing a change delivery, the new SW
build is stored into the same directory as the running SW build (usually the BU build) and
the new build is set in the UT status. After that, the activity and the status of the builds
have to be switched with the WSS command.
Every SW build that is created by using the commands of software configuration man-
agement and stored on a disk has a certain working status. (See Figure Statuses of a
created SW build). The possible statuses are as follows:
BACKUP (BU)
BACKUP is the status of a SW build that is stored on a disk and normally defined as the
active, running SW build. Usually the BU build is also the default build, which means that
when the network element starts up, the initial loading system loads the BU build. The
BU build cannot be destroyed by using the SW build management commands. Only one
BU build can be stored on the disk at a time.
FALLBACK (FB)
FALLBACK is the status of a SW build that is a fallback copy of the BU build. In principle,
the FB build is the same as the BU build, except that its data is from the copying
moment, which means that data updated in the BU build after the copying of the FB build
is missing. When the whole SW build is fallback copied (FULL parameter), that is, the
BU build is copied as the FB build, the status of the old FB build automatically changes
into UT. When a fallback copy is made either of all files marked DATA in the MAFILE or
only of changed files (ARCHIVE), the files are copied on top of the previous FB build.
When necessary, you can restore the system to the FB build by using the WSD
command. The use of the FB build has to be resumed, for example, when the BU build
becomes corrupted.
Only one SW build on the disk can be in the FB status at a time.
NEW (NW)
NEW is the status of a new SW build on the disk. The NW build is brought into the
network element first to be tested and then to be deployed. Only one SW build on the
disk can have the NW status at a time.
UNTITLED (UT)
UNTITLED is the status of a SW build stored on a disk. The system can contain several
SW builds that are in the UT status, and they can be stored in their own directories.
Usually, the SW builds which have the UT status are old ones, and they can be deleted.
However, the change delivery introduces the update as a UT build in the same directory
as the BU build.
UNDEFINED (UD)
All the above mentioned are created SW builds. There can also be some uncreated SW
builds on the disk. The status of an uncreated SW build is undefined.
SW builds that are in the UD status can only be referred to in the directory. If there is
more than one uncreated SW builds in the directory, you need to give more information
DN0989007 DN0989007 Id:0900d8058098f336 15

Confidential
mcTC
to specify the builds. When a new uncreated SW update build is copied to the hard disk,
the system automatically sets it to the UD status in order to define it. The SW builds in
the UD status are only visible in the output commands. Several SW builds can be in the
UD status on the disk at the same time.
Changing the status of a SW build

You can change the status of SW builds by using the commands of Software Package
Status Handling, WS command group. The best time to change the status of SW builds
is when the SW is being updated. Also, when a new FB copy is being made of the whole
BU build (FULL parameter), the status of the previous FB build changes to UT (WKS
command).
(Note: the WKS command creates a new SW build,

the status of BU build does not change)
Fallback copy (WKS)
Switch active package (WSS)
FB BU
Rollback statuses (WSR)
Rollback Change
statuses of status
(WSR) (WSC)
Fallback copy (WKS) Change of status (WSC)

with parameter
NW Switch active package (WSS) UT
FULL
Rollback statuses (WSR)
Figure 2 Statuses of a created SW build
Commands related to the states of SW builds

For instructions on the use of the commands presented in Figure Statuses of a created
SW build, see:
WKS Start fallback copying
WSC Change status of two created packages
WSS Switch active package in directory
WSR Rollback statuses of created packages.
However, in a redundant HLR, the WSD command can even be used to activate UT SW
builds directly. This use of the command is specific to the redundant HLR only.
16 Id:0900d8058098f336 DN0989007 DN0989007

Confidential
mcTC
Status of a SW build during a software update

The following two figures illustrate how the SW build status, its activity and the default
build data change in update situations. The figures also show which build is running in
each situation.
• Deployment of a new SW build
The following figure shows the status of the SW builds stored in different directories,
when a new SW build is being deployed in the network element.
Situation Command Directory Active Traffic Trial

Status Default side side
Normal situation A NW x - - -
(a new SW build has been
created in the directory WQC B BU x x x -
with command WQC) C FB x - - -
OMU is added to the trial A NW x x - x
configuration (command WRA)
(default build becomes NW) WRA B BU x x x -
All other units are added to
trial configuration C FB x - - -
Cutover A NW x x x -
WRS B BU x - - x
C FB x - - -
Completing the trial A NW x x x -
configuration
WRC B BU x - - -
C FB x - - -
Change of status A BU x x x -
WSC B NW x - - -
C FB x - - -
Figure 3 The effects of a new SW build deployment on other SW builds
g The figure shows a situation where the network element has two OMUs. Adding an OMU
in the trial configuration (the WRA command) automatically makes the NW build the
default build in the current OMU, and the BU remains the default build of the traffic side
OMU. If the system has only one OMU and the OMU is added to the trial configuration,
only the NW build is the default build.
• Deployment of a change delivery

The following figure shows the status of the SW builds stored in different directories
when a change delivery is being installed in the same directory as the BU build.
DN0989007 DN0989007 Id:0900d8058098f336 17

Confidential
mcTC
Situation Command Directory Active Running

Status Default
Normal situation A NW x - -
B BU x x x
C FB x - -
Installing a change delivery to the A NW x - -
same directory as the BU build (B) WNA
and creating a SW build B BU x x x
and UT - - -
(Change delivery could also be installed WQC
in the directory of the NW build) C FB x - -
Switch the active SW build A NW x - -
(BU becomes UT and UT becomes BU)
B UT - - x
WSS
BU x x -
C FB x - -
Deploy a change delivery by restarting A NW x - -
the selected units and by updating USU, USC,
the new SW build identity in the units WNJ and B UT - - -
BU x x x
UST
C FB x - -
Delete the old SW build A NW x - -
(the UT build from the B directory)
which brings the system back to the WQD B BU x x x
normal situation C FB x - -
Figure 4 The effects of a change delivery deployment on other SW builds of the

network element
2.1.2.3 Disk file versions

There can be several files of the same name in a directory, but the files have different
disk version numbers. In a SW build directory, however, the maximum number of disk
versions is two by default, and one of the versions is the default version.
It is not recommended to change the default value (2) because software configuration
management uses the file identity data in handling the SW builds, and it cannot recog-
nize two different disk files if they have the same name and the same identity code and
neither of them is the default version. The system is able to separate the default version
and the non-default versions from each other. The I/O system recognizes both disk ver-
sions. The loading system and the disk update system recognize the default version
only.
The main purpose of the disk file versioning is to make it possible to introduce small
(compatible) software updates to a network element so that only a minimal amount of
disturbance is caused in the traffic. The software that will be changed is copied to the
same directory as the currently loaded SW build, then the new software is defined as
the default version in the directory, and finally the changed parts are loaded in the
network element.
When the SW build is being changed, software configuration management sets the
default version of the load module by using the identity data of the load module. You do
not need to handle the disk version data of the files, since the software manages them
automatically.
18 Id:0900d8058098f336 DN0989007 DN0989007

Confidential
mcTC
2.1.3 Update deliveries

A software update is a general term referring to a software change deployed in a
network element that has already been delivered to a telecommunication operator. The
largest possible software update changes all the components of a SW build. The
smallest possible software update changes only one component of the software.
The types of software updates can be the following:
1. New SW build deliveries
• release-level upgrades (major updates)
• correction updates (minor updates)
• functionality-level upgrades (minor updates)
2. Change deliveries
The deployment of a software update is affected by the functional compatibility and file
compatibility of the update and the SW build currently running in the network element.
From the software configuration management point of view, the new software is either
compatible or non-compatible with the old software. The files in the SW build are either
compatible or require conversion.
Update deliveries are delivered on removable media, for example, optical discs and
USB mass storage devices can be used for this purpose.
2.1.3.1 New SW build deliveries

A new SW build can be delivered either as a completely new build, which results in a
release-level upgrade (major), or as an update to the old SW build (minor) meaning that
the old SW build can be copied as the base for the new build. Usually, the delivery of a
new SW build has the following characteristics:
• requires file conversion
• is brought as a NW build in a directory of its own
• is done through trial configuration
• causes interruptions in traffic
2.1.3.2 Change deliveries

A change delivery is usually preceded by a change delivery request. A change delivery
consists of one or more change notes. A change note explains the difference between
the old and the new product, the reason for the change, and the effects of the change
on the functions of the product. A change delivery is usually installed by using
commands specially designed for this purpose.
Sometimes in an exceptional situation a minor software update has to be introduced
resembling a change delivery in a network element. It has to be copied directly to the
same directory as the old SW build and set as the default version. These kinds of deliv-
eries are used in emergency situations, and they usually cause disturbance for software
configuration management and some parts of the change delivery.
The characteristics of change delivery are the following:
• It is a correction of a detected fault, or an introduction of a new functionality to the
existing software.
DN0989007 DN0989007 Id:0900d8058098f336 19

Confidential
mcTC
• It contains new load modules, operating instructions, a change delivery description

list and instructions for installation.
• It does not cause interrupts in traffic if it is warm-up compatible. However, if the
update requires a restart of the network element, there can be an interruption in the
traffic.
• It is either functionally warm-up compatible or requires the network element to be
restarted.
• It is installed in the running BU build, and file conversions are not necessary. A small
software update resembling a change delivery can also be made to the NW build,
for example, to aid the installation of a new SW build delivery. If there are no NW
builds running, it is possible to make a file conversion if necessary. File conversions
are not allowed in running NW builds.
• It is created as a UT build into the directory of a BU build (or NW build). If that direc-
tory already contains a UT build, you have to delete it first by using the WQD
command. When updating the software, it is possible to have more than one version
of each file in the directory of the BU build (or NW build), but this is not recom-
mended.
Main installation tasks

Main installation tasks for a change delivery are the following:
• Copying the files for a change delivery to the CDTEMP directory of the current
software build.
• Making the actual installation by one MML command, which means that new load
modules are copied to the right directories, a new MAFILE (if not included in the
delivery) is created and the history information is updated. Several change deliveries
can be installed with one MML command.
• Creating a new software build for a change delivery with an MML command to the
same directory as the old build.
• Activating the new build with an MML command, in which new load modules are
changed from non-default to default versions.
• Activating the changes by restarting the corresponding units. New build id is updated
in the units during restarts.
• Updating the package id in the rest of the units with MML commands.
• Deleting the old build if the installed change delivery works properly.
2.1.3.3 Software update compatibility

In the perspective of software configuration management, there are two kinds of
software updates:
• Compatible software updates
• Non-compatible software updates
There can also be some intermediate forms of non-compatible software updates, which
can be used, for example, with the methods of installing a compatible software update.
For detailed instructions, see the installation operating instructions of the relevant
update delivery.
Compatible software update

The new software is purely functional and data-compatible. Taking compatible software
update into use does not cause traffic disturbances. Telecommunication connections
20 Id:0900d8058098f336 DN0989007 DN0989007

Confidential
mcTC
can be created from computer units running the old software build to computer units
running the new software build. The update process is executed unit by unit by restarting
and switching over the units. During the software update installation, the old and the new
build can communicate with each other.
Non-compatible software update

The new software is not functional or data-compatible in some parts of the software.
Non-compatible software update has to be used simultaneously in all necessary
computer units. This requires restarting the whole system. Non-compatible software
update causes disturbances or total breakdown in the operating state (including tele-
communication connections) of the network element. During the software update instal-
lation, the old and the new software cannot communicate with each other.
Embedded software
The CPU and several other hardware items include embedded software. When a new
network element is taken into use or faulty hardware items are replaced with new ones,
we recommend that you make sure the hardware includes the correct versions of the
eSW.
For instructions on how to check and upgrade eSW packages, see the maintaining and
troubleshooting hardware related documents, commissioning and integrating related
documents and the Embedded Software Handling Command Reference Manual
(command group WD).
For information about the different types of eSW, see the related hardware documenta-
tion.
DN0989007 DN0989007 Id:0900d8058098f336 21

Confidential
mcTC
2.2 Preparing the system for software update

A software update is a general term referring to a software change deployed in a
network element that has already been delivered to a telecommunications operator. The
largest possible software update is the one that changes all the components of a SW
build. The smallest possible software update changes only one component.
g The prerequisites are different for each release. Only the basic prerequisites that apply
to all updates are presented here.
Before starting an update

We recommend performing the software update during low traffic. Before starting an
update, pay attention to the following issues:
g The ETME/ETMA units need to be restarted manually after activating the fallback (or in
any scenario when the software package is changed with system restart).
Steps
1 Check the alarms (AHO).

Output the active alarms:
ZAHO;
If there are active alarms, find out what caused them. There must not be any active
alarms in the network element when you start the update.
2 Print out the old data.

Print out the data concerning the old SW build for future reference.
3 Make sure that the fallback copy (FB) of the BU build is up-to-date (WQH).
Use the WQH command to output the history data on the SW build changes.
Specify in the parameter the date from which the history data is reported. The WQO
command outputs data concerning the specified SW build.
4 Check the working states of the units (USI).

The computer units must be in normal working states (the USI command), either in the
WO-EX or SP-EX state, and there must not be any FLTY (faulty unit) additional informa-
tion.
The units can also be in the SE-NH state if the update does not affect those units.
For more information, see the related troubleshooting documents.
5 Check the working states of the timeslots on the external routes (RCI).
g This step is only valid for network elements with TDM connections.
If there are too many external routes and timeslots, it is usually enough to take a
sample of them (for example, the first 10 timeslots) for the check-up.
The working states of the timeslots in the external routes must not change in the update.
22 Id:0900d8058098f330 DN0989007 DN0989007

Confidential
mcTC
6 Make sure that the BU build is the default build (WQO).

Make sure that the BU build is the default build and that it is loaded in all units:
ZWQO:CR;
In the printout, Y is marked in the Default column by the default SW build.
ZWQO:RUN;
If not all units have the default build loaded, give the reset command to those units that
have some other build loaded.
g Instead of using reset, you can first try the WNJ command, which updates in all units the
SW build identity that the OMU is using.
7 Check if the disk of the network element has space for a new build (WQO).
Check how much space there is on the disk:
ZWQO:EX;
You can free more space by deleting old builds that are not used any more, using the
WQD command.
Further information
For more instructions on software configuration management, see Installing and deploy-
ing a change delivery and Deleting old SW builds.
DN0989007 DN0989007 Id:0900d8058098f330 23

Confidential
mcTC
2.3 Installing and deploying new software build
g Detailed instructions for making a software update are given in the installation manuals
of the relevant SW build. The instructions given here are examples, and they only
contain the basics of the update process. All software updates do not necessarily
include all the phases described here, and on the other hand, some updates require
more phases.
2.3.1 Creating directories and copying the SW build

The new SW build is usually copied to the network element at the site and introduced to
the network on removable media or through FTP.
When a whole new software build is delivered, the SW build is copied into the network
element as follows:
Steps
1 Copy the SW build and its directories to the network element.

a) Copy the SW build and its directories from the UMS device (IWL).
1. Create a new directory and subdirectories for it.
Create first a new directory and then subdirectories BLCODE, LFILES,
MMDIRE, CONVPR and ASWDIR in it.
If temporary directory is used in the update process, create a temporary
TMPDIR directory for conversions:
ZIWL::WSB,NODEF:<directory>:<new_subdirectory_name>,800,2,
XY;
If temporary directory is not used, replace all TMPDIR with LFILES in the insturc-
tions described in the installation procedures.
2. Copy the SW build (commands IWY and IBC).
Copy the SW build, for example, the 'standard' build, into a new directory on the
system disk:
ZIWY:S:UNIT=OMU,PATH=/<subdirectory name>,DRIVE=UMS-00;
ZIWY:D:UNIT=OMU,PATH=/<new directory>/<subdirectory name>,
DRIVE=WDU-S;
ZIBC;
If the update process includes conversions from the old SW build CONVPR
directory, copy the relevant conversions there with the IWY and IBC commands.
b) Copy the SW build using FTP protocol and compressed SW build image. The image
consists of all SW build files in the correct directory format.
1. If temporary directory is used in the update process, create a temporary
TMPDIR directory for conversions:
ZIWL::WSB,NODEF:<directory>:<new_subdirectory_name>,800,2,
XY;
If temporary directory is not used, replace all TMPDIR with LFILES in the insturc-
tions described in the installation procedures.
2. Copy the ZIP file from external network resource to the network element.
3. Check the ZIP file content.
ZIXL:,,<zip file directory>,<zip file name>.ZIP;
It is important to check that the SW build directory in use is correct.
24 Id:0900d80580913629 DN0989007 DN0989007

Confidential
mcTC
4. Unzip SW build.
ZIXX:,, <zip file directory>,<zip file
name>.ZIP:,:,,/:TIME=1600;
SW build will be extracted from the ZIP file to the correct directory structure on
the system disk. Unzipping the complete SW build takes about 15 minutes.
2 Copy other necessary release-specific files (IWY and IBC).

ZIWY;
ZIBC;
3 Copy all directories (IWY and IBC).

Copy all directories, except the LFILES directory, from the system side to the backup
side.
ZIWY:S:UNIT=OMU,PATH=/<new directory>/<subdirectory name>,
DRIVE=WDU-S; (System)
ZIWY:D:UNIT=OMU,PATH=/<new directory>/<subdirectory name>,
DRIVE=WDU-B; (Backup)
ZIBC:,,,,,,,,,DIR:;
4 Copy other files (IWY and IBC).

If the TMPDIR is used in the update process, copy both the release-specific parameter
files needed for conversions and the other files from the new directory to the temporary
directory. Files to be copied include the MAFILE, MEFILE and DXPFIL. In the IBC
command parameter, you should specify the name of the file you want to copy (or at
least a part of the name, for example, MAF%).
ZIWY:S:UNIT=OMU,PATH=/<new
directory>/<subdirectory_name>,DRIVE=WDU-S;
ZIWY:D:UNIT=OMU,PATH=/<new directory>/TMPDIR,DRIVE=WDU-S;
ZIBC:,,MAF%,%;
5 Check the lengths of the DXPFILGX files (LP and PD).

Check the lengths of the DXPFILGX files stored in the units that have disks, using the
service terminal commands LP/LE and PD. The DXPFILGX includes, for example, the
following file lengths:
ZLP:P,FUT;
You can also use LE command instead of LP:
ZLE:P,FUTILIGX;
ZPD:LFILES;
If the PD command reports differences in file lengths, you have to find out what causes
the differences. If the differences cause no problems, update the contents of the
DXPFILGX file according to the actual file lengths:
ZPDU:LFILES;
DN0989007 DN0989007 Id:0900d80580913629 25

Confidential
mcTC
6 Print the Readme.txt file (IWY and IBT).

Print the Readme.txt file if the MMDIRE directory contains one. The Readme.txt file
contains such information as how much memory each unit needs in order to operate
properly with the new SW build.
ZIWY:S:PATH=<new directory>/MMDIRE;
ZIBT:WDU,0,README,TXT,,200,,A;
2.3.2 Converting and copying files

For more information, see Software builds.
Steps
1 Copy the new SW build files (IWY, IBC).

Copy the new SW build files that will be needed in the conversion to the TMPDIR
working directory of the system disk as default versions (MAFILE, MEFILE, DXPFIL,
NECONF and the new file templates, if necessary). The following example shows
copying the MAFILE from the BLCODE directory to the working directory:
ZIWY:S:UNIT=OMU,PATH=/<new directory>/BLCODE,DRIVE=WDU-S;
ZIBC:,,MAFILEGX,IMG;
2 Prevent updates (DUP, DBP).

Prevent file updates to disk in all units and prevent all database updates (if databases
also need conversion):
ZDUP:<unit>;
ZDBP:<name of data base>,0:DISK;
3 Copy the necessary files from the old SW build to the new one.
• Use the copy command queue (IDE), if the system has one.
Before you use the IDE copy command queue, the command queue files must be
first copied to the MMDIRE directory of the current active package:
ZIWY:S:UNIT=OMU,PATH=/<new_directory>/<subdirectory name>,
DRIVE=WDU-S;
ZIWY:D:UNIT=OMU,PATH=/<current active package
directory>/<MMDIRE>,DRIVE=WDU-S;
ZIBC:,,<name of the file to be copied>,%;
Run the command queue IDE.
Usually all other files are copied using the copy command queue, which means you
have to specify the copy command queue you want to use. Use parameter PAR1 to
define the source directory and PAR2 to specify the destination directory.
ZIDE:,WDU,0,<name of conversion command queue>:: PAR1="/old
directory/LFILES",PAR2="/new directory/TMPDIR";
Or:
ZIDE:,,<name of conversion command queue>:OUTFILE=VDU;
26 Id:0900d80580913629 DN0989007 DN0989007

Confidential
mcTC
• Copy manually the necessary files (IWY and IBC).

If the system does not have the copy command queue (IDE), copy manually the
necessary files from the old SW build to the new one.
ZIWY:S:UNIT=OMU,PATH=/<old_directory>/<subdirectory name>,
DRIVE=WDU-S;
ZIWY:D:UNIT=OMU,PATH=/<new_directory>/<subdirectory name>,
DRIVE=WDU-S;
ZIBC:,,<name of the file to be copied>,<extension of the
file>,%;
4 Run the necessary file conversions or the conversion command queue (IDE).
Run the conversion from the source SW build (usually BU) to the files in the working
directory (TMPDIR). For example:
ZIDE:WDU,0,<name of conversion command queue>::PAR1="/<old
directory>/LFILES", PAR2="/<new_directory>/TMPDIR";
5 Run the database conversions (IWY, DEE).

ZIWY:S:UNIT=OMU,PATH=/<old directory>/<subdirectory
name>,DRIVE=WDU-S;
ZDEE:,:CONVPR,,:<name of conversion program>;
6 Copy the other files (DEM).

Copy files that do not need conversion from the source build to the temporary working
directory.
ZDEM:<source file name>,%:<destination file name>,%:MODE=<>;
g If the version of the XIPIFCGX.XML file is 1.3-0 in the old package and 1.6-0 in the new
package, you must convert the file in the old package to version 1.6-0 before you
proceed. You can check the file versions with the following commands:
ZIWY:S:PATH=/<old package>/LFILES/,DRIVE=WDU-S;
ZIBT:WDU,S,XIPIFCGX%,XML,,,,A;
ZIWY:S:PATH=/<new_package>/LFILES/,DRIVE=WDU-S;
ZIBT:WDU,S,XIPIFCGX%,XML,,,,A;
If the version of XIPIFCGX.XML is 1.3-0 in the old package and 1.6-0 in the new
package, continue with the following steps.
a) Create a source directory, for example: SRC.
ZIWL::WSB,NODEF:<new_package>:SRC,800,2,XY;
b) Copy XIPIFCGX.XML from the old package directory to the SRC directory.
ZIWY:S:UNIT=OMU,PATH=/<old_package>/LFILES,DRIVE=WDU-S;
ZIWY:D:UNIT=OMU,PATH=/<new directory>/SRC,DRIVE=WDU-S;
ZIBC:,,XIPIFCGX,XML,;
DN0989007 DN0989007 Id:0900d80580913629 27

Confidential
mcTC
c) Copy MAFILEGX.IMG and MEF*.IMG from the new software package to the SRC
directory.
ZIBC:,,MAFILEGX,IMG;
ZIWY:S:UNIT=OMU,PATH=/<new directory>/LFILES,DRIVE=WDU-S;
ZIBC:,,MEF%,%;
d) Make sure you have copied MAFILE and MEFILE from the new software package
to the TMPDIR directory. (See step 4 under section 2.3.1 Creating directories and
copying the SW build)
e) Convert the old XIPIFCGX.XML file from the SRC directory to a new
XIPIFCGX.XML file in the TMPDIR directory with command ZDEM.
ZDEY:S:I:OMU:/<new_package>/SRC:WDU-S:;
ZDEY:D:I:OMU:/<new_package>/TMPDIR:WDU-S;
ZDEM:XIPIFCGX,XML:XIPIFCGX,XML:MODE=FORE:;
7 Allow updating of both files and databases to the disk (DUR, DBR).
ZDUR:<unit>;
ZDBR:<database name>,0:DISK;
8 Copy the converted files, if using TMPDIR.

If the TMPDIR directory is used in the conversion, copy the converted files from the
working directory to the LFILES directory of the new SW build. If the TMPDIR is not used
in the conversion, the files are already in the LFILES directory.
ZIWY:S:UNIT=OMU,PATH=/<new directory>/TMPDIR,DRIVE=WDU-S;
ZIWY:D:UNIT=OMU,PATH=/<new directory>/LFILES,DRIVE=WDU-S;
ZIBC;
9 Copy the LFILES subdirectory (IWY, IBC).

Copy the LFILES subdirectory of the new directory from the system disk to the backup
disk.
ZIWY:S:UNIT=OMU,PATH=/<new directory>/LFILES,DRIVE=WDU-S;
(System)
ZIWY:D:UNIT=OMU,PATH=/<new directory>/LFILES,DRIVE=WDU-B;
(Backup)
ZIBC;
10 Copy the DMX Boot to disk root (IWY, IBC).

Copy the DMX Boot from new SW build to disk root.
ZIWY:D:UNIT=OMU,PATH=/,DRIVE=WDU-SB;
ZIBC:,,BOLEROGX,IMG;
28 Id:0900d80580913629 DN0989007 DN0989007

Confidential
mcTC
11 Delete all files except the default files from the subdirectories in the new directory
(IWD).
ZIWD:,:WSB,NODEF:<new directory>,<subdirectory name>:%,%,FF;
2.3.3 Creating a SW build

Steps
1 Create the SW build and set it in the NW status (WQC).

The status of a new build must be NEW (NW), otherwise you cannot create a trial con-
figuration.
ZWQC:NAME=<new SW build>,PAID=<SW build identity>, DIRE=<new
directory>,STAT=NW,ENVI=<SW build environment>, DELI=<name and
version of the delivery>;
Further information
If the network element already has an NW build that is not needed any more, you can
destroy the build by using the WQD command, and then create a new SW build in the NW
status.
If the network element already has an NW build and you want to keep it, create the
newest build first in the UT status. In this case, you do not specify the status in the WQC
command, but the system automatically sets the new build in the UT status after creating
it.
When the creation is completed, you can exchange the statuses of the NW and the UT
build by using the WSC command. For example:
ZWSC:NAME=<name of new build>:STAT=NW;
2.3.4 Creating a trial configuration

Before you start
1. Before you form a trial configuration, make sure that the units are in normal states
and copy or convert the PCMCON and SCDFLE files located in the LFILES direc-
tory, from the old SW build to the new one. If the files have not been changed, copy
them with either the IWY and IBC commands or the DEM command. If the files have
been changed, convert them with the DEE command.
2. If IM1FIL has not been copied or converted before, copy or convert it from the
ASWDIR directory. IM1FIL records the IUA connections for ETPA, ETPT, ETPE,
ETPC, ETMA, MCTC and PTUM. After IM1FIL has been copied and converted,
check the IUA connections with the D2I command.
3. Create the trial configuration. The trial configuration can be created unit by unit, or
by using the default configuration (basic trial configuration) suggested by the system
(use parameter BASE). Usually the basic trial configuration is used.
For more information on IUA connections, see Signalling Transport over IP (M3UA and
IUA).
DN0989007 DN0989007 Id:0900d80580913629 29

Confidential
mcTC
Steps
1 Add the OMU to the trial configuration (WRA).

Before the command is given, make sure that the default build has the BU status.
ZWRA:OMU;
The WRA command makes the NW build the default build and restarts the OMU.
2 Add the backup central memory unit to the trial configuration (WRA).
Depending on configuration, central memory unit can be the MCHU, MCMU, CM or
CMM unit type.
g Modifying trial configuration is done on the trial side MML session. You have to either
use VIMMLA service terminal extension or configure a different O&M IP address to the
trial side OMU.
For example:
00:MAN> ZLP:1,VIM
00:VIM> 1
00:VIM> CT:
ZWRA:<central memory>,1;
Wait until the unit is up and running before you continue.
3 Add units to the trial configuration (WRA).

Next, add to the trial configuration the units which you want to add separately, without
using the basic trial configuration. (If there is no need to add the units separately, it is
possible to give the command ZWRA:BASE; at this point.)
The unit is selected depending on which external connections you want to maintain
during the testing period. Leave on the traffic side the units of the external connections
that you want to keep.
ZWRA:<unit type>,<unit index>;
4 Check that the IUA connections are not changed (D2I).

If you have added BCSU/BCXU to the trial configuration, check the IUA connections and
make sure they are not changed.
ZD2I;
5 Add the rest of the units to the trial configuration (WRA).

ZWRA:BASE;
Further information
Add the units in the trial configuration in the order which is shown in Table Creating a
trial configuration.
30 Id:0900d80580913629 DN0989007 DN0989007

Confidential
mcTC
State/Command Traffic side Trial side

Normal situation before a trial WO SP
configuration is created
OMU
MCMU-0 MCMU-1
<unit1>-0 <unit1>-1
<unit2>-1 <unit2>-0
After OMU has been added to trial MCMU-0 MCMU-1 OMU
side WRA:OMU; <unit1>-0 <unit1>-1
<unit2>-1 <unit2>-0
After MCMU has been added to trial MCMU-0 OMU
side WRA:MCMU,1; <unit1>-0 <unit1>-1 MCMU-1
<unit2>-1 <unit2>-0
After the selected unit has been MCMU-0 OMU
added to the trial <unit1>-0 MCMU-1
side WRA:<unit1>,1;
<unit2>-1 <unit2>-0 <unit1>-1
Finally, add all the remaining units to MCMU-0 OMU
the trial configuration by using the <unit1>-0 MCMU-1
base trial configuration. QRA:BASE;
<unit2>-1 <unit1>-1
<unit2>-0
Table 2 Creating a trial configuration
You can also form a trial configuration by separately adding all selected units to the trial
configuration. Remember that when you add an N+1 backed up signaling unit to the trial
side, you can define the unit (on the traffic side in this phase) whose lines the signaling
unit will start serving after a cutover. This saves time for the cutover in that unit and its
lines will also be back in the traffic transmitting mode sooner.
If necessary, you can remove units from the trial configuration. For example, if you want
to remove MCMU-1 from the trial side, give the following command:
ZWRR:MCMU,1;
2.3.5 Making necessary modifications

Steps
1 Make all necessary changes to the new SW build in the trial configuration.
New functionalities are often introduced when changing from an old SW build to a new
one, and the update may cause changes that demand modifications in the new SW
build. You should make these changes when the new SW build is tested in the trial con-
figuration.
DN0989007 DN0989007 Id:0900d80580913629 31

Confidential
mcTC
Before you carry out the update, print the same data as in the preparations phase, and
compare them with each other.
Make all necessary updates.
2 Test the new SW build.

Test the new SW build (MML output commands, partial unit diagnostics, etc.)
Remember that the equipment management commands (WT) must not be given while
the system has a trial configuration, because the configuration has to remain the same
on both the traffic side and the trial side.
g During the trial configuration on classic mechanics, complete diagnostics cannot be run
on a unit if the unit has plug-in units with PCM line interfaces. This is because the plug-
in units have not been connected to the active switching network in this situation.
However, those parts of the diagnostics that do not test the interfaces operate in a
normal manner.
3 If necessary, you can remove a unit from the trial configuration (WRR).
Remove a unit from the trial configuration on the trial side MML session.
ZWRR:<unit type>,<unit index>;
4 You can also interrupt the testing and delete the trial configuration.
If necessary, you can also interrupt the testing and delete the trial configuration (for
example, if faults occur on the traffic side).
Steps
a Destroy the trial configuration (WRD).

Note that you can give the WRD command only in the MML terminal of the trial side.
In addition, the trial side OMU must have the NEWP additional information set. You
can perform the command in a controlled manner or in a forced manner. By default,
the destroying is carried out in a controlled manner, and this setting needs no
parameters.
ZWRD;
b Check that the IUA connections are not changed (D2I).

The IUA connections should remain unchanged after destroying the trial configura-
tion.
ZD2I;
c Enter the 'complete new configuration' command (WRC).

Enter the 'complete new configuration' command (WRC) to make sure that all addi-
tional information set during the trial configuration are deleted and that the traffic
side is completed with the units transferred from the trial side.
ZWRC;
32 Id:0900d80580913629 DN0989007 DN0989007

Confidential
mcTC
d Check that the modifying of disk is not prevented (DUD).

ZDUD:<unit to be checked>,<unit index>;
e Form the trial configuration again.

If you want to form the trial configuration again, you have to first convert the
PCMCON file and SCDFLE file (DEE) or copy them with the DEM command from the
BU build to the directory of the new SW build.
After this you can continue from Creating a trial configuration.
Further information
g Testing of an SW build stops only when the new software is deployed and taken into use
or if the trial configuration is deleted.
2.3.6 Cutting over to a new SW build

In the cutover process the trial side becomes the traffic side and the old traffic side
becomes the trial side.
Steps
1 Perform the cutover (WRS).

Note that you have to give the WRS command on the MML terminal of the trial side. The
OMU must have the NEWP additional information set.
When you give this command, the traffic will be interrupted. After a short outage, the
network element starts handling teletraffic by using the new software.
Cutover can be made when at least OMU and central memory unit are in trial system. If
there are units of each computer unit type in the trial system, the cutover can be made
without the FCD parameter. Otherwise the FCD parameter can be used to get all units
to the new tele system, except those selected with the WRA commands as old package
units to remain running the original SW build.
ZWRS;
Expected outcome
After the command is given and the cutover has been performed, the new software
becomes responsible for handling actual telecommunications traffic in the network
element. In case of duplicated units, the responsibility is transferred from one unit to the
other, but if the unit type is backed up using the N+1 method, the new software is loaded
in the N units and only the unit which has NOSW additional information keeps the old
software.
2 Check the IUA connections after the cutover (D2I).

The IUA connections associated with BCSU/BCXU change accordingly.
For example, There are two pairs of units BCXU-0 (WO), BCXU-2 (SP) and BCXU-1
(WO), BCXU-3 (SP); the units in SP state are redundant units for the two WO units
respectively. During the trial configuration, BCXU-3 is transferred to the trial side before
cutover and the state becomes WO. The IUA connections originally associated with
DN0989007 DN0989007 Id:0900d80580913629 33

Confidential
mcTC
BCXU-1 change and associate with BCXU-3 after cutover. However, the state and con-
nections for BCXU-0 and BCXU-2 pair remains the same after they are transferred to
the trial side. BCXU-1 remains at the tele side in WO state.
You can use the D2I command to check if the IUA connections are correct:
ZD2I;
3 Test that the new software operates correctly.

Test that the new software operates correctly when transmitting traffic. Make test calls
and check that analyses, charging, and general traffic function as they should; you can
make printouts, for instance.
4 Transfer the rest of the units to the traffic side (WRC).

When you make sure that the new software functions faultlessly, you can stop the
testing, clear the trial configuration and transfer the rest of the units to the traffic side.
ZWRC;
g You can return to using the old SW build (command WSD), in which case the default build
changes and the whole system is restarted.
ZWSD:STAT=BU;
5 Return to the old build, if necessary.

If the new software does not function well enough, return to the old build. Then you can
continue testing the new software or stop the testing, if that is necessary.
a) Cancel the cutover and return to the old software (WRO).
ZWRO;
b) Continue testing the new software.
If necessary, continue testing the new software (test the MML output commands,
partial diagnostics in the units, etc.).
c) If you stop the testing, destroy the trial configuration (WRD).
ZWRD;
d) Give the complete configuration command (WRC).
Finally, give the complete configuration command to make sure that all additional
information appeared during the trial phase is deleted:
ZWRC;
g When you cancel the cutover or stop testing to return to the old build, IUA connections
to the units resume their original state. Use the D2I command to check the connections.
2.3.7 Completing the update process

For more information, see Software builds, Preparing the system for software update,
Installing and deploying a change delivery and Deleting old SW builds.
34 Id:0900d80580913629 DN0989007 DN0989007

Confidential
mcTC
Steps
1 Exchange the BU and NW statuses (WSC).

ZWSC:STAT=BU:NAME=<new SW build>;
2 Make a fallback copy.

See instructions in Backup and Restore.
3 Verify the SW build (WQB).

Verify the SW build by checking with command WQB that a comparison can be run.
4 Check that disk updating is not prevented in any unit (DUD).

ZDUD:<unit to be checked>;
5 Check the time slot states in the external routes (RCI).

Use the RCI command.
g This step is only valid for network elements with TDM connections.
6 If you have used a temporary directory, destroy it (IWD, IWM).

ZIWD:,:WSB,NODEF:<new directory>,TMPDIR:%,%;
ZIWM:,:WSB,NODEF:<new directory>:TMPDIR;
7 Destroy all non-default versions (IWD).

Destroy all non-default versions from the subdirectories (CONVPR,MMDIRE, BLCODE
and LFILES) of the new directory:
ZIWD:,:WSB,NODEF:<new directory>,<subdirectory name>:%,%,FF;
8 Test that changeovers function properly.

You can test that the changeovers function properly. Change the states of some units.
ZUSC:<unit type>, <unit index>: <working state>;
9 Destroy the old SW build (WQD).

Destroy the old SW build (currently having status NW) if it is not needed any more.
ZWQD:STAT=NW: MAFILE;
Further information
When the LAN device integration feature is used, update the Ethernet LAN switches
according to the instructions in Updating the software package of a LAN switch in Inte-
grated LAN Administration. Otherwise, see the instructions in Updating software image
to ESA12, ESA24, ESB20, ESB20-A, and ESB26 Ethernet switches.
DN0989007 DN0989007 Id:0900d80580913629 35

Confidential
mcTC
2.4 Installing and deploying a change delivery
g When installing a change delivery, follow the instructions provided with the software.
36 Id:0900d805808ab5ab DN0989007 DN0989007

Confidential
mcTC
2.5 Deleting old software builds

Deleting old SW builds consists of removing software package information from the
Software Management File (SOMAFI) and deleting files and directories of the software
package from the hard disk.
You can delete an old SW build from a directory with the WQD command. If there are two
builds in the directory, the SW build to be deleted must not be active and the status of
the SW build must not be 'BU'. You can delete the SW build by specifying its name,
status or directory.
For more general information about software builds, see Software builds.
Steps
1 Delete the SW build (WQD).

Use the name, status or directory of the SW build to specify the build you want to delete.
You can also use the DIRE or MAFILE deleting mode.
For example, you can give the name, status or directory to specify the build and the
deleting mode.
ZWQD:NAME=<SW build name>:MAFILE;
ZWQD:STAT=<SW build status>:MAFILE;
ZWQD:DIRE=<directory name>:MAFILE;
If you want to delete the SW build from one unit, give the destination unit in the following
command:
ZWQD:NAME=<SW build name>:MAFILE:MASU=<destination unit>;
2 Remove the build from SOMAFI(S).

Enter 'Y' when the program asks you whether you want to remove the build from
SOMAFI(S).
3 Confirm or cancel the deletion from the disks.

The program asks you whether you want to delete the SW build from the disks.
• If you enter ‘Y’ and confirms the deletion, the package will be removed from the
disks. In this case, you cannot re-activate the software build, unless you have a
backup copy on another media (for example, a removable media).
• If you enter 'N' and cancel the deletion, the package will not be removed from the
disks. After this operation, the status of the build becomes 'UD'. You can re-activate
the SW build by creating a build with the WQC command.
DN0989007 DN0989007 Id:0900d805808a192b 37

Confidential
Software configuration management in mcTC Software Configuration Management in mcBSC and
mcTC
3 Software configuration management in

mcTC
3.1 Software configuration management in mcTC

Software configuration management in mcTC gives an overall picture of how the
software build of mcTC is managed. The SCM consists of several files and programs.
By using the software configuration management functions, you can:
• Manage software builds:
– Copy the software build to be installed to the recomended directory
– Make backup copies of the software in the mcTC
For more information, see instructions in Backup and Restore in mcTC in Safe-
copying in BSC, mcBSC and mcTC document.
– Delete installed software deliveries
• Install and activate a new software build
• Obtain information on the software builds of the mcTC:
– List currently active software deliveries
– Check software build statuses
• Install patch deliveries
• Check installed software version
SCLI command for software configuration management
Command Function
set sw-manage Installing and activating software build
show sw-manage Listing currently active software delivery
mctccli patch Manage software patch delivery
mctccli getmctcswver Check installed software version
delete sw-manage Delete software delivery
Table 3 mcTC SCLI command for software configuration management
For details on SCLI command, see mcTC SCLI User Command.
3.1.1 Software builds

A software build is a collection of programs and files (load modules) operating in a
required system. In the building system of the system software, identity data is defined
for both the software build and the load modules.
A new software build brought into a mcTC can be either a new software delivery or a
software update. A software update can again be either a delivery of a new software
build or a change delivery.
38 Id:0900d80580901f33 DN0989007 DN0989007

Confidential
Software Configuration Management in mcBSC and Software configuration management in mcTC
mcTC
3.1.1.1 Recomended directories to copy software build

The software build can be stored at any directories provided there is sufficient disk
space and user permission.
The suggested directory for storing the software build is:
/mnt/backup/
g The recommended directory to copy the software build is also used for storing the
backup build.
3.1.1.2 Software build directories

The software builds and configuration files are stored at the following subdirectories of
the mcTC:
• Software builds are contained as mountable filesystems at:
/mnt/images/<delivery name>/…
• Configurations files are contained at:
/mnt/config/<delivery name>/<config name>/…
3.1.2 Update deliveries

A software update is a general term referring to a software change deployed in a mcTC
that has already been delivered to a telecommunication operator. The largest possible
software update changes all the components of a software build. The smallest possible
software update changes only one component of the software.
The types of software updates can be the following:
1. New software build deliveries
• release-level upgrades (major updates)
2. Change deliveries
Update deliveries are delivered on removable media, for example, optical discs and
USB mass storage devices can be used for this purpose.
3.1.3 Embedded software

The mcTC Box and Add-in cards include embedded software. When a new mcTC is
taken into use or faulty cards items are replaced with new ones, we recommend that you
make sure the Add-in cards includes the correct versions of the eSW.
For instructions on how to check and upgrade eSW packages, see Upgrading
embedded software
DN0989007 DN0989007 Id:0900d80580901f33 39

Confidential
mcTC
3.2 Software upgrade in mcTC

This section describes the upgrading phases of Multicontroller Transcoder (mcTC)
software (SW). With the procedure documented here, the upgrade is to be done locally
at the mcTC site or remotely through an SSH connection .
A software delivery contains the software items related to mcTC software build ship-
ment. The operator may need to install new software versions due to a fault corrections,
security patches, or enhancement features. The operator checks the software package
version in the mcTC and performs SW package upgrade if needed. The new SW
package is downloaded from either Master BSC or NetAct, and then the mcTC is started
with this new SW. The software upgrade is performed by isolating the mcTC from the
BSC by blocking the O&M link. The mcTC supports easy and fast software upgrades.
Software upgrades have minimal effect on mcTC traffic handling capacity, since each
mcTC module is upgraded separately in the customer network.
The mcTC is a part of BSS and controlled by the BSC. However, the mcTC software
build is delivered separately and it is stored and maintained by the BSC. To avoid unnec-
essary downloads, the master copies of the software and the configuration are stored
locally in mcTC. The mcTC software and configuration data updates are always per-
formed by the user since mcTC could be connected to several BSCs, and it is necessary
to have control of the software level during BSS software release upgrades or changes.
The new mcTC software is activated by system restart.
The mcTC keeps the master copies of the following software and data in its non-volatile
memory (AMC HDD):
• ETP SW
• MCU SW
• TCU SW
• mcTC configuration data for ETP, MCU, TCUs and PTU
Pre-requirement
The mcTC is running with the mcTC software release. It is recommended that all
Change Deliveries (general) are installed (if any).
Summary of upgrade tasks:

The mcTC upgrade consists of the following tasks:
• Backup of the current software build.
For detail procedures, refer Backup and restore in mcTC in Safecopying in BSC,
mcBSC and mcTC document.
• Transfer the new mcTC SW build file to MCU-0 from your local media or PC.
The mcTC software delivery build can be found from NOLS (Nokia Online Services).
The master copy of the mcTC build is stored in NetAct, Master BSC, and locally in
mcTC.
• Upgrading the embedded software (eSW).
Refer section, Upgrading embedded software
• Actual upgrades of the new software build.
Refer section, Upgrading mcTC software using a system restart.
• Backup of the new software package.
For detail procedures, refer Backup and restore in mcTC in Safecopying in BSC,
mcBSC and mcTC document.
40 Id:0900d80580892b8f DN0989007 DN0989007

Confidential
mcTC
3.3 Upgrading embedded software
3.3.1 Overview of mcTC embedded software

The Multicontroller Transcoder (mcTC) is a single controlling unit, Box Controller Node
(BCN). It is a BCN-A plug-in unit type and has different add-in cards. Embedded
software (eSW) is needed to initialized hardware and performs an initial loading of the
system software build during unit startup.
The eSW images are programmed into unit's LMP memory and are managed as plug-
in unit type-specific entities. All the plug-in units should contain eSW that is compatible
with the existing software build when they are delivered. An eSW update is necessary
in the following cases:
• A Change Delivery contains a new eSW for one or more plug-in unit types.
• A new eSW has been instructed to be taken into use during a software build
upgrade.
• A separate, earlier or newly delivered plug-in unit needs eSW updating. For
example, when a faulty plug-in unit has to be replaced with a new one, the new unit's
eSW version in flash memory differs from that of the other plug-in units of the same
type in the network element.
The embedded software (eSW) of these add-in cards and its details are given in Table
4 Embedded software (eSW) details of mcTC add-in cards.
Card type Plug-in unit Functional Unit

Octeon processor add-in BOC-A Management Control Unit (MCU) and
card Exchange Terminal for Packet Trans-
port (ETP)
Digital Signal Processor BDSP-A Transcoder Unit (TCU)
(DSP) add-in card
Synchronization add-in BSAC-A Packet Timing Unit (PTU)
card
Table 4 Embedded software (eSW) details of mcTC add-in cards.
To upgrade eSW of the different add-in cards, execute the following procedure:
• Upgrading embedded software of BCN-A and BOC-A add-in cards.
• Upgrading embedded software of BDSP-A add-in cards.
• Upgrading embedded software of BSAC-A add-in card.
• Setting up LMP for commissioning
g After the completion of the embedded software upgrade of the Add-in cards, execute the
procedure describe in Setting up LMP for commissioning to configure the MCH and
switches configuration files which were lost during upgration.
DN0989007 DN0989007 Id:0900d80580901f35 41

Confidential
mcTC
3.3.2 Retrieving the embedded software version

Purpose
To retrieve and display the installed version of the embedded software
Before you start

• Ensure that you have root access rights.
• The SCLI commands are executed from the BCN LMP prompt.
Steps
1 Retrieving eSW version.

To retrieve the version of the eSW by specifying the node name, enter the following
command:
root@BCNMB-A:~# sw_fw_versioninfo
Example:
The following output is displayed:
LMP Version 2.2.0

PCB Version A103-2/A103-3/A103-4/A103-5/A103-6/A103-7
LED CPLD Version 05
PCI-LPC bridge XP2 Version 03
VCMC Version 2.2.0
PWR1014 Version 0007
FRUD Version 2.2.0
Part Number 110656.0.1
Add-in Card 1
MMC Version 2.2.0
PCPL Version 0.3.0
OCTF Version 2.2.0
FRUD Version 2.2.0
Part Number C111723.A1A
Add-in Card 2
MMC Version 2.3.0
DSP DCPL Version 2.5.0
DSP UCSW Version 2.3.0
DSP PCPL Version 0.6.0
42 Id:0900d80580892b58 DN0989007 DN0989007

Confidential
mcTC
Add-in Card 3
MMC Version 2.3.0
DSP DCPL Version 2.5.0
DSP UCSW Version 2.3.0
DSP PCPL Version 0.6.0
.
.
.
Add-in Card 8
MMC Version 2.2.0
PCPL Version 0.3.0
OCTF Version 2.2.0
FRUD Version 2.2.0
AMC 1
MMC Version 1.b
hdsam-a_ad_mmcf Version 01.0B.0000
hdsam-a_ad_mmcf Version 00.00.0000
hdsam-a_ad_frud Version 01.0B.0000
AMC 2
MMC Version 0.15
bcnsa-a_nk_ucsw Version 01.03.0000
bcnsa-a_nk_fpga Version 01.07.0000bcnsa-a_nk_mmcf Version XX.YY.ZZZZ
bcnsa-a_nk_frud Version 01.01.0000
bcnsa-a_nk_pcpl Version 00.01.0000
PSU info 0
PSU info 1
Board Mfg : EMERSON
Board Product : BCNAP-A
Board Serial : TR103600000
Board Part Number : C111722.A1A
Board Extra : 1d01
Product Manufacturer : EMERSON
Product Name : DS850-3-009
DN0989007 DN0989007 Id:0900d80580892b58 43

Confidential
mcTC
Product Part Number : PSU

Product Version : 02
Product Serial : I561G8000Z02P
root@BCNMB-A:~#
44 Id:0900d80580892b58 DN0989007 DN0989007

Confidential
mcTC
3.3.3 Upgrading embedded software of BCN-A and BOC-A add-in cards

Purpose
To upgrade the embedded software of the BCN-A and BOC-A add-in card of the mcTC.
Steps
1 Set up a laptop to serve as TFTP server.

Set up a laptop or any other workstation to be used for storing the mcTC embedded
software package delivery. The following files are included in the package:
• uImage
• ncp20000.dtb
• ncp20000-initrd-upgrade.gz.uboot
Connect the serial cable to mcTC SER management port and connect the console.
Connect the cables as shown in Figure 5 Cabling between laptop and mcTC.
• The Ethernet cable from the laptop interface to the MGT ethernet port on the front
panel of the mcTC. The copper (RJ-45) cable can be used as an Ethernet transmis-
sion path.
• The serial (RS-232) cable from the serial interface of the laptop serial port 1 to the
console port SER on the front panel of the mcTC.
Commissioning interface to the MGT ethernet port on the front panel of the network.
The terminal settings for the console connection are 115200/n/1.
g It is recommended to use console server instead of laptop serial port.
Figure 5 Cabling between laptop and mcTC
2 Copy the embedded software package delivery to the /tftpboot directory of the
TFTP server.
3 Log on to the BCN-A LMP prompt by rebooting the machine or pressing Reset.
Press ENTER at the U-boot countdown to get the prompt.
DN0989007 DN0989007 Id:0900d8058089915b 45

Confidential
mcTC
4 Set the IP address of the TFTP server.

BCNMB-A# set serverip 10.80.53.35
5 Set the local IP address (same subnetwork of TFTP server).

BCNMB-A# set ipaddr 10.80.53.28
6 Load the embedded software image.

BCNMB-A# set ramdiskfile ncp20000-initrd-upgrade-2.2.0.gz.uboot;
setenv othbootargs ramdisk_size=350000k;
7 Boot the image.

BCNMB-A# run ramboot
Expected outcome
BCNMB-A# run ramboot
Speed: 100, full duplex
Using eTSEC0 device
TFTP from server 10.80.53.35; our IP address is 10.80.53.28
Filename 'ncp20000-initrd-upgrade-2.2.0.gz.uboot'.
Load address: 0x2000000
Loading: ######################################################
##############################################################
##############################################################
###############################################################
.
.
.
.
.
If the upgrade tool fails to start automatically.

At the end of the boot, if the upgrade tool does not start automatically, then log on using
(root/root) and run the upgrade tool manually, see step 8 Run the upgrade tool.
ncp20000 login:root
#password is root
Password:
8 Run the upgrade tool.

root@BCNMB-A:~# /opt/upgrade/upgrade.sh
9 Select full automatic upgrade (option a) from the menu:
Expected outcome
BCN Upgrade Program SW ver 2.2.0
========================================================
46 Id:0900d8058089915b DN0989007 DN0989007

Confidential
mcTC
1. Upgrade MB VCMC
2. Upgrade MB VCMC FRU
3. Upgrade MB LMP Flash Bank 0
4. Upgrade MB LMP Flash Bank 1
5. Upgrade Octeon Add-in Card MMC FRU
6. Upgrade Octeon Add-in Card MMC and Flash Bank 0
7. Upgrade Octeon Add-in Card MMC and Flash Bank 1
8. Upgrade MB XP2 CPLD
9. Upgrade MB LED CPLD
a. Fully automatic upgrade
b. Upgrade MB Chassis Part Number
c. Upgrade MB Board Info Mfg Date/Timed.
d. Upgrade MB Product Info
0. QUIT
===================================================
Notice:- 8.9 CPLD SW upgrade only support after HW A-103
===================================================
Please enter your upgrade item [Enter]:
a
The full automatic upgrade option will upgrade the embedded software of the add-in
card number 1 and 8 only which are the BOC-A add-in cards. To continue upgrading,
Reboot the image after exiting from the menu.
g The upgrade of add-in cards from 2 to 7 fails since they are BDSP-A. To upgrade the
BDSP-A add-in cards from 2 to 7, see Upgrading embedded software of BDSP-A add-
in cards.
10 Reboot the image after exiting from the menu.

root@BCNMB-A:~# reboot
11 End
Further information
To upgrade the BDSP-A add-in card, see Upgrading embedded software of BDSP-A
add-in cards.
To upgrade the BSAC-A add-in card, see Upgrading embedded software of BSAC-A
add-in card.
After the completion of the embedded software upgrade execute the procedure describe
in Setting up LMP for commissioning to configure the MCH and switches configuration
files which were lost during upgration.
DN0989007 DN0989007 Id:0900d8058089915b 47

Confidential
mcTC
3.3.4 Upgrading embedded software of BDSP-A add-in cards

Purpose
To upgrade the embedded software of the BDSP-A add-in card of the mcTC.
Steps
1 Set up a laptop to serve as TFTP server and connect it to the management port of
the mcTC.
Set up a laptop or any other workstation to be used for storing the mcTC embedded
software package delivery. The following files are included in the package:
• bdsp_ep_dtb.img
• fsl_p2020ds-uImage-WR3.0ar_standard
2 Download the embedded software package delivery to the /tftpboot directory of

the TFTP server.
3 Log on to the BCN-A through the LMP port monitor.

telnet LMPIPaddress 300x
Here, x is the number of the slots of the add-in cards to be upgraded (3002 to 3007) for
BDSP-A.
4 Log on to the BCN-A LMP prompt by rebooting the machine or pressing Reset.
Reset the card and press ENTER at U-boot countdown to get the prompt.
5 Set the IP address of the TFTP server.

BCNMB-A# set serverip 10.80.53.35
6 Set the local IP address (same subnetwork of TFTP server).

BCNMB-A# set ipaddr 10.80.53.28
7 Run the netboot.

BCNMB-A# run netboot;
Expected outcome
Using eth0 device
Filename 'bdsp_ep_dtb.img'.
Load address: 0x1a400000
Loading: #
done
Bytes transferred = 9189 (23e5 hex)
48 Id:0900d8058089915a DN0989007 DN0989007

Confidential
mcTC
Using eth0 device

Filename 'fsl_p2020ds-uImage-WR3.0ar_standard'.
Load address: 0x1a000000
Loading: ####################################################
#############################################################
#############################################################
done
.
.
.
8 Execute the following steps to copy the embedded software package:
1 Log on to the BDSP-A console as root/root:

Press 'C' or 'c' to start DSP POST (in 4 seconds)... bypass
DSP POST
Welcome to Wind River Linux
Please press Enter to activate this console.

BDSP-A-135-110-3 login: root
Password:
Linux glibc_small (standard) 4.0
2 To copy the embedded software package files, execute the following steps:
1. root@BDSP-A-135-110-3:~# cd /tmp/
2. root@BDSP-A-135-110-3:/tmp# ifconfig eth0 10.80.53.26
3. root@BDSP-A-135-110-3:/tmp# scp
eswteam@10.80.53.35:/home/eswteam/BCN/BDSP/eSWv2.3/bin/*.t
gz ./
Console Message:
The authenticity of host '10.80.53.35 (10.80.53.35)' can't
be established.
RSA key fingerprint is
33:2a:43:83:50:2b:6f:c0:a4:02:88:b0:35:3f:25:60.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.80.53.35' (RSA) to the list
of known hosts.
eswteam@10.80.53.35's password:
bcdsp-a_ad_dcpl_2_5_0.tgz 100% 56KB 56.0KB/s 00:00
bcdsp-a_ad_pcpl_0_6_0.tgz 100% 3351 3.3KB/s 00:00
bcdsp-a_ad_tool_2_3_0.tgz 100% 692 0.7KB/s 00:00
bcdsp-a_ad_ucsw_2_3_0.tgz 100% 67MB 3.7MB/s 00:18
DN0989007 DN0989007 Id:0900d8058089915a 49

Confidential
mcTC
4. root@BDSP-A-135-110-3:/tmp# ls -lapt
Console Message:
drwxr-xr-x 23 root root 1024 Feb 12 2011 ../
-rw-r--r-- 1 root root 70034588 Jan 1 00:02 bcdsp-a_ad_ucsw_2_3_0.tgz
drwxrwxrwt 2 root root 140 Jan 1 00:02 ./
-rw-r--r-- 1 root root 244379 Jan 1 00:02 bcdsp-a_ad_mmcf_2_3_0.tgz
-rw-r--r-- 1 root root 3351 Jan 1 00:02 bcdsp-a_ad_pcpl_0_6_0.tgz
-rw-r--r-- 1 root root 692 Jan 1 00:02 bcdsp-a_ad_tool_2_3_0.tgz
5. root@BDSP-A-135-110-3:/tmp# tar -zxvf bcdsp-

a_ad_ucsw_2_3_0.tgz
Console Message:
bcdsp-a_ad_ucsw_2_3_0/
bcdsp-a_ad_ucsw_2_3_0/bdsp.bin.md5”bcdsp-a_ad_ucsw_2_3_0/bdsp_ep_dtb.img.md5
bcdsp-a_ad_ucsw_2_3_0/fsl_p2020ds-jffs2
bcdsp-a_ad_ucsw_2_3_0/fsl_p2020ds-uImage-WR3.0ar_standard
bcdsp-a_ad_ucsw_2_3_0/bdsp_ep_dtb.img
bcdsp-a_ad_ucsw_2_3_0/fsl_p2020ds-jffs2.md5
bcdsp-a_ad_ucsw_2_3_0/fsl_p2020ds-uImage-WR3.0ar_standard.md5
bcdsp-a_ad_ucsw_2_3_0/fsl_p2020ds-initrd.gz.uboot.md5
bcdsp-a_ad_ucsw_2_3_0/fsl_p2020ds-initrd.gz.uboot
bcdsp-a_ad_ucsw_2_3_0/bdsp.bin

a_ad_dcpl_2_5_0.tgz
Console Message:
bcdsp-a_ad_dcpl_2_5_0/bcdsp-a_ad_dcpl_2_5_0/NCPB-
3100E_ver0205.jedbcdsp-a_ad_dcpl_2_5_0/NCPB-
3100E_ver0205.vme

a_ad_pcpl_0_6_0.tgz
Console Message:
bcdsp-a_ad_pcpl_0_6_0/
bcdsp-a_ad_pcpl_0_6_0/bcdsp-a_ad_pcpl_0_6_0.jed
bcdsp-a_ad_pcpl_0_6_0/bcdsp-a_ad_pcpl_0_6_0.vme

a_ad_tool_2_3_0.tgz
9. root@BDSP-A-135-110-3:/tmp# mv bcdsp-a_ad_ucsw_2_3_0/* ./
Console Message:
bcdsp-a_ad_tool_2_3_0/
bcdsp-a_ad_tool_2_3_0/fwinfo.inf
50 Id:0900d8058089915a DN0989007 DN0989007

Confidential
mcTC
bcdsp-a_ad_tool_2_3_0/fwinfo.inf.md5
10. root@BDSP-A-135-110-3:/tmp# mv bcdsp-a_ad_ucsw_2_3_0/* ./

11. root@BDSP-A-135-110-3:/tmp# mv bcdsp-a_ad_dcpl_2_5_0/* ./
12. root@BDSP-A-135-110-3:/tmp# mv bcdsp-a_ad_pcpl_0_6_0/* ./
13. root@BDSP-A-135-110-3:/tmp# mv bcdsp-a_ad_tool_2_3_0/* ./
14. root@BDSP-A-135-110-3:/tmp# ls -lapr
Console Message:
-rw-r--r-- 1 1005 1006 45 Feb 15 2011 fwinfo.inf.md5
-rwxr--r-- 1 1005 1006 1260 Feb 12 2011 fwinfo.inf
-rw-r--r-- 1 1001 1001 70 Feb 12 2011 fsl_p2020ds-uImage-
WR3.0ar_standard.md5
WR3.0ar_standard
-rw-r--r-- 1 1001 1001 52 Feb 12 2011 fsl_p2020ds-jffs2.md5
-rwxr--r-- 1 1001 1001 38709828 Feb 12 2011 fsl_p2020ds-jffs2
-rw-r--r-- 1 1001 1001 62 Feb 12 2011 fsl_p2020ds-
initrd.gz.uboot.md5
-rwxr--r-- 1 1001 1001 31343283 Feb 12 2011 fsl_p2020ds-
initrd.gz.uboot
-rw-r--r-- 1 1001 1001 50 Feb 12 2011 bdsp_ep_dtb.img.md5
-rw-r--r-- 1 1001 1001 9189 Feb 12 2011 bdsp_ep_dtb.img
-rw-r--r-- 1 1001 1001 43 Feb 12 2011 bdsp.bin.md5-rwxr--r--
1 1001 1001 1048576 Feb 12 2011 bdsp.bin
-rw-r--r-- 1 root root 70034588 Jan 1 00:02 bcdsp-a_ad_ucsw_2_3_0.tgz
drwxr-xr-x 2 1001 1001 40 Jan 1 00:03 bcdsp-a_ad_ucsw_2_3_0/
-rw-r--r-- 1 root root 692 Jan 1 00:02 bcdsp-a_ad_tool_2_3_0.tgz
rwxr-xr-x 2 1005 1006 40 Jan 1 00:04 bcdsp-a_ad_tool_2_3_0/
-rw-r--r-- 1 1001 1001 13902 Jun 1 2010 bcdsp-a_ad_pcpl_0_6_0.vme
-rw-r--r-- 1 root root 3351 Jan 1 00:02 bcdsp-a_ad_pcpl_0_6_0.tgz
-rw-r--r-- 1 1001 1001 15092 Jun 1 2010 bcdsp-a_ad_pcpl_0_6_0.jed
drwxr-xr-x 2 1001 1001 40 Jan 1 00:04 bcdsp-a_ad_pcpl_0_6_0/
-rw-r--r-- 1 root root 57350 Jan 1 00:02 bcdsp-a_ad_dcpl_2_5_0.tgz
drwxr-xr-x 2 1001 1001 40 Jan 1 00:03 bcdsp-a_ad_dcpl_2_5_0/
-rw-r--r-- 1 1001 1001 86005 Aug 4 2010 NCPB-3100E_ver0205.vme
-rw-r--r-- 1 1001 1001 292849 Aug 4 2010 NCPB-3100E_ver0205.jed
15. root@BDSP-A-135-110-3:/tmp# rm -Rf *.tgz

16. root@BDSP-A-135-110-3:/tmp# rm -Rf *.md5
17. root@BDSP-A-135-110-3:/tmp# ls -lapr
Console Message:
WR3.0ar_standard
-rwxr--r-- 1 1001 1001 31343283 Feb 12 2011 fsl_p2020ds-
DN0989007 DN0989007 Id:0900d8058089915a 51

Confidential
mcTC
initrd.gz.uboot
-rwxr--r-- 1 1001 1001 1048576 Feb 12 2011 bdsp.bin
drwxr-xr-x 2 1001 1001 40 Jan 1 00:03 bcdsp-a_ad_ucsw_2_3_0/
drwxr-xr-x 2 1005 1006 40 Jan 1 00:04 bcdsp-a_ad_tool_2_3_0/
drwxr-xr-x 2 1001 1001 40 Jan 1 00:04 bcdsp-a_ad_pcpl_0_6_0/
drwxr-xr-x 2 1001 1001 40 Jan 1 00:03 bcdsp-a_ad_dcpl_2_5_0/
18. root@BDSP-A-135-110-3:/tmp# rm -Rf bcdsp-a_ad_ucsw_2_3_0/

bcdsp-a_ad_tool_2_3_0/bcdsp-a_ad_pcpl_0_6_0/ bcdsp-
a_ad_dcpl_2_5_0/
19. root@BDSP-A-135-110-3:/tmp# ls -lapt
Console Message:
WR3.0ar_standard
-rwxr--r-- 1 1001 1001 31343283 Feb 12 2011 fsl_p2020ds-
initrd.gz.uboot
-rwxr--r-- 1 1001 1001 1048576 Feb 12 2011 bdsp.bin
9 Run the upgrade tool.

root@BDSP-A-135-110-3:/tmp# /mgmt/upgrade/auto_upgrade.sh
./fwinfo.inf
10 Reboot the card.

root@BDSP-A-135-110-3:~# reboot
11 End
Further information
To upgrade the BSAC-A add-in card, see Upgrading embedded software of BSAC-A
add-in card.
52 Id:0900d8058089915a DN0989007 DN0989007

Confidential
mcTC
After the completion of the embedded software upgrade execute the procedure describe
in Setting up LMP for commissioning to configure the MCH and switches configuration
files which were lost during upgration.
DN0989007 DN0989007 Id:0900d8058089915a 53

Confidential
mcTC
3.3.5 Upgrading embedded software of BSAC-A add-in card

Purpose
To upgrade the embedded software of the mcTC BSAC-A add-in card.
Steps
1 Log on to BCN-A LMP prompt with username and password as root.
2 Set the primary flash bank to active.

root@BCNMB-A:~# ipmitool -t 0x84 -b 7 raw 0x2e 0x1C 0x2a 0x6f 0x00 0x00
Output:
2a 6f 00
3 Reset BSAC-A to boot up from the active flash bank.

root@BCNMB-A:/tftpboot# cd
root@BCNMB-A:~# mch_cli
Console output:
CLI> Deactivate AMC2

Set fru activation policy: clear deactivation lock bit!
deactivate: Command completed normally
CLI> Activate AMC2
Clear locked bit!
done: Command completed normally
Set FRU Activation!
CLI>
4 Copy the following files included in the embedded software upgrade package to
the /dev/shm directory of the BCN LMP.
• bcnsa-a_nk_tool_0_9_0.tgz
• bcnsa-a_nk_ucsw_01_05_0000.tgz
• bcnsa-a_nk_mmcf_01_05_0000.tgz
5 Uncompress the MMC file.

root@BCNMB-A:~# tar -xzvf bcnsa-a_nk_mmcf_01_05_0000.tgz
Archive contents:
bcnsa-a_nk_mmcf_01_05_0000.hpm
bcnsa-a_nk_mmcf_01_05_0000.iif
bcnsa-a_nk_mmcf_composite_01_05_0000.hex
bcnsa-a_nk_mmcf_eeprom_01_05_0000.hex
bcnsa-a_nk_mmcf_flash_01_05_0000.hex
54 Id:0900d8058089915c DN0989007 DN0989007

Confidential
mcTC
6 Upgrade the MMC.

root@BCNMB-A:~# ipmitool -t 0x84 -b 7 hpm upgrade bcnsa-a_nk_mmcf_01_05_0000.hpm
Console output:
PICMG HPM.1 Upgrade Agent 1.0:
Validating firmware image integrity...OK
Performing preparation stage...
Services may be affected during upgrade. Do you wish to
continue? y/n y <enter>
OK
*Target Product ID : 3364
\Target Manufacturer ID: 28458
Performing upgrade stage:
Upgrading BSAC-A MMC BL
with Version: Major: 1
Minor: 5
Aux : 000 000 000 028
Writing firmware: 100 % completed
Upgrading BSAC-A MMC FW
Minor: 5
Aux : 000 000 000 028
Upgrading BSAC-A FRU DATA
Minor: 5
Aux : 000 000 000 028
Firmware upgrade procedure successful
7 Activate hpm.
root@BCNMB-A:~# ipmitool -t 0x84 -b 7 hpm activate
8 Check the shown version.

To check if Firmware Revision and IPMI Version have the latest version, execute
the following command.
root@BCNMB-A:~# ipmitool -t 0x84 -b 7 mc info
Output:
Device ID : 132
Device Revision : 0
DN0989007 DN0989007 Id:0900d8058089915c 55

Confidential
mcTC
Firmware Revision : 1.5

IPMI Version : 1.5
Manufacturer ID : 28458
Manufacturer Name : Unknown (0x6f2a)
Product ID : 3364 (0x0d24)
Device Available : yes
Provides Device SDRs : yes
Additional Device Support :
Sensor Device
FRU Inventory Device
IPMB Event Generator
Aux Firmware Rev Info :
0x00
0x00
0x00
0x1c
9 Log on to BSAC-A.
You can reach the MCU if it is up and running.
ssh ptu-0
Or
If the MCU is down, then log on from LMP BCN.
Before logging to LMP BCN, set the eth0.800 with an IP address within the same sub
network of BSAC-A eth2.800. In case if the BSAC-A cannot be reached due to switch
configuration (for example with the default switch configuration found after an eSW
upgrade of the BCN), load the reference configuration indicated in the commissioning
guide.
ssh 192.168.1.18
or
ssh 192.168.101.19
g The settings depends on FW.
10 Copy the following files.

root@localhost:/dev/shm> scp root@LMPIP:/dev/shm/bcnsa-a_nk_ucsw_01_05_0000.tgz./
root@localhost:/dev/shm> scp root@LMPIP:/dev/shm/bcnsa-a_nk_tool_0_9_0.tgz./
56 Id:0900d8058089915c DN0989007 DN0989007

Confidential
mcTC
11 Uncompress the copied files.

1. root@localhost:/dev/shm> tar -xzvf bcnsa-
a_nk_ucsw_01_05_0000.tgz
Archive contents:
bcnsa-a.dtb
bcnsa-a_nk_fsl_p2020-jffs2
u-boot.bin
uImage
2. root@localhost:/dev/shm> tar -xzvf bcnsa-a_nk_tool_0_9_0.tgz
Archive contents:
bsp_bootenv
upgrade-dtb.sh
upgrade-flash.sh
upgrade-jffs2.sh
upgrade-kernel.sh
upgrade-uboot.sh
12 Delete unnecessary files.

root@localhost:/dev/shm> rm *.tgz
root@localhost:/dev/shm> ls -la
Console output:
total 106448
drwxrwxrwt 2 root root 300 Oct 11 12:30 .
drwxr-xr-x 8 root root 13300 Jan 1 1970 ..
-rwxrwxr-x 1 500 500 8008 Aug 31 02:59 bcnsa-a.dtb
-rw-r--r-- 1 500 500 104857600 Sep 6 05:47 bcnsa-
a_nk_fsl_p2020-jffs2
-rwxr-xr-x 1 500 500 14044 Sep 8 08:04 bsp_bootenv
-rw-r--r-- 1 root root 822774 Oct 11 12:30 syncApp.log
-rwxrwxr-x 1 500 500 524288 Sep 6 01:03 u-boot.bin
-rw-rw-r-- 1 500 500 2595345 Aug 31 03:00 uImage
-rwxrwxr-x 1 500 500 2887 Sep 8 08:04 upgrade-dtb.sh
-rwxrwxr-x 1 500 500 543 Sep 8 08:04 upgrade-flash.sh
-rwxrwxr-x 1 500 500 1740 Sep 8 08:04 upgrade-jffs2.sh
-rwxrwxr-x 1 500 500 3466 Sep 8 08:04 upgrade-kernel.sh
-rwxrwxr-x 1 500 500 2842 Sep 8 08:04 upgrade-uboot.sh
-rw-r--r-- 1 root root 5676 Oct 11 12:30 watchdog.log
-rw-r--r-- 1 root root 14425 Oct 11 12:30 zarlinkApi.log
13 Run the upgrade.

root@BSAC:/dev/shm> ./upgrade-flash.sh<enter>
upgrade dtb file? (y or n) : y
DN0989007 DN0989007 Id:0900d8058089915c 57

Confidential
mcTC
[DTB] Upgrade < 1 Min ...

Size = 8008
[DTB] 0x00000000 Erasing
[DTB] 0x00000000 Flash Writing
upgrade uboot binary? (y or n) : y
[U_BOOT] Upgrade < 1 Min ...
Size = 524288
[U_BOOT] 0x00000000 Erasing
[U_BOOT] 0x00000000 Flash Writing
upgrade Linux kernel? (y or n) : y
[KERNEL] Upgrade < 3 Min ...
Size = 2595345
[KERNEL] 0x00000000 Erasing
[KERNEL] 0x00000000 Flash Writing
upgrade filesystem? (y or n) : y
[JFFS2] Upgrade > 15 Min ...
Size = 104857600
[JFFS2] 0x00000000 Erasing
[JFFS2] 0x00000000 Flash Writing
14 Set the backup flash bank to active.

root@BSAC:/dev/shm> /opt/diagnostic/bcnsa-a_nk_diagsw 602 1
Output:
Case ID: 602
Execution time: Thu Aug 1 00:08:40 2011
IPMI:Primary Boot Flash Selected as the Active Flash Bank (Flash
#1) successfully.
-Please reset the AMC card to active the selection --
15 Before resetting check that the new bank has been correctly selected.
root@BSAC:/dev/shm> /opt/diagnostic/bcnsa-a_nk_diagsw 601
Output:
Case ID: 601
IPMI:The flash boot bank 1
16 Log on to BCN LMP with username and password as root.
58 Id:0900d8058089915c DN0989007 DN0989007

Confidential
mcTC
17 Reset BSAC-A to boot up from the backup flash bank.

Console output:

CLI> Activate AMC2
Clear locked bit!
Set FRU Activation!
CLI>
18 Log on to the BSAC-A.

ssh ptu-0
Or
Log in otherwise from LMP BCN.
Set the eth0.800 with an IP address within the same sub network of BSAC-A eth2.800.
ssh 192.168.1.18 or 192.168.101.19
19 Check whether the BSAC-A esw version is updated correctly.

root@localhost:/root> cat /etc/bcnsa-a_version
Console output:
BSAC-A - Hardware Revision: C112361.A2A (DR3)
BSAC-A - Software Release: 01.05.0000
BSAC-A - FPGA Release: 01.07.0000
BSAC-A - CPLD Release: 00.01.0000
20 Copy the following files.

root@localhost:/dev/shm> scp root@LMPIP:/dev/shm/bcnsa-a_nk_ucsw_01_05_0000.tgz./
root@localhost:/dev/shm> scp root@LMPIP:/dev/shm/bcnsa-a_nk_tool_0_9_0.tgz./
DN0989007 DN0989007 Id:0900d8058089915c 59

Confidential
mcTC
21 Uncompress the copied files.

1. root@localhost:/dev/shm> tar -xzvf bcnsa-
a_nk_ucsw_01_05_0000.tgz
Archive contents:
bcnsa-a.dtb
bcnsa-a_nk_fsl_p2020-jffs2
u-boot.bin
uImage
2. root@localhost:/dev/shm> tar -xzvf bcnsa-a_nk_tool_0_9_0.tgz
Archive contents:
bsp_bootenv
upgrade-dtb.sh
upgrade-flash.sh
upgrade-jffs2.sh
upgrade-kernel.sh
upgrade-uboot.sh
22 Delete unnecessary files.

root@localhost:/dev/shm> rm *.tgz
root@localhost:/dev/shm> ls -la
Console output:
total 106448
drwxrwxrwt 2 root root 300 Oct 11 12:30 .
drwxr-xr-x 8 root root 13300 Jan 1 1970 ..
-rwxrwxr-x 1 500 500 8008 Aug 31 02:59 bcnsa-a.dtb
-rw-r--r-- 1 500 500 104857600 Sep 6 05:47 bcnsa-
a_nk_fsl_p2020-jffs2
-rwxr-xr-x 1 500 500 14044 Sep 8 08:04 bsp_bootenv
-rw-r--r-- 1 root root 822774 Oct 11 12:30 syncApp.log
-rwxrwxr-x 1 500 500 524288 Sep 6 01:03 u-boot.bin
-rw-rw-r-- 1 500 500 2595345 Aug 31 03:00 uImage
-rwxrwxr-x 1 500 500 2887 Sep 8 08:04 upgrade-dtb.sh
-rwxrwxr-x 1 500 500 543 Sep 8 08:04 upgrade-flash.sh
-rwxrwxr-x 1 500 500 1740 Sep 8 08:04 upgrade-jffs2.sh
-rwxrwxr-x 1 500 500 3466 Sep 8 08:04 upgrade-kernel.sh
-rwxrwxr-x 1 500 500 2842 Sep 8 08:04 upgrade-uboot.sh
-rw-r--r-- 1 root root 5676 Oct 11 12:30 watchdog.log
-rw-r--r-- 1 root root 14425 Oct 11 12:30 zarlinkApi.log
23 Run the upgrade.

root@BSAC:/dev/shm> ./upgrade-flash.sh<enter>
upgrade dtb file? (y or n) : y
60 Id:0900d8058089915c DN0989007 DN0989007

Confidential
mcTC
[DTB] Upgrade < 1 Min ...

Size = 8008
[DTB] 0x00000000 Erasing
[DTB] 0x00000000 Flash Writing
upgrade uboot binary? (y or n) : y
[U_BOOT] Upgrade < 1 Min ...
Size = 524288
[U_BOOT] 0x00000000 Erasing
[U_BOOT] 0x00000000 Flash Writing
upgrade Linux kernel? (y or n) : y
[KERNEL] Upgrade < 3 Min ...
Size = 2595345
[KERNEL] 0x00000000 Erasing
[KERNEL] 0x00000000 Flash Writing
upgrade filesystem? (y or n) : y
[JFFS2] Upgrade > 15 Min ...
Size = 104857600
[JFFS2] 0x00000000 Erasing
[JFFS2] 0x00000000 Flash Writing
24 Set the primary flash bank to active.

root@BSAC:/dev/shm> /opt/diagnostic/bcnsa-a_nk_diagsw 602 0
Output:
Case ID: 602
IPMI:Primary Boot Flash Selected as the Active Flash Bank (Flash
#0) successfully.
-Please reset the AMC card to active the selection --
25 Before resetting check that the new bank has been correctly selected.
root@BSAC:/dev/shm> /opt/diagnostic/bcnsa-a_nk_diagsw 601
Output:
Case ID: 601
IPMI:The flash boot bank 0
26 Log on to BCN LMP with username and password as root.
DN0989007 DN0989007 Id:0900d8058089915c 61

Confidential
mcTC
27 Reboot BSAC-A from the primary flash bank.

Console output:

CLI> Activate AMC2
Clear locked bit!
Set FRU Activation!
CLI>
28 Log on to the BSAC-A.

ssh ptu-0
Or
Log in otherwise from LMP BCN.
Set the eth0.800 with an IP address within the same sub network of BSAC-A eth2.800.
ssh 192.168.1.18 or 192.168.101.19
29 Check whether the BSAC-A esw version is updated correctly.

root@localhost:/root> cat /etc/bcnsa-a_version
Console output:
BSAC-A - Hardware Revision: C112361.A2A (DR3)
BSAC-A - Software Release: 01.05.0000
BSAC-A - FPGA Release: 01.07.0000
BSAC-A - CPLD Release: 00.01.0000
End
Further information
After the completion of the embedded software upgrade executes the procedure
describe in Setting up LMP for commissioning to configure the MCH and switches con-
figuration files which were lost during upgration.
62 Id:0900d8058089915c DN0989007 DN0989007

Confidential
mcTC
3.3.6 Setting up LMP for commissioning
3.3.6.1 Configuring the general LMP settings

Purpose
To configure the general settings for the Local Management Processor (LMP).
Steps
1 Login to the LMP.

The LMP can be accessed through the console connection. The LMP boots automati-
cally and provides the following login prompt:
BCNMB-A login:
When, you login to the prompt as root user, you must enter the Wind River Linux shell
with the following prompt:
root@BCNMB-A:~#
g If the login prompt is different, then the embedded software is of older version.
2 Set the console connection for the node.

The terminal server starts in the LMP boot init script stage and the dhcp client is
started on the LMP. The LMP must be connected to the FEWS with the ethernet cable
and the commissioning session must be running on the same interface. If the eth0 inter-
face does not have the IP address from the commissioning subnet, start the dhcp client
manually. Enter the following command:
root@BCNMB-A:~# udhcpc
The LMP now has the address obtained from the commissioning session running on the
FEWS. Hence, the add-in cards (nodes) are accessible from the FEWS.
Example:
If the LMP dhcp client obtains address 192.168.4.9, the first add-in card can be con-
nected using the following command:
telnet 192.168.4.9 3001
g The /etc/ser2net.conf file on the LMP lists the port numbers for the different slots
and can used to configure terminal settings, if the default ones are not suitable.
g If you have trouble with the management interface, force it to100mbit speed with
autonegation off on the FEWS side:
# ifdown [commissioning interface]
# ethtool -s [commissioning interface] speed 100
# ethtool -A [commissioning interface] autoneg off
# ifup [commissioning interface]
These commands must not be run on LMP.
DN0989007 DN0989007 Id:0900d805808edf8f 63

Confidential
mcTC
3 Set the MCH configuration.

The MCH daemon /usr/bin/mch provides the support for IPMI functions. The MCH
configuration file:
• Initializes the CPU cards.
• Loads the /etc/ipmi/mch.conf configuration file
• Starts the RMCP server based on OpenIPMI library
The configuration file mch.conf must be modified to include correct bootup script for
MCU-0 node. Otherwise, the MCU-0 node remains in the U-boot prompt even though it
is rebooted after commissioning.
To view the bootscript number of MCU-0, enter the following command:
root@BCNMB-A:~# grep "[2-8].bootscript" /etc/ipmi/mch.conf
The value must be 03. If the value is not correct, modify this value to 03 and save the file.
root@BCNMB-A:~# vi /etc/ipmi/mch.conf
4 Modify the rack number.

The rack number of the LMP corresponds to cabinet number. The
recommended value for the rack number is 1. However, the rack number is not used cur-
rently.To check the current rack number, enter the following command:
root@BCNMB-A:~# mch_cli GetRackNumber
To modify the rack number to 1, enter the following command:
root@BCNMB-A:~# mch_cli SetRackNumber 1
5 Modify the node number.

The node number of the LMP corresponds to the chassis number. The recommended
value for the node number is 1. To check the current node number, enter the following
command:
root@BCNMB-A:~# mch_cli GetNodeNumber
To modify the node number to 1, enter the following command:
root@BCNMB-A:~# mch_cli SetNodeNumber <chassis-n>
64 Id:0900d805808edf8f DN0989007 DN0989007

Confidential
mcTC
3.3.6.2 Configuring the BCM56820 main switch

Purpose
To configure the BCM56820 main switch automatically using the configuration file. The
configuration file must be copied from ISO image to LMP.
Steps
1 Create the mount point for the iso image.

If the mount point for the ISO image does not exist, create it using the following
command:
mkdir -p <mount point>
For example:
mkdir -p /mnt/fews
2 Mount the iso image to the FEWS file system.

The iso image can be loop mounted to the FEWS’ file system by using the following
standard UNIX/Linux command:
mount –o loop <iso image name> <mount point>
For example:
mount –o loop R_MCTC_1.0.WR.20110523B9.2_WR.iso /mnt/fews
The switch configuration files are available under <mount point>/BCNswitchConf.
In this example, the path is /mnt/fews/BCNswitchConf.
g In order to unmount the iso image after the commissioning is finalized, use the following
command:
unmount
For example:
umount /mnt/fews
3 Copy the configuration file from the ISO image to LMP.

Copy the configuration file from the ISO image to the LMP through SCP and save it as
startup file, enter the following commands:
scp <FEWS username>@<FEWS address>:/mnt/fews\
/BCNswitchConf/BCM56820.scr /mnt/fastpath/init_fp.scr
cp /mnt/fastpath/init_fp.scr /mnt/fastpath/startup-config
The contents of the configuration file is:
!
! Configuration for "main" BCM56820
!
serviceport protocol none
vlan database
vlan 800-802,821-823
vlan name 800 "vlan800"
DN0989007 DN0989007 Id:0900d805808edf4a 65

Confidential
mcTC
vlan name 821 "flip"

vlan name 822 "linx"
vlan name 823 "tcusig"
exit
configure
lineconfig
serial baudrate 115200
exit
interface 0/1
description 'sfp5'
no auto-negotiate
shutdown
exit
interface 0/2
description 'sfp6'
no auto-negotiate
shutdown
exit
interface 0/3
description '56512-HG0'
shutdown
exit
interface 0/4
description '56512-HG1'
shutdown
exit
interface 0/5
description 'addin-8-xaui0'
mtu 9022
vlan pvid 800
vlan participation exclude 1
vlan participation include 800-802,821,823
vlan tagging 801-802,821,823
mode dvlan-tunnel
exit
interface 0/6
mtu 9022
vlan participation include 821
vlan tagging 821
mode dvlan-tunnel
exit
interface 0/7
mtu 9022
vlan pvid 800
vlan participation include 800-802,821-822
vlan tagging 801-802,821-822
mode dvlan-tunnel
66 Id:0900d805808edf4a DN0989007 DN0989007

Confidential
mcTC
exit
interface 0/8
shutdown
exit
interface 0/9
mtu 9022
vlan pvid 800
vlan tagging 801-802,821-822
mode dvlan-tunnel
exit
interface 0/10
shutdown
exit
interface 0/11
mtu 9022
vlan pvid 800
vlan tagging 801-802,821-822
mode dvlan-tunnel
exit
interface 0/12
shutdown
exit
interface 0/13
mtu 9022
vlan pvid 800
vlan tagging 801-802,821-822
mode dvlan-tunnel
exit
interface 0/14
shutdown
exit
interface 0/15
mtu 9022
vlan pvid 800
vlan tagging 801-802,821-822
DN0989007 DN0989007 Id:0900d805808edf4a 67

Confidential
mcTC
mode dvlan-tunnel
exit
interface 0/16
shutdown
exit
interface 0/17
mtu 9022
vlan pvid 800
vlan tagging 801-802,821-822
mode dvlan-tunnel
exit
interface 0/18
shutdown
exit
interface 0/19
mtu 9022
vlan pvid 800
vlan tagging 801-802,822-823
mode dvlan-tunnel
exit
interface 0/20
shutdown
exit
interface 0/21
description 'sfp1'|
no auto-negotiate
shutdown
exit
interface 0/22
description 'sfp2'
no auto-negotiate
shutdown
exit
interface 0/23
description 'sfp3'
no auto-negotiate
shutdown
exit
interface 0/24
description 'sfp4'
no auto-negotiate
shutdown
68 Id:0900d805808edf4a DN0989007 DN0989007

Confidential
mcTC
exit
interface 0/25
description 'mgmt'
mtu 9022
vlan acceptframe vlanonly
vlan ingressfilter
vlan participation include 800
mode dvlan-tunnel
vlan tagging 800
exit
interface 0/27
description 'amc-2'
mtu 9022
vlan pvid 800
vlan participation include 800-802
mode dvlan-tunnel
exit
no isdp run
exit
DN0989007 DN0989007 Id:0900d805808edf4a 69

Confidential
mcTC
3.3.6.3 Configuring the BCM56512 extension switch

Purpose
To configure the BCM56512 extension switch automatically using the configuration file.
The configuration file must be copied from ISO image to LMP.
Steps
1 Create the mount point for the iso image.

If the mount point for the ISO image does not exist, create it using the following
command:
mkdir -p <mount point>
For example:
mkdir -p /mnt/fews
2 Mount the iso image to the FEWS file system.

The iso image can be loop mounted to the FEWS’ file system by using the following
standard UNIX/Linux command:
mount –o loop <iso image name> <mount point>
For example:
mount –o loop R_MCTC_1.0.WR.20110523B9.2_WR.iso /mnt/fews
The switch configuration files are available under <mount point>/BCNswitchConf.
In this example, the path is /mnt/fews/BCNswitchConf.
g In order to unmount the iso image after the commissioning is finalized, use the following
command:
unmount
For example:
umount /mnt/fews
3 Copy the configuration file from ISO image to LMP.

Copy the configuration file from the ISO image to the LMP through SCP and save it as
a startup file, enter the following commands:
scp <FEWS username>@<FEWS address>:/mnt/fews/BCNswitchConf\
/BCM56512.scr /mnt/fastpath2/init_fp.scr
cp /mnt/fastpath2/init_fp.scr /mnt/fastpath2/startup-config
The contents of the configuration file is:
!
! Configuration for “extension” BCM56512
!
configure
line config
serial obdurate 115200
exit
interface 0/1
70 Id:0900d805808edf8b DN0989007 DN0989007

Confidential
mcTC
shutdown
exit
interface 0/2
shutdown
exit
interface 0/3
shutdown
exit
interface 0/4
shutdown
exit
interface 0/5
shutdown
exit
interface 0/6
shutdown
exit
interface 0/7
shutdown
exit
interface 0/8
shutdown
exit
interface 0/9
shutdown
exit
interface 0/10
shutdown
exit
interface 0/11
shutdown
exit
interface 0/12
shutdown
exit
interface 0/13
shutdown
exit
interface 0/14
DN0989007 DN0989007 Id:0900d805808edf8b 71

Confidential
mcTC

shutdown
exit
interface 0/15
shutdown
exit
interface 0/16
shutdown
exit
interface 0/25
shutdown
exit
interface 0/26
shutdown
exit
exit
72 Id:0900d805808edf8b DN0989007 DN0989007

Confidential
mcTC
3.3.6.4 Configuring the BCM56820 switch manually

Purpose
To configure the BCM56820 main switch manually.
Summary
This procedure must be performed only if the automatic configuration described in the
previous section does not work. The BCM56820 main switch can be configured
manually using the LMP’s FASTPATH switch management CLI running in the screen
session. The screen session contains the following windows:
• 0: fp-820 : FASTPATH switch management software CLI for BCM56820
• 1: fp-512 : FASTPATH switch management software CLI for BCM56512
• 2: mch : MCH CLI for controlling the HW in the BCN
To resume the screen session, type screen-r command. Now, you can access the
three windows listed earlier. To access the windows, the following shortcut keys can be
used:
• <Ctrl-G> + <0> - fp-820 CLI window
• <Ctrl-G> + <1> - fp-512 CLI window
• <Ctrl-G> + <2> - MCH CLI
• <Ctrl-G> + <d> - Log out of the screen session and return to the bash shell.
Steps
1 Login to the BCM56820 main switch.

The FASTPATH CLI has a separate authentication. To access the BCN main switch,
login to the fp-820 window as an administrator.
(Broadcom FASTPATH Switching)

User:admin
Password:
The FASTPATH CLI has different access level or modes. The access level defines the
operations that can be performed for that level. The different access levels are as
follows:
(Broadcom FASTPATH Switching) > unprivileged mode
(Broadcom FASTPATH Switching) # privileged mode
(Broadcom FASTPATH Switching) (Config)# configuration mode
(Broadcom FASTPATH Switching) (Interface 0/<if-n>)# interface config mode
The switch configuration must be performed in the configuration and interface configu-
ration modes.
Since you are logged in the unprivileged mode, you must enter the privileged mode to
perform the switch configuration. To enter the privileged mode, enter the following
command:
(Broadcom FASTPATH Switching) >enable
Password:
Then, enter the configuration mode using the following command.
(Broadcom FASTPATH Switching) #configure
The following table lists the internal network port mapping for BCM56820 switch.
DN0989007 DN0989007 Id:0900d805808edf8c 73

Confidential
mcTC
Interface name Port name Connection details

0/19 addin-1-xaui0 Internal network addin 1
connectivity
connectivity
connectivity
connectivity
connectivity
connectivity.
connectivity.
connectivity.
0/21 SFP+1 External network connec-
tivity
tivity
tivity
tivity
tivity
tivity
0/25 BCM53212 Internal network towards
LMP
0/28 AMC1 Connectivity towards
AMC#1
AMC#2
AMC#2
0/3 HG0 Connectivity to extension
switch BCM56512
Table 5 Internal network port mapping for BCM56820 main switch
74 Id:0900d805808edf8c DN0989007 DN0989007

Confidential
mcTC
Interface name Port name Connection details

0/4 HG1 Connectivity to extension
switch BCM56512
Table 5 Internal network port mapping for BCM56820 main switch (Cont.)
2 Configure the xaui0 ports.

The configuration must be first set for needed xaui0 ports. For example, if the chassis is
equipped with two addin cards, interfaces 0/19 and 0/17 must be configured. To con-
figure the interfaces, enter the following commands:
interface 0/<n>
mtu 9022
vlan pvid 800
vlan participation include 800-802
vlan tagging 801-802
mode dvlan-tunnel
no shutdown
exit
To SFP+1 and SFP+6 interfaces, repeat the following configuration for all interfaces:
interface 0/<n>
no auto-negotiate
mtu 9034
shutdown
exit
3 Configure the xaui1 ports.

The xaui1 ports are configured as shutdown by default and they do not need any con-
figuration.
4 Configure the 0/25 interface towards the LMP.

The interface towards the LMP can be configured by entering the following commands:
interface 0/25
mode dvlan-tunnel
mtu 9022
no shutdown
exit
g The interface towards the LMP are configured by default.
5 Enable the AMC interfaces 0/26 to 0/28.

To enable the AMC interfaces, enter the following command:
interface 0/26
no shutdown
DN0989007 DN0989007 Id:0900d805808edf8c 75

Confidential
mcTC
exit
interface 0/27
no shutdown
exit
interface 0/28
no shutdown
exit
6 Disable the port-channel related configuration.

Disable the port-channel related configurations and all the interfaces leading to the
extension switch BCM56512. Enter the following commands:
no port-channel all
interface 0/3
shutdown
exit
interface 0/4
shutdown
exit
Once, the changes are made go back to the privileged mode. Enter the following
command:
Broadcom FASTPATH Switching) (Config)#exit
Write the changes into the flash. Enter the following command:
Broadcom FASTPATH Switching) #write mem
After this you can exit from the screen session using the <Ctrl-G> + <d> key
command.
76 Id:0900d805808edf8c DN0989007 DN0989007

Confidential
mcTC
3.3.6.5 Configuring the BCM56512 switch manually

Purpose
To configure the BCM56512 extension switch manually.
Steps
1 Login to the BCM56512 extension switch.

The FASTPATH CLI has a separate authentication. To access the BCN extension
switch, login to the fp-512 CLI window as an administrator. To enter the configuration
mode, refer to step 1 of Configuring the BCM56280 switch manually section.
2 Disable all port-channel related configurations.

Disable all port-channel related configurations and interfaces leading to the main switch
BCM56820. Enter the following commands:
no port-channel all
interface 0/25
shutdown
exit
interface 0/26
shutdown
exit
3 Disable all the ports from 1 to 16.

To remove all ports from 1 to 16, enter the following command:
interface 0/<n>
shutdown
exit
Once, the changes are made go back to the privileged mode. Enter the following
command:
(Broadcom FASTPATH Switching)(Config)#exit
Write the changes into the flash. Enter the following command:
Broadcom FASTPATH Switching)#write mem
After this you can exit from the screen session using the <Ctrl-G> + <d> key
command.
DN0989007 DN0989007 Id:0900d805808edf8d 77

Confidential
mcTC
3.3.6.6 Resetting the LMP

Purpose
To reset the LMP.
Steps
1 Reset the LMP.

After the required configurations are made to the LMP, the LMP has to be reset for the
changes to become active. To reset the LMP enter the following command:
root@BCNMB-A:~# reboot
g Resetting the LMP will reset all the add-in cards (nodes).
78 Id:0900d805808edf8e DN0989007 DN0989007

Confidential
mcTC
3.3.6.7 Restoring other Flexi Platform (FP) settings

Purpose
To restore other FP settings on LMP that got lost after an eSW upgrade like the ssh
keys, NTP and syslog configurations.
Steps
1 Restore settings.
Log in as root into MCU-0 and give the following command:
/opt/nokiasiemens/bin/configBCNLmp.py
g If required (authentication key mismatch), edit /root/.ssh/known_hosts file and

delete the row containing the entry for LMP-1-1-1.
DN0989007 DN0989007 Id:0900d805808edf48 79

Confidential
mcTC
3.4 Installing and activating mcTC software delivery using a

system restart
Purpose
To upgrade the mcTC system using a system restart.
Summary
The deliveries are installed and activated with the set sw-manage SCLI commands.
g Before upgrading the software, you must backup your data. For more information on
how to backup or restore mcTC software build, refer to the Backup and restore in mcTC
section.
Steps
1 Make a backup copy of the installed delivery.

For more information, see instructions in Making a full software backup in Safecopying
in BSC/mcBSC and mcTC document.
2 Copy the software delivery.

Copy the software delivery to the recommended subdirectory.
/mnt/backup
3 Delete the existing build from the directory, if needed.

For deleting the build you must use the delete sw-manage SCLI command.
The syntax of the command is as follows:
delete sw-manage {[logfile <logfile name>]? [noexec]? [arch]?} delivery [<delivery
label>]
You can use the following options:
Parameter Description
logfile <logfile The logfile option will write the logs in the specified file. By
name> default, the logs are located in /var/log/swm.log.
noexec The noexec option will print the important steps that are
executed during the installation of a software patch delivery.
arch The architecture name
<delivery label> The <delivery label> is the name of the software delivery
to be deleted.
Table 6 Parameters for deleting software deliveries
80 Id:0900d80580892b5a DN0989007 DN0989007

Confidential
mcTC
4 Install the delivery.

Install the delivery with the set sw-manage install SCLI commands. While install-
ing the multiple deliveries, you can list the names of the delivery packages as an argu-
ment.
set sw-manage [logfile <logfile name>] [norollback] [noexec] install delivery
<delivery name>
norollback The norollback option will omit clean up in case of failure
of the command. This will be useful for debugging purposes.
executed during the installation of a software delivery.
<delivery name> The <delivery name> is the full path to the software
delivery of an iso image.
Table 7 Parameters for installing deliveries
5 Activate the installed delivery.

set sw-manage [logfile <logfile name>] [norollback] [noexec] activate delivery-
label <delivery label> [mode <online | restart>] all
For upgrading a system using the system restart, use the restart mode option.
logfile <logfile name> The logfile option will write the logs in the speci-
fied file. By default, the logs are located in
/var/log/swm.log.
delivery label The <delivery label> is the name of the
software delivery to be activated.
mode <online | restart> The mode <online | restart> option can be
used to force the node to be restarted before the
installation is activated. By default, the activation is
performed in the restart mode.
Table 8 Parameters for activating deliveries
DN0989007 DN0989007 Id:0900d80580892b5a 81

Confidential
mcTC
Example: Installing several deliveries at the same time

To install the three deliveries (RR_MCTC_1.0.WR.20110725B9.5.0_WR.iso that is
located in the /home/SWM directory) and to activate the latest one in the node, enter the
following commands:
set sw-manage install delivery /home/SWM/R_MCTC_1.0.WR.20110725B9.5.0_WR.iso
set sw-manage activate delivery-label R_MCTC_1.0.WR.20110725B9.5.0_WR mode restart

all
6 List the currently active software delivery.

For listing the software delivery build you must use the set show sw-manage SCLI
command.
show sw-manage current all
7 List the installed deliveries.

For listing the installed deliveries build you must use the set show sw-manage SCLI
command.
show sw-manage list
End
82 Id:0900d80580892b5a DN0989007 DN0989007

Confidential
mcTC
3.5 Installing mcTC correction or patch delivery

Purpose
To install correction or patch delivery to the mcTC system. Upgrading of mcTC with new
software involves one or more mcTC functional units MCU, ETP, or DSP.
Summary
The delivery are installed and activated with the mctccli patch SCLI command. Only
ETP, MCU and DSP software can be upgraded with the patch command.
The involved ETP Add-in card, TCU Add-in cards, and MCU software application are
restarted if involved in the correction delivery.
The software version of MCU, ETP and DSP load correction is check with the mctccli
getmctcswver command.
g Before installing the patch, you must backup your data. For more information on how to
backup or restore mcTC software build, refer to the Backup and restore in mcTC section.
Steps
1 Copy the patch delivery.

Copy the patch delivery to the recommended subdirectory of MCU.
/mnt/backup
2 Install the patch delivery.

Install the patch delivery with the mctccli patch SCLI command.
mctccli patch folder <directory where the correction is located> file <name of
the correction file>
folder The full path to the software patch delivery.
file The name of the patch delivery
Table 9 Parameters for installing patch delivery
Example:
To install the correction delivery (S15_MCTC_9_4_0_CORR2) that is located in
/mnt/backup folder, enter the following command at the prompt:
patch folder /mnt/backup file S15_MCTC_9_4_0_CORR2
3 Check the installed software version.

To check the correction delivery has been correctly installed, use the mctccli
getmctcswver SCLI command.
DN0989007 DN0989007 Id:0900d805808a0502 83

Confidential
mcTC
mctccli getmctcswver
Example:
MCTCMCU 9.4.0
METCKRNA.elf 1.27-1
METCMGTA.elf 1.37.1
METCUPCA.elf 1.37.1
mctdsp.out 1.2
MCTCMCU represents the software running on MCU, the METCKRNA.elf,
METCMGTA.elf, and METCUPCA.elf are the images running on mcETPC and
mctdsp.out is the image running on DSP.
End
84 Id:0900d805808a0502 DN0989007 DN0989007

Confidential
mcTC
3.6 Downgrading mcTC software using system restart

Purpose
To downgrade a software delivery and activate the old delivery in the mcTC.
Summary
Use the following instructions to revert to a previous delivery build.
Steps
1 Downgrade the software delivery installation.

For downgrading you must use the set sw-manage activate command.
The command is the same as that used for upgrading software delivery, only the delivery
label is of the older delivery.
set sw-manage [logfile <logfile name>] [norollback] [noexec] activate delivery-
label <delivery label> [mode <online | restart>] all
You can also use the following options:
norollback The norollback option will omit clean up in case of failure
of the command. This will be useful for debugging purposes.
to be activated.
mode <online | The mode <online | restart> option can be used to
restart> force the node to be restarted before the installation is acti-
vated. By default, the activation is performed in the restart
mode.
Table 10 Parameters for downgrading to older software deliveries
Example: Activating an older delivery

To activate an older delivery, (R_MCTC_1.0.WR.20110420B9.0_WR.iso located in
the /home/SWM directory), enter the following command:
set sw-manage activate delivery-label R_MCTC_1.0.WR.20110420B9.0_WR mode restart
all
DN0989007 DN0989007 Id:0900d80580892b5b 85

Confidential
mcTC
3.7 Deleting old mcTC SW builds

Purpose
You can delete old SW builds from a directory with the delete sw-manage SCLI
command. The SW build to be deleted must not be active. You can delete the SW build
by specifying the delivery label.
Steps
1 Delete the SW build.

Delete the delivery with the delete sw-manage SCLI commands.
delete sw-manage [logfile <logfile name>] [noexec] delivery <delivery label>
to be deleted.
Table 11 Parameters for deleting old software deliveries
End
86 Id:0900d805808a0503 DN0989007 DN0989007

Confidential

Software Configuration Management in MCBSC

Uploaded by

Copyright:

Available Formats

You might also like

Software Configuration Management in MCBSC

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Configuration Management in MCBSC

Uploaded by

Copyright:

Available Formats

GSM/EDGE BSS, Rel.

Software Configuration Management in

f Important Notice on Product Safety

The same text in German:

f Wichtiger Hinweis zur Produktsicherheit

2 Id:0900d805809a705b DN0989007 DN0989007

2 Software Configuration Management . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Software configuration management in mcTC. . . . . . . . . . . . . . . . . . . . 38

DN0989007 DN0989007 Id:0900d805809a705b 3

3.3.6.5 Configuring the BCM56512 switch manually . . . . . . . . . . . . . . . . . . . . . 77

4 Id:0900d805809a705b DN0989007 DN0989007

DN0989007 DN0989007 Id:0900d805809a705b 5

6 Id:0900d805809a705b DN0989007 DN0989007

DN0989007 DN0989007 Id:0900d805809186ac 7

8 Id:0900d805809186ac DN0989007 DN0989007

DN0989007 DN0989007 Id:0900d80580896dae 9

2 Software Configuration Management

2.1 Software configuration management

g Installing a software update requires extensive knowledge and long-term experience of

2.1.1 Software configuration information

g Not all network elements have all of the following functionalities.

The system includes a software configuration management system which consists of

10 Id:0900d8058098f336 DN0989007 DN0989007

• by restarting the relevant units or

MML programs for software configuration management

MML programs closely related to software configuration management

2.1.2 Software builds

DN0989007 DN0989007 Id:0900d8058098f336 11

g After returning to a fallback copy, the SW build has the FB status.

2.1.2.1 Software build subdirectories

12 Id:0900d8058098f336 DN0989007 DN0989007

- SOMAFI (SW Config. Management file)

SCMANA TMPDIR BLCODE MMDIRE LFILES CONVPR ASWDIR CDTEMP WEBFIL

CGI SCRIPT APPS HTDOCS ICONS GRAPHICS

DN0989007 DN0989007 Id:0900d8058098f336 13

Table 1 Subdirectories of WEBFIL

2.1.2.2 Status of a SW build

14 Id:0900d8058098f336 DN0989007 DN0989007

DN0989007 DN0989007 Id:0900d8058098f336 15

Changing the status of a SW build

(Note: the WKS command creates a new SW build,

Rollback statuses (WSR)

Fallback copy (WKS) Change of status (WSC)

Rollback statuses (WSR)

Figure 2 Statuses of a created SW build

Commands related to the states of SW builds

16 Id:0900d8058098f336 DN0989007 DN0989007

Status of a SW build during a software update

Situation Command Directory Active Traffic Trial

Figure 3 The effects of a new SW build deployment on other SW builds

• Deployment of a change delivery

DN0989007 DN0989007 Id:0900d8058098f336 17

Situation Command Directory Active Running

Figure 4 The effects of a change delivery deployment on other SW builds of the

2.1.2.3 Disk file versions

18 Id:0900d8058098f336 DN0989007 DN0989007

2.1.3 Update deliveries