ARO I AAAE I
`
`US 20030093688A1
`
`as United States
`a2) Patent Application Publication co) Pub. No.: US 2003/0093688 Al
`
` Helgesen et al. (43) Pub. Date: May15, 2003
`
`
`(54) METHOD FOR AUTOMATION OF
`SOFTWARE UPGRADE
`
`(52) US. Cd. ce eccecccssessnescsssessueccenenssasecsuneceneressnerennes 713/200
`
`(76)
`
`Inventors: Jan Ingvard Helgesen, Oslo (NO);
`Stefano Angelo Donati, Oslo (NO)
`
`Correspondence Address:
`NIXON & VANDERHYE, PC
`1100 N GLEBE ROAD
`8TH FLOOR
`ARLINGTON, VA 22201-4714 (US)
`
`(21) Appl. No.:
`
`10/312,392
`
`(22) PCT Filed:
`
`Jun. 21, 2001
`
`PCT/SEOL/O1417
`(86) PCI'No.:
`+
`att
`eae
`:
`(30)
`Foreign Application Priority Data
`Jun. 21, 2001
`(NO) sescnnsnenneneneneatanne 20003375
`oS
`Publication Classification
`
`(SL) UM, CI? accessesesccsssnseeecssessneeseessane HO4L 9/00
`
`Upgrade Process
`
`G3)
`
`(57)
`
`ABSTRACT
`
`The present invention relates to a method for automation of
`software upgrade of network elements in data and commu-
`nication networks. In a preferred embodimentof the present
`invention, an upgrade of network elements in a communi-
`cation system is controlled from one certain workstation.
`Before the actual activation of the new software of the
`network elements takes place, the hardware configuration
`(5) is validated ensuring that the new software is loadable in
`the hardware. The software configuration is then also vali-
`dated ensuring that
`the new software and the existing
`software are compatible. A health check is then executed
`investigating whether the status of the network elements is
`as required. Then, the certain workstation from which the
`upgrade is controlled is assigned exclusive network admin-
`istration access to the network elements. Assuming that the
`above mentionedis carried through successfully, the actual
`activation of the new software is executed. Thereafter, the
`exclusive access which was assigned to the workstation is
`released, and before cleaning up and tcrminating, post
`validation and post health checks are executed.
`
`Google Exhibit 1031
`Google v. VirtaMove
`
`Google Exhibit 1031
`Google v. VirtaMove
`
`

`

`Patent Application Publication May 15, 2003 Sheet 1 of 2
`
`US 2003/0093688 Al
`
`Figure 1 Remote Upgrade Station
`
`Remote Upgrade Station
`
`
`
`
` : Presentation
`“Upgrade Logic
`
`
`| Elemént Access
`
`
`
`
`Figure 2 Network Element
`
`Network Element
`
`
`Network Element
`
`Network Element
`
`
`

`

`Patent Application Publication May 15, 2003 Sheet 2 of 2
`
`US 2003/0093688 Al
`
`Figure 3 Upgrade Process
`
`(3)
`
`
` .
`
`PreValidate HW/SW
`Configuration of NE
`
`OK
`
`
`
`Post Validate SW
`Configuration on NE
`
`OK
`
`;
`
`Post Health Check
`.of NE
`.
`
`
`
`
`
`

`

`US 2003/0093688 A1
`
`May15, 2003
`
`METHOD FOR AUTOMATION OF SOFTWARE
`UPGRADE
`
`FIELD OF THE INVENTION
`
`invention relates to a method for
`[0001] The present
`automatic software upgrade of network elements, in particu-
`lar for use in data and telecommunication network.
`
`BACKGROUND OF THE INVENTION
`
`[0002] A data or telecommunications network consists of
`a number of nctwork clements interconnected by physical
`connections. Network elements implement routing, switch-
`ing and transport functions that are required to establish
`communication between two or more network end-points.
`
`In addition, network elements may implement
`[0003]
`application functions like multimedia telephony or unified
`messaging, which provide additional value for the end-user
`beyond basic end-to-end connectivity. In traditional tele-
`communication networks, the number of different types of
`network elements has been quite small, because network
`functions spanning from transport to the application layer
`have been integrated in a single element.
`
`[0004] However, following the convergence of data and
`telecommunication technologies,
`the number of different
`network element types is increasing. Ericsson and other
`vendors are dividing, the next generation network into con-
`nectivity, control and application layers, with a large number
`of specialized network element types at each layer. The next
`generation network enables the operator to decrease time-
`to-market for new services, and differentiate current service
`offerings more effectively.
`
`[0005] Networktraffic is increasing rapidly in access and
`carrier networks world-wide, which implies that the number
`of network elements is growing fast in order to handle the
`increased network load. This and the fact
`that network
`elements are becoming morespecialized require more effec-
`tive operation and maintenance of the network.
`
`In large operator networks with thousands of net-
`[0006]
`work elements, software upgrade is both a time-consuming
`and complex process. The complexity of the upgrade pro-
`cess makes it difficult to roll out software on several ele-
`
`ments in parallel, because the operator needs to manually
`supervise every step of the process.
`
`[0007] The software upgrade process is also often com-
`plicated by dependencies between software modules. There
`may be dependencies on the version of other software
`modules that need to be resolved before upgrade can com-
`mence. There are also runtime dependencies between soft-
`ware modules, which implies that a software module may
`not be upgraded while another is running. In addition, the
`upgrade process is complicated by dependencies between
`software modules and the underlying hardware that executes
`the software.
`
`[0008] Exceptional situations may also frequently occur
`during the upgrade process, which require special attention
`or even rollback of some orall steps performed up to that
`point.
`
`[0009] As described above, next generation networks will
`include a large number of network elements based on
`different hardware platforms. This further complicates the
`
`software upgrade process, since it requires experience on
`several different hardware platforms. In the current situation,
`experience is required only on a small numberofdifferent
`platforms, e.g.
`the AXE platform for Ericsson’s network
`elements. However, this is about to change and for next
`generation, Ericsson is introducing Cello, TelORB, Ronja,
`Erlang OTP and Tigris platforms. The situation is also
`similar for other vendors.
`
`[0010] Another problem of today’s upgrading methodsis
`that education operation and maintenancestaff on every new
`platform is expensive. In addition, software upgrading is in
`great extent performed manually at the network elementsite
`or remotely from an operation and maintenance center. The
`problem with the manual approach is that experienced
`operators are required to control
`the process, and such
`individuals are often a scarce resource that should not be
`
`used for routine like operations. In addition, humans cannot
`control more than a few upgrades in parallel, whereas
`computer programs can control a large amountin parallel.
`
`{0011] There are IT applications which produce software
`packages used to install software components on general-
`purpose computers, e.g. InstallShield® from InstallShield
`Software Corporation Inc. These applications produce soft-
`ware packages that contain scripts to interact with the user
`and copy the software into the system. It is also commonto
`include scripts to remove software from the system. Since a
`network clement is no more than a special-purpose com-
`puter, these IT applications should be regarded as known
`solutions.
`
`{0012] Current script based solutions can be used to install
`software on a single network element, but there are no
`knownsolutions for automating the entire upgrade process.
`The latter is required to upgrade software on several network
`elements in parallel. The problem is that any number of
`exceptional situations may arise during the upgrade process.
`
`[0013] European Patent Application EP 0 945 792 A2,
`held by Sun Microsystems Inc., describes a technique for
`implementing a framework for extensible applications.
`Using the framework, a software module which installs
`itself within an application can be developed.In this context,
`one may regard a network elementas an “application”, thus
`the patent could be used for software upgrade of network
`elements.
`
`[0014] However, no known network elements are based on
`the framework proposed here, and for this reason,this patent
`proposes no solution to the software upgrade problem of
`existing network elements. Also, it is not likely that future
`network elements will implement this framework.
`
`International Patent Application PCT/SE92/00411,
`{0015]
`held by ICL Data AB, describes a “method and system for
`revising data in a distributed data communication system”.
`The following procedure is described in the patent to per-
`form an installation or upgrade of data. In this context,
`software may be regarded as data.
`
`[0016]
`
`1. Establish a list of destination devices
`
`2. Establish a procedure for the revision of
`[0017]
`data on selected destination devices, and store this as
`a revision recipe.
`
`3. Create a data package with the data to be
`[0018]
`revised and the revision recipe.
`
`

`

`US 2003/0093688 A1
`
`May15, 2003
`
`4. The data packageis distributed to selected
`[0019]
`destination devices.
`
`order to make sure that the required conditionsto initiate the
`activation is met, and to make sure that the activation has
`indeed been successful.
`
`5. The selected destination devices interpret
`[0020]
`the information in the data package by meansof a
`special interpreter program installed in each device.
`
`[0021] The above patent concerns only installation or
`upgrade of workstations in a distributed data communication
`system. There are different non-functional requirements for
`upgrade of workstations and network elements. For instance,
`downtime may be accepted for workstations, while this is
`unacceptable for network clements, 1.c. the upgrade must be
`performed while traffic is running.
`
`[0022] The object of the present invention is to provide a
`method eliminating the drawbacks described above.
`
`[0023] More specifically, a main object of the present
`invention is to simplify the complex and time-consuming
`upgrade process in a data or telecommunication network
`including a large number of network elements byintroduc-
`ing automatic software upgrade of the elements.
`
`[0024] Another object of the invention is that it provides
`the required fault tolerance during the upgrade process to
`ensure that special attention or even rollback of someorall
`steps performed up to a certain point takes place. This is
`achieved by dividing the process in a number of sleps, where
`each step must complete successfully before proceeding
`with the next.
`
`[0025] A further object of the invention is that it mini-
`mizes the need for expensive, manual intervention by expert
`operators.
`
`[0026] The present invention also overcomes the draw-
`backs of the mentioned international Patent Application
`PCT/SE92/00411, e.g. the scope of the present invention is
`upgrade of network elements that carry the traffic in the
`communication system, and no downtime for the elements
`while upgrading is required.
`
`SUMMARYOF THE INVENTION
`
`[0027] The above objects are achieved by a method char-
`acterized in the features defined by the characterizing part of
`claim 1.
`
`invention relates to a
`the present
`In particular,
`[0028]
`method for automatic software upgrade of network ele-
`ments, for use in data and telecommunication network. It
`describes a recipe that makes is possible to automate the
`upgrade process, ic.
`run the software upgrade without
`operator intervention. The recipe is required to include the
`following steps:
`
`[0029]
`
`health checks of the upgrade target,
`
`[0030]
`ration,
`
`validation of the hardware/software configu-
`
`[0031]
`
`backup,
`
`[0032]
`
`data conversion,
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`In order that the invention may be morereadily
`[0036]
`understood, the method will in the following be described
`with reference to the accompanying drawings.
`
`FIG.1 illustrates a sample upgrade station and the
`[0037]
`communication towards network elements,
`
`[0038]
`element,
`
`FIG.2 illustrates major components in a network
`
`[0039] FIG. 3 is a float diagram illustrating the steps
`involved in the upgrade process.
`
`DESCRIPTION OF PREFERRED EMBODIMENT
`
`[0040] With reference to the abovementioned figures, in
`the following, an example of howa method according to the
`present invention may be implemented will be described.
`
`[0041] Soliware Package
`
`It is assumed that the vendor distributes software
`[0042]
`upgrades to network operators by means of software pack-
`ages, which contain everything required to perform the
`upgrade. This includes at least the following components:
`
`1. The software that should be upgraded. The
`[0043]
`software on the network element may consist of
`several load modules which are upgraded indepen-
`dently. In this case, the package may include only the
`modules that are to be upgraded.
`
`2. Software configuration. A description of the
`[0044]
`software modules included in this package andtheir
`dependencies on other software modulesinstalled on
`the network elementor includedin this package. The
`configuration also includes a description of the hard-
`ware required to install this software. The recipe
`presented below uses this configuration.
`
`3. One or more recipes used to execute each
`[0045]
`step of the upgrade process (3). These have to be
`tailored to support upgradeof the particular software
`delivered with this package. One allermative is to
`implementthe recipe using one script per step of the
`upgrade process (3), where each script includes the
`commandsrequired to execute a step. For instance,
`a script may start by setting up a Telnet session
`towards the network element, issuing an appropriate
`sequence of commands, and analyzing the output.
`
`4. Reference documentation for the newsoft-
`[0046]
`ware. The upgrade process (3) is automated bythis
`invention, hence no documentation is required for
`this purpose, but troubleshooting information may be
`necessary. It is also commonto includetranscripts of
`the verification test performed by the vendor.
`
`[0047] Remote Upgrade Station (1)
`
`activation, and
`[0033]
`In most cases, it is preferred to initiate software
`[0048]
`upgrades from a remote upgrade station (1) to avoidavisit
`[0034]
`cleanup.
`to the network element site, and in order to run several
`upgrade sessions in parallel. FIG. 1
`illustrates a sample
`upgrade station and the communication towards network
`
`[0035] These steps are partly executed prior to and after
`activation of the software on the upgrade target. This in
`
`

`

`US 2003/0093688 A1
`
`May15, 2003
`
`elements. This communication may be carried together with
`the voice/data traffic or over a separate management net-
`work.
`
`[0049] The figure also indicates the components which
`would typically be used to implementthe upgradestation.
`This includes presentation,
`logic used to execute the
`upgrade, and element access. Presentation and element
`access is outside the scope of this invention, but included
`here for completeness. Element access is responsible for
`communication towards the network element’s management
`interface. SNMP, CORBAorTelnet protocols are commonly
`used for this purpose.
`
`[0050] The upgradelogic is requiredto initiate and control
`the software upgrade process(3) defined later. The upgrade
`logic will read the recipe and follow the steps defined
`therein.
`In order to make the upgrade process (3) run
`automatically,
`these steps should conform to the ones
`defined in this invention. The upgrade logic may be regarded
`as an interpreter program that performs the upgrade based on
`information contained in the recipe. This invention defines
`contents of the recipe that
`is required to automate the
`upgrade.
`
`[0051] Network Element(2)
`
`[0052] FIG. 2 illustrates major components in a network
`element(2), but these may vary depending onthe role of the
`network clement (2). What is important with regards to this
`invention, is that the network element (2) must implement
`some sort of managementinterface, which may berealized
`using available standards (e.g. SNMP, CORBA, FIP and
`Telnet) or vendor specific protocols.
`
`[0053] Commands are invoked on the managementinter-
`face to perform the software upgrade from a remote location,
`e.g. there may be a set of commands for downloading the
`sofiware to the network element (2) and another set for
`activating the software.
`
`[0054] Naturally, the granularity of the managementinter-
`face may vary from one network element(2) to another, and
`the trend is towards more high-level support implemented in
`the network element (2). This meansthat different network
`elements provide different levels of support for software
`upgrades, which again affects the level of control that the
`remote upgrade station (1) needs to enforce on the upgrade
`process (3). For older network elements, the station may
`need to issue a number of low-level commands for every
`step in the process (3), while newer elements may support a
`single high-level commandfor each step.
`
`[0055] Upgrade Process (3)
`
`[0056] The present invention assumesthat software pack-
`ages should include a recipe to automate the upgrade process
`(3). This recipe is embeddedin a software upgrade package
`distributed to customers. The recipe should be considered as
`the foundation for building tools to automate the upgrade
`process (3), and the customer need not be concerned about
`the nature of the recipe.
`
`[0057] The present invention specifies a numberof steps
`that need to be covered in order to perform a successful
`upgrade of a network clement (2), and everystep necds to
`be covered by the recipe embeddedin the software package.
`The steps involved in the upgrade process(3) are illustrated
`in FIG,3.
`
`[0058] The recipe is assumed to handle exceptional situ-
`ations during every step of the upgrade process (3), but of
`course, it is practically impossible to cover every possible
`situation. In this case, a step will exit with a NOKresult code
`as indicated in the figure, which aborts the upgrade process
`(3) and initiates rollback and cleanup activities if required.
`The latter depends on how far the upgrade has progressed
`before a critical incident occurs that the script cannot catch.
`
`[0059] The steps required to automate the software
`upgrade process (3) are further described below. However,
`detailed execution of each step is outside the scope of this
`invention, since it
`largely depends on the management
`interface towards the network element (2).
`
`[0060] Download Software to Network Element (4):
`
`‘The download (4) of software to the network
`[0061]
`element does not necessarily need to be covered by the
`recipe to automate the upgrade, but the step is included here
`for completeness. The remote upgrade tool is responsible for
`implementing this step, mostlikely by using an availablefile
`transfer mechanism like I’TP, NI'S, or the like. Thestep itself
`includes transferring the software that are to be upgraded
`from the file server connected to the remote upgrade station
`(1) to the file system of the network element (2).
`
`[0062] Software packages are likely to be distributed in
`ZIP or TAR format. The download step (4) needsto inflate
`the package in some designated directory on the remote
`upgrade station (1), and to initiate transfer of the software
`files to the network element(2).
`
`[0063] By default, a delta of the software should be
`transferred to the node to optimize the bandwidth usage.
`Delta transfer means that componentsalready existing in the
`node file system are not
`transferred. As an option,
`the
`operator may chooseto transfer the complete set of software
`to the node. All components will then be transferred, even if
`they already exist in the nodefile system.
`
`Pre Validate Hardware Configuration of Network
`[0064]
`Element(5):
`
`[0065] There may be dependencies between the software
`modules to install and the hardware configuration of the
`network element (2) to upgrade. E.g.
`the software may
`require that a special I/O processoris installed or a higher
`stepping of the main processor.
`
`be
`should
`dependencies
`[0066] Software/hardware
`checked prior to initiating any further upgrade activities,
`since they will ultimately force the upgrade to backtrack. A
`step of the recipe is designed to check these software/
`hardware dependenciesfor the software modules included in
`the package distributed.
`
`the new
`[0067] The check is performed to assure that
`software is loadable in the current hardware configuration.
`The software configuration states the HW compatibility
`window for the delivered software. The compatibility win-
`dow will be compared with the installed HW revision.
`
`[0068] The check function will return OK/NOKstatus. If
`the check fails,
`the recipe will not continuc unless the
`operator overrides the result. The operator is warned by the
`system that overruling of the negative result may lead to
`traffic disturbances.
`
`

`

`US 2003/0093688 A1
`
`May15, 2003
`
`Pre Validate Software Configuration of Network
`[0069]
`Element(5):
`
`(2) during the upgrade. Forinstance, all statistics collection
`should be turned off during the upgrade.
`
`[0070] The step of the recipe is performed to assure that
`that the software in the package and the current executing
`software in the network element(2) are compatible,i.e. it is
`possible to perform a data conversion. This is done by
`comparing the software revision compatible window given
`by the configuration with the software revision of the
`running system.
`
`Inthe situations where not all software modules on
`[0071]
`the network clement (2) are upgraded,it is csscntial to check
`that the revision of the modules that are left untouched will
`work together with the upgraded modules. This is referred to
`as software-software dependencies.
`
`[0072] The check function will retum OK/NOKstatus. If
`the check fails,
`the recipe will not continue unless the
`operator overrides the result. The operator is warned by the
`system that overruling of the negative result may lead to
`traffic disturbances.
`
`[0073]
`
`Pre Health Checks of Network Element(6):
`
`[0074] This part is very specific for each network element
`(2) type, but generally includes checking the current status
`of the network element (2), and possibly taking the appro-
`priate countermeasuresto ensure that status is as required for
`the upgrade to progress.
`
`[0075] The health check step normally includes checking
`the alarms pending for this network element (2) and any
`records logged in the syslog. It is also commonto check the
`current load of the network element (2) to seeif it is feasible
`to progress. At this point, the upgrade process (3) has not
`affected the network element (2), and consequently there is
`no need for rollback if the step returns a NOK exit status.
`
`[0076] Backup Existing Software on Network Element
`(7):
`
`[0077] This step includes backup of the software that is to
`be upgraded. A backup may be performed by saving the HW
`and SW configuration settings, or by dumping the entire
`memory. Naturally,
`the latter option consumes far more
`space in the network element(2)file system.
`
`[0078] The existing software may either be stored on the
`network element (2) file system, or the remote upgrade
`station’s (1) file server. Storing the backup on the remote
`upgrade station (1) provides additional safety against data
`loss during the upgrade, since the network element (2) may
`become unavailable. However, remote storage also comesat
`a cost, since the transferring of the backup over a remote
`connection will consume bandwidth and maytake hours to
`complete over a slow connection.
`
`[0079] The normal procedure to handle failures during the
`upgrade procedure is that a return to the backup is made by
`the network element(2), by reloading the backup. There can
`be occasions whenit is desirable not to return to the backup
`and instead make a forced reload with the new software.
`
`[0080] Obtain Exclusive Access to Network Element:
`
`[0081] This stcp includes actions required to obtain cxclu-
`sive network managementaccess to the network element (2)
`that
`is target for the upgrade. Only the remote upgrade
`station (1) should be allowed to manage the network clement
`
`If the software management application docs not
`[0082]
`have exclusive access during the upgrade,it is practically
`impossible to automate the process, since other applications
`may execule management operations on the network ele-
`ment (2) that is not included in the recipe. External appli-
`cations will introduce non-deterministic behavior into the
`
`upgrade that will be almost impossible to catch in the recipe.
`
`[0083] Data Conversion on Network Element(8):
`
`[0084] Before loading the new software, data conversions
`may have to be made. Data conversion may differ
`in
`complexity depending on the support provided by the net-
`work element (2). Necessary data conversion instructions
`for conversion of data structure and format are provided in
`a separate step in the recipe.
`
`[0085] Old values will remain where appropriate. If a
`parameter value has to be recalculated, the conversion step
`handles this. In case of a new parameter (due to structure
`conversion), the parameter will get a default value from a
`default value in the software configuration. The operator
`should able to change the supplied default values to site-
`specific values.
`
`[0086] Activate the New Software on Network Element
`(9):
`
`[0087] Activating the new software modules may differ in
`complexity depending on the support provided by the net-
`work element (2). A separate step in the recipe should
`supervise the loading of modules from the network element
`(2) file system onto main and special processors. Note that
`some elements may also have additional processor types.
`
`[0088] There are typically a number of different excep-
`tional situations that may arise during activation, simply
`because it is a complex task to upgrade network elements (2)
`that is in operation. Problems or deficiencies that have not
`been discovered earlier, will often surface during activation.
`For this reason,
`the activation step needs to focus on
`exception handling, and support rollback of activations that
`could not be completed.
`
`(0089] The order in which the load modules shall be
`loaded depends on interface compatibility rules. The step
`will define instructions to keep the interface compatibility.
`The step also contains instructions of where, ie. which
`target processors the load modules belongsto, and the order
`in which the load modules shall be activated.
`
`[0090] The step could provide checksum control during
`software loading.
`
`[0091] Release Exclusive Access to Network Element:
`
`[0092] This step includes releasing the exclusive access
`obtained carlicr, and restarting any nctwork management
`activities that was running prior to data conversion and
`activation of the network element (2). This may be imple-
`mented by having the “obtain exclusive access” step of the
`recipe save the activities that where running in some tem-
`porary storage, and then re-invoke the saved activities in this
`step.
`
`

`

`US 2003/0093688 A1
`
`May15, 2003
`
`[0093] Post Validate Software Configuration of Network
`Element (10):
`
`the software
`[0094] A step is included to check that
`configuration performed after the upgrade complies with
`expected values. This is to ensure that the correct software
`revisions have actually been installed. The step is similar to
`the software validation performed prior to activation, but if
`the validation fails, the activation should be rolled back. For
`this reason, rollback functions needs to be provided in this
`step.
`
`[0095] Post Health Checks of Network Element (11):
`
`[0096] The post upgrade health checks are similar to the
`checks performedprior to the upgrade, but in this case, there
`may also be a need to rollback the activation if discovered
`that the network element (2) is not working properly.
`
`[0097] Cleanup TemporaryFiles in Network Element File
`System (13):
`
`[0098] During upgrade, a numberof files may be tempo-
`rarily stored in the network element(2)file system, and to
`resolve this situation, a cleanup step should be included in
`the recipe to finalize the upgrade process (3).
`
`invention is intended for software
`[0099] The present
`upgrade of network elements, which may be seen as a
`special-purpose computer for use in communication net-
`works. However, there is nothing stopping it from being
`applied for software upgrade of general-purpose computers.
`In fact, network elements that realize application functions
`like unified messaging in next generation networks will be
`general-purpose computers.
`
`[0100] Abbreviations
`
`[0101] CORBA Common Object Request Broker
`Architecture
`
`{0102] FTP File Transfer Protocol
`
`[0103] HW Hardware
`
`[0104] NE Network Element
`
`[0105] NES Network File System
`
`[0106] O&M Operation and Maintenance
`
`[0107] SNMP Simple Network Management Proto-
`col
`
`[0108] SW Software
`
`[0109] TAR Tape Archive
`
`[0110] ZIP ZIP is a commonarchive format
`
`1. Method for installation of new software or upgrade of
`existing software by new software in workstations or net-
`work elements in a distributed data or telecommunication
`system, characterized by an automated process (3), con-
`trolled by a certain workstation (1), including the following
`sequential steps:
`
`validation of hardware configuration (5) of said worksta-
`tions or network elements (2), where said validation is
`performedto assure that said new software is loadable
`in said hardware configuration, finishing said process
`(3) if the validation (5) is not carried through success-
`fully,
`
`first validation of software configuration(5) of said work-
`stations or network elements (2) prior to activation of
`new software, where said validation is performed to
`assure that said new software and said existing software
`are compatible, finishing said process (3) if the valida-
`tion (5) is not carried through successfully,
`
`first condition check (6) of said workstations or network
`elements (2) prior
`to activation of new software,
`including necessary checks and measurements to
`ensure that status is as required for the upgrade process
`(3), finishing said process (3) if the condition check (6)
`not is carried through successfully,
`
`carrying out actions providing the certain workstation
`with exclusive network management access to said
`workstations or network elements (2),
`
`activating new software (9) on said workstations or net-
`work elements,
`returning an OK value if carried
`through successfully and a NOK value if not.
`
`releasing the exclusive network management access of
`said certain workstation
`
`second validation (10) of software configuration of said
`workstations or network elements (2) after activation of
`new software, where said validation is performed to
`assure that said new software correctly has been
`installed, returning an OK value if carried through
`successfully and a NOKvalue if not
`
`second condition check (11) of said workstations or
`network elements (2) after activation of new software,
`including necessary checks and measurements to
`ensure that status is as desired in a normalstate,
`
`cleaning up (13) temporary files that may have been
`temporary stored during installation or upgrade.
`2. Method as defined in claim 1, characterized in an
`additional step (4) prior to the step concerning validation of
`hardware configuration (5), where said new software which
`is to be installed or used for updating is transferred from said
`remote workstation (1)
`to the workstations or network
`elements (2) of the distributed data communication system.
`3. Method as defined in claim 1 or 2, characterized in an
`additional step (7) prior to the step concerning actions
`required to obtain exclusive network management access
`and after the step concerning condition check (6), where
`backup of said existing software and configuration data are
`accomplished and stored either on the network elements/
`workstations or on the remote workstation (1).
`4. Method as defined in any of the preceding claims,
`characterized in an additional step (8) prior to the step
`concerning release of the obtained exclusive network man-
`agement access and after
`the step concerning actions
`required to obtain exclusive network management access,
`where required data conversion including recalculation of
`values and introduction of new parameters in the existing
`software is accomplished.
`5. Method as defined in any of the preceding claims,
`characterized in that the step concerning the second condi-
`tion check (11) includes checking the current load,
`the
`alarms, or any logged records pending for each of the
`workstations or network elements (2) in the distributed data
`or telecommunication system.
`6. Method as defined in any of the preceding claims,
`characterized in an additional step (12) prior to the step
`
`

`

`US 2003/0093688 A1
`
`May 15, 2003
`
`concerning upcleaning (13) initiated only by a NOK value
`from the step concerning activation of the new software (9)
`or from the step concerning second validation (10) of
`software configuration, where the process (3) is rolled back,
`
`which includes undoingall change