Updating software within a telecommunications switch without interrupting existing communication and neither moving nor converting data

Description Submit all comments and votes

A portion of the disclosure of this patent document contains material to which a claim of copyright protection is made. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but reserves all other rights whatsoever.

BACKGROUND OF THE INVENTION

1. Technical Field of the Invention

The present invention generally relates to updating software within a telecommunications switch. More particularly, the present invention relates to a method and system for updating an old software version by exchanging the old software version with a new software version without a restart of the telecommunications switch.

2. Description of Related Art

In the modern telecommunication industry, computer software (software) is often used to control the various aspects of processing calls within a telecommunications switch. Unfortunately, telecommunications software, and other types of software, often contain errors or undesired responses. The errors or undesired responses are usually corrected by a new version of the software which is intended to replace the defective version,

In certain types of computing systems, such as stand-alone or batch processing systems, exchanging old software with a newer version presents few obstacles. Typically, the computer system is merely shut down during a period of the day when there is little activity and maintenance personnel are readily available. The old software is then simply removed and replaced by the newer version. Thereafter, the computing system is restarted and all future data processing is done with the new version of the software.

In other types of computing systems, such as modern stored program control (SPC) telecommunications exchange systems (commonly referred to in the industry simply as "switches"), the exchanging of software in the system is not as simple as in the standalone batch processing systems.

Telecommunication switches are designed and intended to run perpetually without interruption in order to serve the continuous need for communication services within a community. In other words, a continuous flow of telecommunications traffic is being processed by the switch even during off hours of the day or night. Any interruption in the operation of the switch would consequently result in a disruption of the telecommunications traffic within the switch. Such a disruption is highly undesirable in the telecommunication industry.

The real-time requirements of a telecommunications switch place severe constraints on the exchanging of a new version of software containing error corrections or "bug fixes" for an old versions of software without disrupting the existing telecommunications traffic being processed by the switch. It is highly desirable in the telecommunications industry to have a method and system which provides the capability to exchange software within the switch during operation, without the need for any downtime.

Therefore, it would be highly useful within the telecommunications industry to be able to exchange software during actual operation of the telecommunications switch without disrupting ongoing telecommunications traffic within the switch. The present invention provides such a method and system.

SUMMARY OF THE INVENTION

An object of the present invention is to provide a method and system for exchanging an old software version for a new software version within a telecommunications switch without a restart of the switch.

In one aspect, the present invention is a method of exchanging a new software version for an old software version within a telecommunications switch without a restart of the switch. The switch includes memory, a software loading subsystem, a database management subsystem, and a program exchange subsystem. The method includes the steps of loading the new software version into the memory with the software loading subsystem, and registering the new software version in the program exchange subsystem with the database management subsystem. The method also includes the steps of passivating the old software version with the program exchange subsystem, and activating the registered new software version with the program exchange subsystem.

In another aspect, the present invention is a method of exchanging a new software version for an old software version within a telecommunications switch without a restart of the switch. The switch includes memory, a software loading subsystem, a database management subsystem, and a program exchange subsystem. The method includes the steps of loading the new software version into the memory with the software loading subsystem, and registering the new software version in the program exchange subsystem using the database management subsystem. The method further includes the steps of activating the registered new software version with the program exchange subsystem, and passivating the old software version with the program exchange subsystem. The method also includes the steps of confirming the activated new software version with the program exchange subsystem, and certifying the confirmed new software version with the program exchange subsystem.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be better understood and its numerous objects and advantages will become more apparent to those skilled in the art by reference to the following drawings, in conjunction with the accompanying specification, in which:

FIG. 1 is a block diagram illustrating a telecommunications switch and a computer system employed in a preferred embodiment of the present invention;

FIG. 2 is a block diagram illustrating in greater detail the structure and contents for the Program Storage are a, Reference Storage are a, and Data Storage area, of the memory of the telecommunications switch of FIG. 1 according to a preferred embodiment of the present invention;

FIG. 3 is a block diagram illustrating the program exchange (PXCP) subsystem's components and their interactions with the components of a software loading subsystem, and a loading central processor subsystem within the telecommunications switch of FIG. 1 according to a preferred embodiment of the present invention;

FIG. 4 is a flow chart which generally illustrates the steps of a program exchange method for exchanging a new software unit with an old software unit within the switch of FIG. 1 according to a preferred embodiment of the present invention;

FIG. 5 is a flow chart which illustrates in greater detail the registration step of the new software unit in FIG. 4 according to a preferred embodiment of the present invention;

FIGS. 6A-6B are a flow chart illustrating in greater detail the activation step of the new software unit in FIG. 4 according to a preferred embodiment of the present invention;

FIG. 7 is a flow chart which illustrates in greater detail the confirmation step of the new software unit in FIG. 4 according to a preferred embodiment of the present invention;

FIGS. 8A-8B are a flow chart illustrating in greater detail the certification step of the new software unit in FIG. 4 according to a preferred embodiment of the present invention;

FIGS. 9A-9B are a flow chart illustrating in greater detail the passivation step of the new software unit in FIG. 4 according to a preferred embodiment of the present invention;

FIGS. 10A-10B are a flow chart illustrating in greater detail the step of removing the new software unit in FIG. 4 according to a preferred embodiment of the present invention;

FIG. 11 is a block diagram which illustrates the various program exchange states of a new software unit as it progresses through the program exchange method of the present invention; and

FIG. 12 is a block diagram illustrating an example of the various stages through which a new and old software unit progress during the program exchange method of the present invention.

DETAILED DESCRIPTION OF AN EXEMPLARY EMBODIMENT

Referring now to FIG. 1, a block diagram is shown which illustrates a telecommunications switch 104 and a computer system 102 employed in a preferred embodiment of the present invention. The switch 104 comprises a storage device 110, software 108, hardware 106, memory 122, and a database management subsystem (DBS) 124. The switch 104 may be, for example, a stored program control switch such as AXE 10 produced by Telefonaktiebolaget LM Ericsson in Sweden. The storage device 110 may be, for example, a floppy drive, a hard drive, a magnetic tape drive, or an optical drive.

As shown in greater detail in FIG. 2, the memory 122 is divided into a Data Storage (DS) area 206, a Reference Storage (RS) area 204, and a Program Storage (PS) area 202. The software 108 is loaded from the storage device 110 into memory 122, and resides within each of the PS 202, DS 206, and RS 204 areas. The software 108 is used to control the hardware 106 via communication paths 112 and 114 (FIG. 1). The computer system 102 communicates with the switch 104 via communication path 116. The computer system 102 may be, for example, an individual personal computer system, an operation and maintenance center system, a network manager center system, or other similar type of system. The DBS 124 may be, for example, a semi-relational database management system.

Referring now to FIG. 2, a block diagram is shown which illustrates in greater detail the structure and contents for each of the PS 202, RS 204, and DS 206 storage areas of the memory 122 of FIG. 1 according to a preferred embodiment of the present invention. The Program Store (PS) area 202 is used for storing a plurality of function blocks (computer programs) each of which is identified by a unique identification number. Each of the function blocks stored within the PS 202 area may have data such as variables associated with them. Any variables which are referenced by a function block stored within the PS 202 area, are stored separately in the DS area 206. Each variable stored within the DS area 206 is also identifiable by a unique variable identification number. The Reference Store (RS) 204 area is employed for determining the locations of function blocks stored within the PS area 202 and their associated variables stored within the DS area 206.

The RS area 204 employs a plurality of reference tables and base tables to track the various locations of the function blocks stored within PS area 202 and their associated variables within the DS area 206. Each function block which is stored within the PS area 202, has an associated reference table within the RS area 204 which is indexed according to the function block's unique identification number. Each variable used by a particular function block within the PS area 202 has its location within the DS area 206 specified in a Base Address Table (BAT). A reference table comprises a Program Start Address (PSA), and a Base Start Address (BSA). The PSA indicates the start address of an associated function block stored within the PS 202 area. The BSA indicates a location for a BAT, associated with the function block, stored within the RS area 204.

A Signal Distribution Table (SDT) exists at the start address of each function block stored within the PS area 202. The SDT specifies locations for tasks (procedures/functions) within the function block. An example of a function block 208 and its associated tables and variables is also shown in FIG. 2. Function block 208 is stored within the PS area 202, and is identifiable by function block number 01 (No. 01). An SDT 210 is located at the start address of function block 208, and is employed for locating specific tasks within function block 208. The function block 208 has an associated reference table 212 within the RS area 204. The reference table 212 is indexed within the RS area 204 by the function block No. 01. The reference table 212 comprises a PSA 220 and a BSA 222. The PSA 220 identifies the start address for function block 208. The BSA 222 identifies the location of a BAT 224 stored within the RS area 204. The BAT 224 identifies the locations of variables used by the function block 208. The variables may be, for example, variables state 214, Distcnt 216, and Mup 218.

The following description is an example of how a specified task within the function block 208 can be invoked. First, the RS area 204 is accessed and searched for any reference table indexed by the function block No. 01. In this particular example, reference table 212 matches the search. Next, PSA 220 is used to locate the start address for function block 208. The start address is used in conjunction with the specified task to access SDT 210 and invoke the specified task. During the execution of the specified task, function block 208 may require the use of variables state 214, Distcnt 216, or Mup 218. If function block 208 requires the use of the variables, then function block 208 uses BSA 222 to access BAT 224 to determine the locations of the variables within the DS area 206.

Referring now to FIG. 3, a block diagram is shown which illustrates the subsystem program exchange (PXCP) 394 components and their interactions with the components of a software loading subsystem (CPS) 390, and a loading central processor subsystem (LOCP) 392 within the switch of FIG. 1 according to a preferred embodiment of the present invention. PXCP 394 comprises the following components: a program exchange administrator (PXZA) 320, a program exchange data difference handler (PXZD) 318, a program exchange signal difference handler (PXZS) 316, and a program exchange machine dependent routine (PXZMD) 314. PXCP 394 communicates with the following CPS 390 components: an audit function controller (AFCO) 302, a program test monitor (TEM) 304, a loading administrator reference information handler (LARI) 308, and a system event information broadcaster (KEED) 306. PXCP 394 also communicates with the following LOCP 392 components: a loading administration controller (LACO) 310, and a loading administration symbol handler (LASYMB) 312. Each of the components of the PXCP 394 and their interactions with the components of the CPS 390 and LOCP 392 are described briefly below.

PXZA 320 coordinates the program exchange implementation. PXZA 320 communicates with PXZD 318, PXZS 316, KEED 306, PXZMD 314, and LACO 310 via bi-directional logic paths 324, 326, 348, 328, and 322 respectively. PXZD 318 verifies compatibility between stored data variables for the old and new software units, and optimizes the amount of RS 204 and DS 206 areas required for the new software unit during the program exchange. PXZD 318 communicates with PXZA 320, LACO 310, and LARI 308 via hi-directional logic paths 324, 334, and 330 respectively. PXZS 316 verifies compatibility between signal interfaces for the old and new software units, and stores information concerning any differences between the signal interfaces. PXZS communicates with PXZA 320 and LARI 308 via communication paths 326 and 332 respectively. PXZMD 314 implements the program exchange using assembly routines to directly update the reference table and BAT for the new software unit. A different version of PXZMD which performs substantially the same function is required for each different hardware platform used in the AXE 10 switch. PXZMD 314 communicates with AFCO 302, TEM 304, LASYMB 312, LACO 310, and PXZA 320 via bi-directional communication paths 342, 344, 340, 338, and 328 respectively.

The communication signals which travel each of the logic paths 324, 326, 330, 332, 334, 338, 340, 342, 344, and 348 during the program exchange method are listed in Appendix A.

LACO 310 notifies PXCP 394 when a new software unit has been loaded for program exchange, and acts as an interface between the PXCP 394 and the CPS's 390 store functions. LASYMB 312 administers signal and variable name symbols for the new and old software units to be exchanged.

AFCO 302 performs the function of an interface between the PXCP 394 and the CPS's 390 audit functions. TEM 304 comprises central functions for a program test system. LARI 308 is machine-dependent, and comprises a plurality of service routines for reading and updating reference information used by the operating system (OS) of the switch 104 (FIG. 1).

Referring now to FIG. 4, a flow chart is shown which generally illustrates the steps of a program exchange method for exchanging a new software unit with an old software unit (function block) within the switch 104 of FIG. 1 according to a preferred embodiment of the present invention. The method begins at step 402 and proceeds to step 404 where a new software unit which is to be exchanged with an old software unit is loaded into the memory 122 of the switch 104 (FIG. 1). The method then proceeds to step 406 where the new software unit is registered, and the method continues to step 408 where the new software unit is activated. After the new software unit has been activated, the method proceeds to confirm the new software unit at step 410. The method then continues to step 412 where it is determined whether or not the new software unit is operating properly. If it is determined that the new software is operating properly, then the method proceeds to step 418. If, however, it is determined that the new software is operating improperly, then the method proceeds to step 414. At step 414, the new software unit is passivated, and the method proceeds to step 416 where the passivated new software unit is removed from the switch 104, and the method proceeds to end at step 422. At step 418 the new software unit is certified, and the method continues to step 420 where the old software unit is removed from the memory 122 of the switch 104 (FIG. 1), and the method proceeds to end at step 422. A detailed description of the above steps in FIG. 4 is provided below.

In a preferred embodiment of the present invention a command transaction within DBS 124 (FIG. 1) can be used to specify a plurality of new software units each one of which replaces an associated old software unit.

At step 404 of FIG. 4, the new software unit is loaded into the memory 122 of the switch 104 (i.e. PS 202, RS 204 and DS 206). After the new software unit has been successfully loaded for program exchange, the DBS 124 via LACO 310 uses PLEX-SQL (DBS) statements to insert exchange information into a PXPROGRAM database table. The exchange information may include, for example, the block name for the new software unit, the block number of the old and new software units, the product number of the old and new software units, and the R-STATE of the old and new software units. The loading of the exchange information into the PXPROGRAM table results in the new software unit being registered at step 406.

Referring now to FIG. 5, a flow chart is shown which illustrates in greater detail the registration of the new software unit at step 406 of FIG. 4 according to a preferred embodiment of the present invention. The registration of the new software unit begins at step 500 and proceeds to step 504 where the method determines whether or not a table row insert into the PXPROGRAM table is permitted. A table row must be inserted in the PXPROGRAM table by the program exchange subsystem (PXCP) 394 (FIG. 3) and not by an operator. If it is determined that the table row insert is permitted, then the method proceeds to step 506. If, however, it is determined that the table row inserted is not permitted then the method proceeds to step 514.

At step 506, it is determined whether or not the new software unit is compatible with the old software unit. A new software unit is compatible with an old software unit when the following exists within the new software unit: the block type and the block type-External are the same as the old software unit's block type and block type-External, no corrections exist within the correction area, the signal interface is compatible with the signal interface of the old software unit, and the structure of the variables is compatible with the structure of the old software unit's variables. PXZS 316 performs the determination of whether the signal interfaces of the old and new software units are compatible. The signal interfaces are compatible if they are identical. PXZD 318 also determines whether the structure of the variables for the old and new software units is compatible. PXZD 318 stores any compatible variable differences in a VARIABLEDIFF database table within the DBS 124 (FIG. 1). If it is determined that the new software unit is compatible, then the method proceeds to step 508. If, however, it is determined that the new software unit is incompatible, then the method proceeds to step 510.

At step 508, identical variables within the new software unit that currently exist within the old software are removed from the new software unit. The identical variables may be removed in order to save DS area 206 (FIG. 2) space, since the new software unit inherits the old software unit's variables. After the identical variables have been removed from the new software unit, the new software unit's BAT is compressed so that only one position exists for each added, changed or deleted variable. After the new software unit's BAT has been compressed, the VARIABLEDIFF table is updated to define mapping between positions for variables within the compressed BAT and variables within the old software unit's BAT. The method then continues to step 512. At step 510, a variable result.sub.-- code is set to indicate that the new software unit is incompatible with the old software unit, and the method proceeds to step 512. At step 514, it is determined whether or not a valid table operation was performed. If it is determined that a valid table operation was performed, then the method proceeds to step 512. If, however, it is determined that an invalid table operation was performed, then the method proceeds to step 516.

At step 516, a fault indicating that an invalid table operation was performed is returned to the DBS 124 (FIG. 1), and the method proceeds to end at step 518. At step 512, a function within LACO 310 (FIG. 3) is invoked, and the method proceeds to end at step 518. The invoked function in LACO 310 concludes the registration of the new software unit.

FIGS. 6A-6B are a flow chart illustrating in greater detail the activation of the new software unit at step 408 of FIG. 4 according to a preferred embodiment of the present invention. The activation of the new software unit is performed by PXZA 320 (FIG. 3). The activation of the new software unit is initiated by generic DBS commands which enable the new software unit to be executed. If a system restart of the switch 104 occurs during the program exchange process, then the "ACTIVE" new software unit is passivated. Hereinafter, the term passivated is used to define a software unit which is capable of executing but is denied permission.

Referring now to FIG. 6A, the activation of the new software units specified within the PXPROGRAM table begins at step 600 and proceeds to step 604 where it is determined whether or not permission to update the system reference information is granted from LACO 310. If it is determined that LACO 310 grants permission, then the method proceeds to step 610. If, however, it is determined that LACO 310 denies permission, then the method proceeds to step 606 where a function fault code is reported to the DBS 124 (FIG. 1), and the method procee