JP2005502971A - Method, apparatus and system for updating software - Google Patents

Abstract

The present invention provides a method, apparatus, and system for updating software.
A system for remotely updating software existing in at least one electronic device connected to a network. The electronic device has a non-volatile rewritable storage device divided into at least two partitions, one partition containing core firmware and the other partition containing auxiliary software. When an update is received at the device, the updated core firmware is written and overwritten on the partition containing the auxiliary software of the rewritable storage device. Once this is completed and confirmed to be successful, the previous version of the core firmware stored in the storage device is prevented from executing by the device. The updated auxiliary software is then written over the old version of the core firmware and overwritten. When this writing is complete, the device determines an appropriate time to reboot the device in order to execute the updated software. In another embodiment, the device's current core firmware is copied from the partition in which it resides to the other partition and overwritten with auxiliary software stored there. The new core firmware received to update the device will be overwritten on the first partition, and if the upgrade fails, the copied old core firmware exists and if the first partition can be successfully updated The auxiliary software is written to the second partition and overwrites the copied old core firmware. In this way, the location of the core firmware and auxiliary software within the partition is maintained during normal operation of the device.

Description

【Technical field】
[0001]
The present invention relates generally to methods, apparatus, and systems for updating software in remotely located electronic devices. More particularly, the present invention relates to methods, systems and devices for updating software residing in remotely located electronic devices connected to a network, according to these methods, systems and devices, Those electronic devices can recover from the update failure and complete the update via the network.
[Background]
[0002]
Many common electrical appliances include a rewritable memory that can hold software or data even when the device is powered down. Software or data held in the rewritable memory can be rewritten. Currently, such rewritable memory is typically flash memory or equivalent, but other types of memory or storage devices may be used. A flash memory is a kind of nonvolatile semiconductor memory. Therefore, data is not lost even when the power is turned off, and can be rewritten to include different data. Flash memories are widely used because they are small, fairly durable, fast, and rewritable. For example, cell phones use flash memory to hold software that performs phone functions such as abbreviated numbers, ring tones, firmware updates, and the like. Therefore, new functions are provided or bug fixes are implemented, so that firmware in the electronic device can be updated.
[0003]
However, flash memory or equivalent is not without its drawbacks. One drawback is that flash memory is relatively expensive. In equipment where manufacturers must keep consumer prices low, the equipment must be designed to minimize the amount of flash memory required.
[0004]
While it is clearly desirable to be able to update firmware or other software or data at the device on which they are located, it is not always easy to update the flash memory in the electronic device. For example, if you need to update most mobile phone firmware or other software, you must bring the mobile phone to a local service center. The local service center has an update station that holds updated software, and updates the software by connecting a mobile phone to the update station via a wired data link. If there is a problem transferring new software during an update session, the device will be in an unknown or inoperable state. In this case, the device will be reset and new software will simply be transferred again until the transfer is complete and the device is operating properly.
[0005]
However, this method is very rarely an attractive option. This is because such a method requires the active involvement or cooperation of the user who has to visit the service center. In the case of devices such as wireless local loop subscriber stations, bringing a subscriber station to a service center, in addition to the inconvenience of going to the service center, is a telephone or data service where the subscriber station is usually located. It means that it temporarily disappears.
[0006]
Attempts have been made so far to update the non-volatile rewritable memory in devices via a network to which the devices are connected. For example, a mobile phone can receive software updates to its flash memory via a serving wireless network. However, the technique is problematic in that if for some reason the transmission fails or if there is an error in the transmission, the device may remain in an unknown or inoperable state. In such a case, unlike the above-described example in which the update is performed in the service center, it is not possible to attempt to retransmit the update software, and the user is left with an inoperable device until the service center is returned.
[0007]
One prior art solution to this problem has been to provide a rewritable memory consisting of separate banks. U.S. Pat. No. 6,057,031 teaches a mobile phone system in which half of the rewritable memory is a bank used to hold the current version of software and has been updated. The software is downloaded to the other half bank of the rewritable memory. If the mobile phone determines that the transfer was successful, for example by examining the CRC, the mobile phone switches to use the updated bank of memory, and the bank containing the old software is Can be used to receive updates. A similar prior art solution is taught in US Pat. These configurations prevent unrecoverable errors from occurring during the update, but require twice as much expensive rewritable memory.
[0008]
Also, the prior art update methods described above typically require the cooperation or involvement of the device user, who must either go to a service center or transfer update data over the network. And the transfer must be initiated. Critical updates, such as improving network stability or capacity for network operators, may be rejected by some users or otherwise delayed to inconvenience users . Furthermore, in the known prior art method, updating each device in the network must be performed individually.
[0009]
What is desired is a method and system for reliably updating software or data in non-volatile rewritable memory of devices connected to a network. It is desirable that the method and system do not require twice the amount of non-volatile rewritable memory in the device and can be automatically and concurrently executed in multiple devices. .
[Patent Document 1]
US Pat. No. 6,023,620
[Patent Document 2]
US Pat. No. 6,275,931
DISCLOSURE OF THE INVENTION
[Problems to be solved by the invention]
[0010]
An object of the present invention is to provide a novel method, system, and apparatus for updating software existing in an electronic device via a network. These method, system, and apparatus are described above. This eliminates or alleviates the disadvantages of the prior art.
[Means for Solving the Problems]
[0011]
According to a first aspect of the present invention, a system for remotely updating at least one electronic device via a communication link is provided. The system includes an update server, volatile memory, a non-volatile rewritable storage device present in the at least one electronic device, and an update client operating on the device. The update server can be used to transfer updates comprising core firmware and auxiliary software to at least one electronic device via a communication link. Volatile memory is used to temporarily store transfers received from the update server. The non-volatile rewritable storage device is divided into at least first and second partitions, the first partition stores one version of the core firmware and one of the auxiliary software, and the second partition has a version of Stores the other of the core firmware and auxiliary software. The update client runs on the device and (1) overwrites the received update core firmware stored in volatile memory with the version of auxiliary software stored in one of the first and second partitions and writes (2) When the device is next rebooted, set the device to run the core firmware stored in (1), and (3) Stored in volatile memory Overwrite the received updated auxiliary software with the version of the core firmware stored in the other of the first and second partitions, check if this write was successful, (4) reboot the device, Updated core firmware and updated auxiliary Running the software, it can be used to.
[0012]
According to another aspect of the invention, a method for updating software present in a plurality of remote devices connected to a network is provided. The method includes (1) placing an update comprising at least a core firmware update on an update server; (2) identifying a device to be updated connected to a network; and (3) updating the update server. To each identified device over the network, each identified device verifies that the update was received correctly, and if there is an error in the update received so far, Requesting retransmission and receiving the part; (4) core firmware of received updates, ensuring that a valid copy of the previous version of core firmware is always present in the storage device; Non-volatile rewrite with part partitioned Writing to the possible storage device, overwriting the core firmware part over the partition containing the previously stored version of software, and checking the write; (5) using the checked update core firmware partition by the device Considered as valid core firmware to be performed and the previous version of the core firmware is considered unusable; (6) rebooting the device to load and execute the updated software; including.
[0013]
Optionally, before the core firmware portion of the received update is written to the partitioned non-volatile rewritable storage device, the previous version of the core firmware is copied onto the auxiliary software stored on the storage device, It may be verified that it has been correctly copied, the copy is considered valid core firmware to be used by the device, and the original core firmware may be considered unusable.
[0014]
The update may also include updated auxiliary software. Auxiliary software is received and tested by the device, and before the device is rebooted, the auxiliary software update is overwritten with an unusable previous version of the core firmware.
[0015]
According to another aspect of the invention, a system is provided for remotely updating core firmware residing in at least one electronic device via a communication link. The system includes a memory subsystem residing in the electronic device and an update server that can be used to transfer an update including at least an updated version of core firmware to the electronic device over a communication link. . The memory subsystem includes a non-volatile rewritable memory in which the core firmware is stored and the non-volatile rewritable memory is large enough to store auxiliary software, but the core Not large enough to store firmware, updated version of core firmware, and auxiliary software simultaneously. The core firmware (1) writes the updated version of the core firmware to the non-volatile rewritable memory, not overwriting the previous version of the core firmware, and optionally checks whether the writing was correct, and (2) an instruction for disabling the use of an earlier version of core firmware, whereby an updated version of the core firmware is loaded and executed when rebooting at least one electronic device; Including.
[0016]
In addition, the core firmware overwrites at least a portion of the previous version of the core firmware that has been disabled, but does not overwrite the updated version of the core firmware. Instructions for writing to the rewritable memory may be included. Optionally, it may be checked whether the writing was done correctly.
[0017]
The memory subsystem may further include a non-volatile memory in which instructions are stored, which instructions are executed when the electronic device reboots to find a version of the core firmware that is not disabled. The non-volatile rewritable memory is scanned. If a version of the core firmware that is not disabled is found, that version is loaded and executed.
[0018]
According to yet another aspect of the present invention, a system is provided for remotely updating core firmware and auxiliary software residing in at least one electronic device via a communication link. The system includes a memory device residing in at least one electronic device for storing core firmware and auxiliary software, and an update that can be used to transfer the update to the at least one electronic device via a communication link. Server. The memory device includes a non-volatile rewritable memory. In the memory, the first partition stores the first memory contents including the core firmware, and the second partition includes the auxiliary software small enough to be stored in the first partition. 2 memory contents are stored. The second partition is large enough to store the first memory contents. The core firmware includes an update client that receives the updated version of the first memory contents and writes the updated version of the first memory contents to the second partition, Overwrite the memory contents, and optionally verify that the write was done correctly, disable the use of the first memory contents contained in the first partition, and receive an updated version of the second memory contents Then, the second memory content of the updated version is written to the first partition, overwritten on the first memory content that is disabled, and the electronic device is rebooted. Furthermore, the memory device includes a non-volatile memory in which a bootloading instruction is stored, and the bootloading instruction is executed when the electronic device is rebooted. The bootloading instruction includes an instruction that, when executed, searches the nonvolatile rewritable memory to find a version of the first memory content that is not disabled, and if found, The control of the electronic device is switched to the core firmware stored in the memory contents.
[0019]
Alternatively, when the update client receives the updated version of the first memory contents, it copies the first memory contents to the second partition, overwrites the second memory contents, and updates the updated version of the first memory contents. One memory content may be written to the first partition and overwritten on the first memory content. Optionally check that the write was done correctly. Upon receipt of the updated version of the second memory content, the updated version of the second memory content is written to the second partition, optionally checking that the writing was correct, and the electronic device is Reboot.
[0020]
Additionally or alternatively, the update client may reduce the size of the second partition upon receiving an updated version of the first memory contents. Thereby, the second partition is just large enough to store the updated version of the first memory contents, and the updated version of the first memory contents is written to the second partition. Overwrite the previous contents of and optionally verify that the write was done correctly. And making the first memory content version stored in the first partition unusable and receiving the updated version of the second memory content, increasing the size of the first partition, Writes the updated version of the second memory contents to the first partition, overwriting the previous contents of the first partition, including all portions of non-volatile rewritable memory not included in the second partition Optionally, check that the writing was done correctly and reboot the electronics.
[0021]
Optionally, the update client may further be used to notify the update server whether at least one electronic device can be updated at a given time. In response to the information received from the update client, the update server postpones the update of the electronic device if the electronic device is not ready to be updated. The update server can also prioritize updates, thereby allowing the update client to update electronic devices that would otherwise not be updated.
[0022]
In accordance with yet another aspect of the present invention, a memory subsystem for use in an electronic device is provided, the memory subsystem including a non-volatile rewritable memory that stores core firmware and auxiliary software. The core firmware contains instructions that overwrite at least a portion of the auxiliary software, but do not overwrite previous versions of the core firmware, and update the updated version of the core firmware to non-volatile rewritable memory. To check for an updated version of the core firmware so that the previous version of the core firmware cannot be used, so that when the electronic device is rebooted, the updated version of the core firmware is loaded and Executed. The core firmware may include instructions that update to overwrite at least a portion of the previous version of the core firmware that has been disabled, but not to update the updated version of the core firmware. Write the version of the auxiliary software to the non-volatile rewritable memory. The memory subsystem may also include a non-volatile memory that stores instructions that are executed when the electronic device reboots to find a version of the core firmware that is not disabled. Scan the rewritable memory and load and execute a version of the core firmware that is not disabled.
[0023]
According to yet another aspect of the invention, a memory subsystem for use in an electronic device is provided, the memory subsystem including a non-volatile rewritable memory, wherein the non-volatile rewritable memory includes: The core firmware is stored and the non-volatile rewritable memory is large enough to store the core firmware and auxiliary software, but not large enough to store the core firmware simultaneously. The core firmware contains instructions that do not overwrite the previous version of the core firmware, write the updated version of the core firmware to non-volatile rewritable memory, and update the updated version of the core firmware. Inspects and prevents use of previous version of core firmware, so that when the electronic device is rebooted, the updated version of core firmware is loaded and executed. The core firmware may include instructions that update at least a portion of the previous version of the core firmware that has been disabled, but not over the updated version of the core firmware. Write the version of the auxiliary software to the non-volatile rewritable memory. The memory subsystem may also include a non-volatile memory that stores instructions that are executed when the electronic device reboots to find a version of the core firmware that is not disabled. Scan the rewritable memory and load and execute a version of the core firmware that is not disabled.
[0024]
According to yet another aspect of the invention, such instructions for use in an electronic device capable of executing stored instructions and receiving an updated version of such instructions. A memory subsystem for storing is provided. The memory subsystem includes a nonvolatile rewritable memory and a nonvolatile memory. A boot loading instruction that is executed when the electronic device is rebooted is stored in the nonvolatile memory. Non-volatile rewritable memory allows the electronic device to restart, or can continue to update the non-volatile rewritable memory if the electronic device reboots while the update is in progress Rebooting an electronic device in which the first memory content including at least the instructions necessary to achieve is stored in the first partition and is small enough to be stored in the first partition and not included in the first memory content The second memory content, including all instructions necessary for subsequent normal operation, is stored in a second partition that is large enough to store the first memory content. The instruction stored in the first memory content, when executed after the updated version of the first memory content is received, writes the updated version of the first memory content to the second partition. An instruction that overwrites the second memory contents and prevents the use of the first memory contents contained in the first partition, and is executed after an updated version of the second memory contents is received. And writing an updated version of the second memory contents to the first partition, overwriting the first memory contents made unusable, and rebooting the electronic device.
[0025]
Alternatively, when the instructions stored in the first memory contents are executed after an updated version of the first memory contents is received, the instructions copy the first memory contents to the second partition and Overwriting the memory contents of 2 and writing the updated version of the first memory contents to the first partition and overwriting the first memory contents, and receiving the updated version of the second memory contents Executed to write the updated version of the second memory contents to the second partition, overwrite the first memory contents made unusable, and reboot the electronic device. May be included.
[0026]
Alternatively, if the instructions stored in the first memory content are executed after an updated version of the first memory content is received, the size of the second partition is reduced, if possible, and Will cause the second partition to be large enough to store the updated version of the first memory contents, write the updated version of the first memory contents to the second partition, and An instruction that overwrites the previous contents and disables the use of the first memory content version stored in the first partition, and is executed after an updated version of the second memory content is received If possible, increase the size of the first partition and include it in the second partition Write an updated version of the second memory contents to the first partition, including all portions of non-volatile rewritable memory, overwriting the previous contents of the first partition, and And an instruction to reboot.
[0027]
In accordance with yet another aspect of the invention, a method is provided for installing an update in software stored in non-volatile rewritable memory that is not large enough to hold both the update and the software. The method divides the update into individually writable portions including a core portion that can be stored in less than half of the non-volatile rewritable memory, and the non-volatile rewritable memory is updated. An individually rewritable part that contains a core part that contains less than half of the non-volatile rewritable memory and that contains a software part, corresponding to the core part and an auxiliary part that is just large enough to hold the update core part A step of writing the update core part into the auxiliary part of the non-volatile rewritable memory and checking whether the writing has been made correctly, and before being included in the core part of the non-volatile rewritable memory. Steps and Updates to Prevent Using Versions of Software Writing portions of the updates that are not included in the core portion, the portion of the non-volatile rewriting operation must be not included in the core portion of the non-volatile rewriting addressable memory, comprising the steps of examining whether the write is successful, a.
BEST MODE FOR CARRYING OUT THE INVENTION
[0028]
Embodiments of the present invention will be described below with reference to the accompanying drawings.
[0029]
Referring now to FIG. 1, a wireless network that allows for upgrading software or data residing in at least one electronic device is indicated generally by the numeral 20. The network 20 includes at least one update station, which in this example is a radio base station 24, which can be used to send software updates over a two-way communication link 32. . Network 20 also includes subscriber stations 28a, 28b,... For wireless local loops capable of voice and data. . . , 28n. Subscriber station 28 may be a customer premises equipment in a wireless local loop for voice and data, a wireless POS terminal, or a personal digital assistant with a modem ("PDA"), a mobile phone, a cable modem, a laptop computer, and It may be any other electronic device such as other suitable electronic devices that can communicate via communication link 32 that would occur to those skilled in the art.
[0030]
The number “n” of subscriber stations served by the base station 24 may vary depending on the amount of available radio bandwidth or the configuration and requirements of the subscriber station 28. For the sake of clarity, only the subscriber station 28 will be mentioned here as the electronic equipment to be updated. However, other electronic devices such as those described above and those capable of receiving software updates via communication link 32 are within the scope of the present invention.
[0031]
In the network 20, the base station 24 may be connected by an appropriate gateway and backhaul 34 to at least one telecommunications network such as the landline data exchange network 30 and the public telephone exchange network 33. The backhaul 34 may be a link such as T1, T3, E1, E3, OC3, or other suitable landline link, or may be a satellite channel link, other radio or microwave channel link, Or it could be any other link suitable to operate as a backhaul as would be conceivable by those skilled in the art. The base station 24 may also include a software update server 36 or may be connected to the software update server 36 by a backhaul 34 or other means, the software update server 36 being connected to the subscriber station 28. Includes software load for. In addition, the base station 24 is connected to a subscriber database, which is located in the update server 36, or such as a centralized network operations center (described below). Located in a separate database server (not shown) provided elsewhere, that database server maintains a record of the current software load of the subscriber station 28.
[0032]
In the wireless network 20, a communication link 32 is established between the base station 24 and each subscriber station 28 by radio, but other physical connections including wired, infrared, and ultrasonic means. Means may be used. The communication link 32 connects the base station 24 and each subscriber station 28a, 28b,. . . , 28n may transmit voice and data information. Communication link 32 may be implemented by various multiplexing techniques including TDMA, FDMA, CDMA, OFDM, or hybrid systems such as GSM. Further, the communication link 32 may be located in various channels carrying different types of data such as voice communication or data transmission, or for various purposes such as end-user communication or network 20 control. May be used. In the embodiment shown in FIG. 1, the data sent over the communication link 32 is sent as IP (Internet Protocol) packets, but any suitable type of packet may be used.
[0033]
FIG. 2 shows an example of the base station 24 in more detail. Base station 24 includes one or more antennas 40 for receiving and transmitting wireless communications over communication link 32. The antenna 40 is connected to a radio transceiver 44, and the radio transceiver 44 is connected to a modem 48. The modem 48 is connected to a microprocessor router assembly 52, such as a Pentium® III processor system and associated equipment manufactured by Intel. It will be appreciated that the microprocessor router assembly 52 may include multiple microprocessors if desired. Further, the router functionality of the microprocessor router assembly 52 may be provided as a separate unit if desired. The router functions implemented within the microprocessor router assembly 52 are connected to the backhaul 34 in any suitable manner and connect the base station 24 to the at least one telecommunications network 30,33. Further, as described above, the base station 24 may be connected to the update server 36 directly or via the backhaul 34.
[0034]
Referring now to FIG. 3, an example subscriber station 28 is shown in more detail. Subscriber station 28 includes one or more antennas 60 for receiving and transmitting wireless communications over communication link 32. The antenna 60 is connected to a radio transceiver 64, and the radio transceiver 64 is connected to a modem 68. The modem 68 is connected to the microprocessor assembly 72, which is connected to the memory device 78.
[0035]
Microprocessor assembly 72 may include, for example, a StrongARM processor manufactured by Intel, which performs various functions including A / D-D / A conversion, filters, encoders, decoders, Implementing a data compressor, data decompressor, and / or packet decomposition. As shown in FIG. 3, the microprocessor assembly 72 also interconnects the modem 68 with one or more ports 76, which one or more ports 76 connect the subscriber station 28 with data. It may be used to connect to devices and telephone devices. An example of a telephone device is a telephone. Examples of data devices include personal computers, PDAs, or the like. Accordingly, the microprocessor assembly 72 can be used to process data between the port 76 and the modem 68.
[0036]
At the subscriber station 28, the memory device 78 is used by the microprocessor assembly 72 to store two main components: (1) the instructions and data necessary to operate the subscriber station 28. A volatile random access memory ("RAM") 82, which may be dynamic RAM (DRAM) or synchronous DRAM (SDRAM), and (2) a subscriber station used to store data including instructions 28 includes a nonvolatile rewritable storage device RSU86, which is a flash memory. In the RSU 86, data is not lost even when the subscriber station 28 is powered off. The memory device 78 stores all instructions and data necessary for proper and desired functionality of the subscriber station 28, including boot software, operating system, software application, radio resource management software, device drivers, and data files. Can be used to include.
[0037]
As is well known to those skilled in the art, the RAM 82 is typically faster than the flash memory used in the RSU 86, so that in the presently preferred embodiment of the subscriber station 28, the instruction And, in most cases, the data is copied from RSU 86 to RAM 82 by microprocessor assembly 72 before being executed. In certain circumstances, instructions or data are read directly from the RSU 86 into the microprocessor assembly 72 for execution or operation as is well known to those skilled in the art.
[0038]
Microprocessor assembly 72 can also be used to write instructions and data from RAM 82 to RSU 86, as described below.
[0039]
In the subscriber station 28, the RAM 82 is a 32 Mbyte SDRAM, and the RSU 86 is an 8 Mbyte flash memory. However, the capacity and type of the RAM memory are not particularly limited, and other types of non-volatile rewritable memories such as general IDE and SCSI hard drives, optical memory storage devices, and EPROMS are flash memories. May be used instead of Other types of non-volatile rewritable memories will occur to those skilled in the art. Those skilled in the art will also appreciate modifications to the following description that may require the use of an alternative non-volatile rewritable memory or the like in the RSU 86 in embodiments of the present invention.
[0040]
A flash memory such as that used for the RSU 86 must generally be read and written in blocks. A block is the smallest unit that can be written and must be erased before being written (in other words, flash memory is "granular" and how to use it as described below) Influences). Those skilled in the art will appreciate that this constraint does not apply to any other form of non-volatile rewritable memory that may be used in place of flash memory at the subscriber station 28. One particular flash memory currently used at the subscriber station 28 has a block size of 256K bytes. Referring now to FIG. 4a, the initial partitioning of RSU 86 is schematically shown. The RSU 86 is divided into logical partitions, each of which is a storage device consisting of one or more logically contiguous blocks. As will be apparent to those skilled in the art, the terms “partition” and “logical partition” are used interchangeably herein. The only limitation to the present invention is that the partition must be resizable and / or relocatable, except in special cases where equally sized partitions may be used. Accordingly, both logical partitions and, in some cases, physical partitions that meet this requirement are included within the scope of the present invention.
[0041]
Each partition has at least a starting position and a length / size defined for that partition. As is well known to those skilled in the art, partitions are treated as if they were independent individual memory devices for some purpose. For example, a hard drive with two partitions appears to the application software running on a computer connected to the hard drive as two independent hard drives. Also, as is well known to those skilled in the art, logical partitions and some physical partitions are typically added, deleted, or resized to provide flexibility within a storage device. can do. In the case of logical partitions, this is done by changing the data structure stored in non-volatile rewritable memory, or, as in the case of subscriber station 28, re-started at startup, as described below. Composed. The data structure includes data such as the start position and size / length described above, and associates a physical location in the storage device with a logical partition. Logical partitioning can also make discontinuous storage locations appear to applications as if they were contiguous blocks. For example, even-numbered blocks (ie, blocks 0, 2, 4, 6, etc.) appear to the application as one contiguous block of storage and are odd-numbered blocks (ie, blocks 1, 3). 5, 7, etc.) can be partitioned so that it appears to the application as the other contiguous block. One skilled in the art can devise many other partitioning schemes and structures, and these are within the scope of the present invention. At the subscriber station 28, the RSU 86 is first divided into three partitions: a boot partition 104, a core firmware partition 108, and an auxiliary software partition 112.
[0042]
The boot partition 104 is located in the first block of the RSU 86 and contains boot loading firmware for the subscriber station 28. The subscriber station 28 is configured to start up (boot) first with the microprocessor assembly 72 executing instructions that are present in the first block of the RSU 86, but to read the last block of the RSU 86. Other schemes may be used. The remaining blocks of RSU 86 are first partitioned into core firmware partition 108 and auxiliary software partition 112 as described below. In FIG. 4 a, the core firmware partition 108 is shown as occupying the block immediately after the boot partition 104, and the auxiliary software partition 112 is a block that exists between the last block of the core firmware partition 108 and the end point of the RSU 86. Shown as occupying. As described below, the initial locations of the core firmware partition 108 and the auxiliary software partition 112 may be reversed, and may be reversed as a result of the upgrade, as described below (FIG. 4c, the opposite order is shown by adding a dash to the reference number in FIG. 4c).
[0043]
At the subscriber station 28, bootloading firmware is provided in the boot partition 104 to avoid the need to provide additional ROM or other non-volatile storage packages at the subscriber station 28. However, as will be apparent to those skilled in the art, if such a ROM or other non-volatile storage package is provided at the subscriber station 28 at the memory device 78 or elsewhere, the boot partition. 104 may be located there and removed from the RSU 86 and the RSU 86 is configured as two partitions 108 and 112. The term “memory subsystem” refers to either the memory device 78 and, if the boot partition 104 is stored in a ROM or another non-volatile storage package, the ROM or another non-volatile storage package. Is also included.
[0044]
Core firmware necessary to provide at least the minimum functionality to the subscriber station 28 is first written to the core firmware partition 108. The core firmware is responsible for providing basic operation of the subscriber station 28. These basic operations include memory management, task handling, file, I / O, etc. management (although not necessarily sufficient to provide some end-user service) by the subscriber station 28 as a base station And at least a minimum number of functions necessary to enable communication with 24. At the subscriber station 28, the operating system included in the core firmware includes Linux kernel version 2.4, and the boot loading software in the boot partition 104 is a Linux boot loader. The core firmware in partition 108 is a crams file system, which is a read-only compressed file system that is well known to those skilled in the art. The crafs file system documentation is readily available (see, eg, http://sourceforge.net/projects/crams/), and its operation is not further described here.
[0045]
At startup, when the boot partition is read and begins executing the contents of that partition, the boot loader reads sequentially from the starting point of the RSU 86 to search for the starting block and size of the core firmware partition 108 To start. The boot loader does this by locating the superblock defined in the crams file system. If one block is found, it is considered to be a compressed Linux kernel superblock in the core firmware partition 108. The boot loader then uses the information stored in the super block to decompress the kernel image into the RAM 82 and uses the starting block and size of the core firmware partition 108 as a boot parameter when the operating system starts. Can be forwarded to the kernel, thereby determining the partitioning of the RSU.
[0046]
Although Linux is currently preferred, other operating systems and operating system versions are within the scope of the present invention. The location of the core firmware partition 108 within the RSU 86 is not particularly limited, and after the boot partition 104 (if present) as a boot loader searches the contents of the RSU 86, a valid starting point for the core firmware partition 108, That is, any continuous series of logical block addresses may be occupied until the crams superblock is searched. However, as will become apparent from the following description, in order to avoid the situation where one or more memory blocks are not present in either the core firmware partition 108 or the auxiliary software partition 112, the core firmware partition 108 It is preferably located immediately after partition 104 or in the last part of RSU 86.
[0047]
The remaining software and data are stored in the auxiliary software partition 112 of the RSU 86. Hereinafter, this software is referred to as auxiliary software. Auxiliary software is not particularly limited and includes optional device drivers, user applications, system software applications, data files, software and end user applications such as telephone call processing software, voice and audio codecs, software filters, firewalls , Utilities, help files, subscriber data files, digital media files, and other application and data files as would occur to those skilled in the art.
[0048]
The auxiliary software may be stored in a compressed file system format, such as the crafs format described above, or may be stored in any other suitable form that would be conceivable by those skilled in the art. If the auxiliary software is monolithic, i.e. if software changes and updates require replacing the entire contents of the partition, crafs or similar file / storage system is preferred instead. It may be a thing. Alternatively, if the auxiliary software is not monolithic and therefore software components can be loaded and / or unloaded in the partition as needed, Axis Communications AB, Emdalavagen 14, S-223 69, Lund A suitable system such as JFFS (Journaling Flash File System) developed by Sweden may be used.
[0049]
In general, the auxiliary software stored in the auxiliary software partition 112 is not necessary for the subscriber station 28 to communicate with the base station 24, but the auxiliary software stored in the auxiliary software partition 112. Software is required to enable the subscriber station 28 to send and receive voice calls, make end user data connections (such as http browser sessions), or perform other end user functions. It may be. The location of the auxiliary software partition 112 within the RSU 86 is not particularly limited and may occupy a logically contiguous series of blocks, but preferably as described above, the block of the last part of the RSU 86. Exists or immediately after the boot partition 104.
[0050]
As shown in FIG. 4 a, the core firmware partition 108 is smaller in size than the auxiliary software partition 112. However, if the number of blocks available for partitioning as core firmware partition 108 and auxiliary software partition 112 is an even number, the partitions may be the same size. In this embodiment of subscriber station 28, the total storage space available at RSU 86 is 8 Mbytes, boot partition 104 is 256 Kbytes, and core firmware partition 108 has a maximum size of 3.75 Mbytes. The auxiliary software partition 112 has a maximum size of (7.75 Mbytes—the size of the core firmware partition 108). In the particular embodiment described here, the maximum size of the auxiliary software block is 4 Mbytes.
[0051]
In this embodiment, since the total number of memory blocks in RSU 86 is an even number and one block is used for boot partition 104, an odd number of blocks are used as core firmware partition 108 and auxiliary software partition 112. Available for partitioning, therefore, the core firmware partition 108 and the auxiliary software partition 112 may not be equal in size. As will become apparent from the description below, an important constraint is that the core firmware partition 108 must not be larger than the auxiliary software partition 112. Thereby, in any case, core firmware updates can be written to the auxiliary software partition 112 without overwriting the existing core firmware partition 108. This is readily apparent from the following description.
[0052]
If it is desired to update the core firmware in the core firmware partition 108, the updated core firmware is transferred from the update server 36 to the subscriber station 28 via the communication link 32, as will be described in more detail below. The core firmware is received and stored in the RAM 82 in the subscriber station 28 until all transfer of the updated core firmware and auxiliary software to the subscriber station 28 is complete, It is also conceivable to install the update core firmware before transferring and transferring auxiliary software. Depending on the size of the update and the size of the RAM 82, any process that requires a large amount of RAM 82 running on the subscriber station 28 may have to be terminated. As explained below, the ability to terminate such a process is one of the status criteria that is considered before deciding to update the subscriber station 28.
[0053]
It is conceivable that various techniques can be used to transfer the core firmware and auxiliary software from the update server 36 to the subscriber station 28, such as sending the software in packets via UDP / IP or TCP / IP. Since the communication link 32 or physical medium (wired connection, etc.) used to transfer the software can be affected by failures or errors, the correctness of the received transfer software is used. Inspected before. The particular method used to verify this validity is not particularly limited and, as will be apparent to those skilled in the art, checksums, CRCs, digital signatures, etc. are included in all or part of the transfer. May be used. If the received content is not correct and contains one or more errors, the software or an appropriate portion thereof will update the update server until a complete correct copy is received at the subscriber station 28. 36 to the subscriber station 28.
[0054]
Once a complete correct copy of the update / replacement core firmware has been received at the subscriber station 28 and stored in the RAM 82, ie the “new” core firmware, the update process has been previously occupied by the auxiliary software partition 112. Processing continues by writing new core firmware to all or part of the RSU 86. In order to perform this overwriting, any remaining process that was running at the subscriber station 28 and that requires read access to the auxiliary software residing in the auxiliary software partition 112. Although there are those remaining processes, they are terminated. When these processes (if any) are terminated, new core firmware is copied from RAM 82 and written to RSU 86. The new core firmware is shown in FIG. 4b as a new core firmware partition 108 ′. As used herein, the terms “overwrite” and “overwritten” are meant to provide the operations necessary to place new data in non-volatile memory for replacement with old data. Yes, in the case of flash memory, this involves first erasing the memory (if such a step is necessary) before writing new data to the flash memory.
[0055]
Also, in order to reduce the memory required in the RAM 82, if the received update can be verified that it was properly received before writing, the updated core firmware will In addition, it is conceivable that data may be written in a certain amount, for example, in units of 256 Kbyte update blocks. In such a case, when a given amount of update data is received at subscriber station 28, the update data is temporarily stored in RAM 82 and examined and written to RSU 86, and The next update received will overwrite previously received updates temporarily stored in RAM 82. Thus, the various applications and processes saved from RAM 82 do not necessarily have to be terminated during the update process, as will be described below, at least until subscriber station 28 is rebooted.
[0056]
As shown in FIG. 4 b, the overwrite is initiated at an offset from the start point of the auxiliary software partition 112 that is determined such that the end point of the new core firmware partition 108 ′ matches the end point of the auxiliary software partition 112. . In the example described above, the RSU 86 has a total size of 8 Mbytes, the boot partition 104 size is 0.25 Mbytes, the auxiliary software partition 112 size is 4 Mbytes, and the core firmware partition 108 is 3 Mbytes. If .75 Mbytes, the offset at which the new core firmware partition 108 ′ is overwritten on the auxiliary software partition 112 is 4. 25 Mbytes.
[0057]
After the new core firmware partition 108 'has been written, its contents are examined by the subscriber station 28, which in turn reads the contents from the new core firmware partition 108' and stores the contents in the RAM 82. Compare with a copy of the new core firmware in If received, if a new core firmware partition 108 ′ is written to a smaller part from RAM 82, those parts received before the next received part overwrites the last part temporarily stored in RAM 82. The smaller portion of the write is compared with that stored in RAM 82.
[0058]
In either case, if the content read from the new core firmware partition 108 'cannot be verified to be correct, writing the new core firmware partition 108' or writing the relevant part of the new core firmware partition 108 ' Again, the inspection / rewriting process is repeated until it is executed and the contents are confirmed to be correct.
[0059]
If it is determined that the contents of the new core firmware partition 108 ′ have been written correctly, the new core firmware partition 108 ′ is considered by the subscriber station 28 to contain the latest core firmware and the core firmware partition 108 The original core firmware present within is marked "invalid" to prevent the subscriber station 28 from executing. In the subscriber station 28 where the core firmware partitions 108 and 108 'include a crafs format Linux kernel or the like, the original core firmware present in the core firmware partition 108 will superimpose the core firmware partition 108 superblock to which it is no longer valid. It is considered invalid by overwriting it to change to something that is not a block. Once this is done, the next time the subscriber station 28 reboots, the boot loader will only search for the superblock of the new core firmware partition 108 ', which is the newest valid core firmware partition, and the subscriber station 28 will Will boot from '.
[0060]
As is apparent from FIG. 4b, the above results in an invalid core firmware partition 108 and, if any, the rest of the auxiliary software partition 112 that no longer contains valid data. The subscriber station 28 then writes the auxiliary software from the RAM 82 (or downloads the auxiliary software from the update server 36 to the RAM 82 (if it is not already running), as shown in FIG. The auxiliary software partition 112 ′ can be formed in the memory space of the core firmware partition 108 and the remaining portion of the auxiliary software partition 112 (if any). Alternatively, the subscriber station 28 may be rebooted to execute the new core firmware, and the auxiliary software may be downloaded from the update server and stored in the new auxiliary software partition 112 ′. Once it is confirmed that the new auxiliary software has been written correctly in a manner similar to that described above for the core firmware, the subscriber station 28 can execute the auxiliary software (subscriber station 28). (If it has already been rebooted and is running new core firmware), or the updated core firmware in the new core firmware partition 108 'is booted into the loader and both by the core firmware and auxiliary software It may be rebooted to restart all services provided. In doing so, the operating system searches for the superblock of the new core firmware partition 108 ′ and the superblock of the new auxiliary software partition 112 ′ (if crams is used for the auxiliary software partition) and finds the repartitioned RSU 86. Form the data structure to represent.
[0061]
As is apparent from the above, during the update process, the subscriber station 28 may be powered off, power unstable, requires a reboot, or otherwise interrupted by the core firmware. A valid copy of is always present in RSU 86. If the update process has already begun by overwriting the new core firmware partition 108 ′ with the auxiliary software partition 112, the subscriber station 28 power supply is written before the writing of the new core firmware partition 108 ′ is completed and confirmed. When the power is turned off, the subscriber station 28 will boot from the still intact old core firmware partition 108 the next time it is powered on again. It can be seen that there is no valid auxiliary software partition 112 and either the entire update process is restarted or a transfer of valid auxiliary software is requested to the update server 36 and the RSU 86 is restored as a restored auxiliary software partition 112. And the update process is postponed later. This latter option is selected when the network 20 is used in an overloaded state and capacity for performing updates cannot be easily obtained.
[0062]
If the update is successful, whenever the core firmware in the subscriber station 28 is to be updated again, the new core firmware partition 108 overwrites a portion of the auxiliary software partition 112 'and the new auxiliary software partition 112 , Overwriting the rest of the old core firmware partition 108 'and old auxiliary software partition 112', again resulting in the configuration shown in FIG. 4a. Note that it is not absolutely necessary to erase the superblock of the old core firmware partition 108 ′ after the new core firmware partition 108 has been verified to be correct. This is because if the update is interrupted at that stage, when a reboot occurs, the boot loader searches and uses the contents of the new core firmware partition 108 before reaching the old core firmware partition 108 '. .
[0063]
With each subsequent update of the core firmware, the new core firmware partition will be overwritten on the existing auxiliary software partition, and the new auxiliary software partition will be overwritten on the old core firmware partition and the rest of the auxiliary software partition become.
[0064]
As used herein, the term “new auxiliary software” refers to the unaltered software that has not been changed to the auxiliary software and the new auxiliary software has been downloaded to the subscriber station 28. It is noted that it is intended to include both simply meaning a new copy and when an updated or otherwise modified version of the auxiliary software is downloaded to the subscriber station 28. I want.
[0065]
As shown in FIG. 5a, the “old” core firmware partition 108 was copied and copied onto the “old” auxiliary software partition 112, unless you want to change the location of the partitions 108 and 112 in the normal operating RSU 86 An old core firmware partition 108 "may be formed, and if this copied old core firmware partition 108" is examined and verified to be correct, the original core firmware partition 108 changes it. Is considered invalid by overwriting its superblock to do so, or by some other suitable means. At this point, if the subscriber station 28 is rebooted for any reason, the boot loader searches and uses the contents of the copied core firmware partition 108 ".
[0066]
Next, as shown in FIG. 5b, the “new” core firmware is overwritten from the RAM 82 to the original core firmware partition 108 and examined. The new core firmware superblock that replaces the original core firmware partition 108 is not written to the original core firmware partition 108 until the contents of the rest of the core firmware partition 108 are examined, after which Blocks are written and verified. The copied core firmware partition 108 "is then deemed invalid by overwriting or changing its superblock or by some other suitable means. Thus, the new core firmware Reboots or other events that must load the core firmware prior to verifying the writing of the partition 108 use the copied core firmware partition 108 ″ instead of the new core firmware partition 108.
[0067]
Finally, new auxiliary software is copied from RAM 82, as shown in FIG. 5c, to form auxiliary software partition 112, which is checked before it is used, and subscriber station 28 once again returns its normal The operation configuration is as follows. This process results in partitions 108 and 112 that always have the same location in the RSU 86, but extra write operations performed to copy the contents of the core firmware partition 108 to the copied core firmware partition 108 "and A confirmation operation is required, which increases the time required to perform the update and may exhaust the RSU 86 earlier if the RSU 86 is flash memory.
[0068]
In this embodiment of the invention, updating software at the subscriber station 28 is a managed process. This is especially important in critical networks or “always-on-service continuity” networks such as wireless local loops that replace major telephone lines. FIG. 6 illustrates a network operations center (NOC) 200, a radio sector manager 204 for each sector in the base station 24 of the network 20, and a subscriber station update for each subscriber station served by the network 20. 2 shows a management system hierarchy of a network 20 including a client 208.
[0069]
The network operations center 200 is a centralized facility operated by an operator of the network 20 and performs other network management functions such as OAM & P in addition to managing updating subscriber stations throughout the network 20. You can also The wireless sector manager 204 is preferably located at each base station 24 of the network 20 and may be located at the same location as the update server 36 or may be implemented within the update server 36. If the base station 24 is an omnidirectional (single sector) base station, only one radio sector manager 204 is provided in that base station. More generally, the base station 24 may use a directional (beamforming) antenna, which allows the base station 24 to serve more subscriber stations 28. Can do. For example, if a 60 ° beamforming antenna is used, the base station 24 can be configured as six different radio sectors, each sector being a total subscriber served by that base station 24. A service is provided to a part of the station 28. In such a case, six radio sector managers 204 are provided to the base station 24. Finally, each subscriber station 28 includes an update client 208 as part of its core firmware, and the update client 208 operates at the subscriber station 28.
[0070]
The NOC 200 can serve hundreds of wireless sector managers 204, and through those wireless sector managers 204, through their update clients 208 to thousands or more subscriber stations 28. Since a service can be provided, in FIG. 6, the wireless sector manager 204, shown in dashed lines, is intended to represent a plurality of such wireless sector managers 204 and their associated update clients.
[0071]
If an update to the auxiliary software or core firmware of the subscriber station 28 is generated and the operator of the network 20 wishes to perform the update, the network operations center 200 will provide each subscriber served by the network 20. Determine the current version of the software loaded in station 28. As will be apparent to those skilled in the art, this determination may be made in a variety of ways. In an embodiment of the present invention, each time a subscriber station 28 is powered on and / or after an update is made, the update client 208 of each subscriber station 28 will have its subscriber station 28. The current version of the software loaded in the subscriber station 28 is reported to the wireless sector manager 204 serving the The wireless sector manager 204 forwards this information to the network operations center 200, where the information is stored in an appropriate database. As will be apparent to those skilled in the art, various other techniques are used to determine the current software load for each subscriber station 28, including polling the update client 208 at appropriate intervals. be able to.
[0072]
The current software load of each subscriber station in the network 20, or some subscriber stations 28 of interest in the network 20 (eg, the network operator is only interested in updating subscriber stations in a particular city). Once the current software load (which may not be present) is determined, the network operations center 200 determines the subscriber station 28 to be updated. In most environments, it is desirable to update all the subscriber stations 28 in the network 20, but it is possible to update some selected subscriber stations 28 or to update individual subscriber stations 28. Even this may be considered desirable.
[0073]
The network operations center 200 ensures that the updated desired software is available at one or more update servers 36 serving the wireless sector manager 204 with the subscriber station 28 to be updated, If necessary, the updated software is transferred to the update server 36. The network operations center 200 then informs the wireless sector managers 204 with the subscriber stations 28 to be updated of the IDs of those subscriber stations 28 and informs those wireless sector managers 204 to begin the update. Instruct.
[0074]
When the wireless sector manager 204 receives an update instruction from the network operations center 200, the wireless sector manager 204 determines the level and / or status of the activity of the subscriber station 28 that it manages to be updated. Ideally, an update is an end user where the capacity that the update requires on the communication link 32 is not otherwise required, and / or where the subscriber station 28 must be interrupted for the update process. It is implemented only when the process is not running. Accordingly, the wireless sector manager 204 first determines whether there is room and / or capacity in the communication link 32 to send the update. Typically, such updates may be performed at midnight or early morning when the communication link 32 is not heavily utilized by the end user. However, critical updates such as those required to stabilize the operation of the network 20 or provide improved security etc. are also assigned a high update priority by the network operator center 200. The network operator center 200 may instruct the wireless sector manager 204 to perform the update as soon as possible, terminate or suspend use of the capacity of the communication link 32 for others, and / Or interrupts end user activity at the subscriber station 28 to be updated, degrades service, or puts it on hold.
[0075]
If the wireless sector manager 204 determines that the communication link 32 has a capacity for the wireless sector manager 204 to send updates to the subscriber station 28, or a high priority update with the wireless sector manager 204 ensuring capacity. , The wireless sector manager 204 queries the update client 208 at each subscriber station 28 to be updated to determine the status of those subscriber stations 28. This status informs the level and / or type of activity currently being performed at the subscriber station 28.
[0076]
For example, the subscriber station 28 is idle for 10 minutes (no end user activity) or it is currently running an http session for the end user, etc. May be notified. The download of the update to be transferred is typically first stored in RAM 82, so the amount of selected memory required to store the download (this amount is for all updates). If a predetermined amount or may be provided by the wireless sector manager 204 in a status query to its update client 208), the subscriber station 28 Include this information in its status report to the wireless sector manager 204. Alternatively, the update client 208 at the subscriber station 23 may determine whether a process and / or application using the RAM memory 82 can be terminated to free up memory space, and If so, do so before sending the status response to the wireless sector manager 204.
[0077]
The wireless sector manager 204 reviews the status responses received from each subscriber station 28 to be updated and determines which subscriber stations 28 may be included in the update at this time. Then, the update client 208 of each of those subscriber stations 28 receives the update information transmitted from the wireless sector manager 204, and the update information indicates that those subscriber stations 28 will be updated. It notifies the station 28 and indicates the channel of the communication link 32 to which updates are transmitted.
[0078]
The wireless sector manager 204 then starts multicasting updates from the update server 36 to the subscriber stations 28 that have been notified to process the updates. In an embodiment of the invention, the update is sent by UDP over IP as a multicast transmission, and each packet sent is checked with a CRC checksum to verify that it was received correctly, and Contains a sequence number or other unique identifier, so that each subscriber station 28 can determine whether it has received all the required packets correctly. If one or more packets are received by the subscriber station 28 in an erroneous or totally lost state, such subscriber station 28 may request a retransmission while the transmission of the packet is in progress. It may be transmitted to the wireless sector manager 204 and the requested packet may be retransmitted. Preferably, this retransmission is valid for all subscriber stations 28 that are implemented and updated via the multicast channel (if more than one subscriber station 28 requires retransmission of the same packet). Also, such retransmissions may be made to one subscriber station 28 for that purpose via the dedicated channel of the communication link 32 established with the subscriber station 28 by the radio sector manager 204. Good thing is considered.
[0079]
In an embodiment of the invention, once the entire update has been downloaded and verified, the update client at the subscriber station must determine when to perform the RSU 86 update. Since the update requires a reboot (restart) of the subscriber station 28, the update client 208 selects a time zone for the update so that there will be minimal, if any, disruption of service to the end user. Try to do. Again, it is conceivable that such updates are typically performed at midnight or early morning, or at some other time when the user is unlikely to use the subscriber station 28.
[0080]
However, when the update client 208 at the subscriber station 28 also performs the update by determining what end user activity is occurring and / or the time since the last end user activity. You may intelligently decide on. For example, a subscriber station 28 that last made an end user voice connection or data connection more than 20 minutes ago may reasonably assume that it will not be used by the end user for the next few minutes during which the update takes place. it can.
[0081]
Again, some updates may also be important to the operation of the network 20 enough to cause those updates to be assigned a high priority, which high priority will be updated. To ensure that the update client 208 terminates end user activity at the subscriber station.
[0082]
If the update client 208 determines that an update can be performed, the process described above is performed, and the auxiliary software partition 112 is overwritten, such as a new firmware partition 108 'or a copied partition 108.
[0083]
When the update is successfully performed, the subscriber station 28 reboots the new core firmware and / or auxiliary software, and the new core firmware and / or auxiliary software is executed, an update status message is sent to the wireless sector manager 204. To confirm that the update has been completed and to confirm the version number of the software executed by the subscriber station 28. The wireless sector manager 204 then updates its records for the updated subscriber stations 28 and subscriber stations 28 that are still requesting updates.
[0084]
The radio sector manager 20 then repeats the process by repeating one or more times for the remaining subscriber stations 28 to be updated. It is also conceivable that the update will not start until it becomes possible to update a preselected proportion of subscriber stations 28 to be updated in the wireless sector. For example, as long as at least 50% of the subscriber stations 28 to be updated in a sector of the wireless sector manager 204 can be updated, the wireless sector manager 204 may be selected not to initiate an update. If this threshold is not reached, until this threshold is met or the network operations center lowers this threshold (eg to 35%) or raises the priority of the update Will postpone the update until the subscriber station 28 is forced to perform the update.
[0085]
The network operation center 200 is notified of the update status by the wireless sector manager 204. Thus, the network operations center 200 can determine the number of updated subscriber stations 28 and the number of remaining subscriber stations 28 to be updated. If the network operations center 200 finds that updates are being performed for fewer subscriber stations 28 than desired, the network operations center 200 will force those subscriber stations 28 to prepare for updates, etc. In order to avoid this, high priority may be applied to the update.
[0086]
In most environments, core firmware updates and supplemental software updates are considered to be sent as one update, but in some environments, the core firmware update is sent first and the subscriber station 28 It may be desirable to send an auxiliary software update after successfully installing the update. Depending on the environment, it may be desirable to update only the auxiliary software. In such a case, the core firmware is not updated and the updated auxiliary software is overwritten on the existing software partition 112.
[0087]
FIG. 7 shows a flowchart of the update process described above. If the network operations center 200 wants to update a device present in the network 20, in step 300, the device on which the update is to be installed is determined. In step 304, the update is forwarded to one or more update servers 36, otherwise made available by those update servers 36 from which the update is to be updated on the device to be updated. Forwarded to
[0088]
In step 308, each wireless sector manager 204 determines which of the devices it is serving can be updated. In step 312, the wireless sector manager 204 notifies them that their devices are being updated and provides details of the update communication, such as multicast parameters.
[0089]
In step 316, the update is transferred to the device to be updated. Each target device confirms whether or not the transmitted update has been correctly received when transmission is completed or during transmission, and in step 320, the erroneous part of transmission is received or transmitted. The device that could not receive a part of the information notifies the wireless sector manager 204 of this, and the wireless sector manager 204 retransmits those parts.
[0090]
In step 324, if the device receives a correct copy of the update, the device determines an appropriate time to perform the update. As described above, this determination may be a trivial issue (ie, perform an update regardless of the device status), or may be made in response to the device status. The state includes factors such as the current process being executed on the device, the time since the end user process was executed, and so on.
[0091]
When the device update and reboot is complete, in step 328 the device notifies the radio sector manager 204 that manages it that it has been updated and provides details of its current software load. Also good.
[0092]
In step 332, each wireless sector manager 204 determines whether there are any devices it manages that have not yet been updated. If there is still such a device, steps 308 to 328 are executed again as necessary. If there are no more such devices, the update process is completed at step 336.
[0093]
It will be appreciated that the several embodiments described herein are intended to describe specific embodiments of the invention, and that combinations, portions and variations of this embodiment are within the scope of the invention.
[0094]
The above-described embodiments of the present invention have been described by way of example of the present invention, and those skilled in the art will recognize that without departing from the scope of the present invention, which is defined only by the claims appended hereto. Variations and changes can be made.
[Brief description of the drawings]
[0095]
FIG. 1 is a block diagram of a network that enables an electronic device upgrade in an embodiment of the present invention.
FIG. 2 is a block diagram of an update station in the embodiment of the present invention.
FIG. 3 is a block diagram of an updatable electronic device including a memory device according to an embodiment of the present invention.
4A is a block diagram of a memory device according to an embodiment of the present invention in the electronic device shown in FIG.
4B is a block diagram of the memory device according to the embodiment of the present invention in the electronic device shown in FIG. 3. FIG.
4c is a block diagram of a memory device according to an embodiment of the present invention in the electronic device shown in FIG.
5a is a block diagram of a memory device according to another embodiment of the present invention in the electronic device shown in FIG.
5b is a block diagram of a memory device according to another embodiment of the present invention in the electronic device shown in FIG. 3. FIG.
5c is a block diagram of a memory device according to another embodiment of the present invention in the electronic device shown in FIG. 3. FIG.
FIG. 6 is a block diagram of a hierarchy of an update system according to an embodiment of the present invention.
FIG. 7 is a flowchart illustrating an embodiment of an update process according to the present invention.

Claims (28)

A method of updating software in multiple remote devices,
Each of the remote devices has a non-volatile rewritable storage capacity that is insufficient to store both an updated version of the software and a previous version of the software;
Each of the remote devices is connected to a network;
(1) placing an update including at least a core firmware update on an update server;
(2) identifying a device to be updated connected to the network;
(3) The update is transferred from the update server to the identified device via the network, and each of the identified devices checks that the update has been received correctly, and updates the received update. If there is an erroneous part, requesting retransmission of the part and receiving the part; and
(4) writing the core firmware portion of the received update to a non-volatile rewritable storage device so as not to overwrite a previous version of the core firmware present in the storage device;
(5) examining the core firmware portion of the received update written to the storage device;
(6) considering the inspected updated core firmware as valid core firmware to be used by the device, and considering the previous version of core firmware as unusable;
(7) rebooting the device to load and execute the updated software;
Including methods. Between step (3) and step (4), the previous version of the core firmware is copied onto the auxiliary software stored in the storage device, inspected, and the copy is used by the device The method of claim 1, wherein the method is considered to be valid core firmware and the original previous version of the core firmware is considered unusable. The update further includes an updated auxiliary software, the auxiliary software is received and inspected by the device, and the auxiliary software update is not available between step (6) and step (7). The method of claim 2, overwritten on a previous version of core firmware. The update further includes an updated auxiliary software, the auxiliary software is received and inspected by the device, and the auxiliary software update is not available between step (6) and step (7). The method of claim 1, overwritten on a previous version of core firmware. The method according to any one of claims 1 to 4, wherein step (2) further comprises the device notifying the network whether the device is ready to be updated. A system for remotely updating a core firmware present in at least one electronic device via a communication link,
A memory subsystem residing in the at least one electronic device;
An update server,
With
The memory subsystem includes a non-volatile rewritable memory in which the core firmware is stored,
The non-volatile rewritable memory is large enough to store auxiliary software, but not large enough to store the core firmware, an updated version of the core firmware, and the auxiliary software simultaneously,
The core firmware includes instructions,
The instruction does not overwrite the previous version of the core firmware, writes the updated version of the core firmware to the non-volatile rewritable memory, and prevents the use of the previous version of the core firmware.
As a result of the instruction, when the at least one electronic device is rebooted, the updated version of the core firmware is loaded and executed,
The update server can be used to transfer an update comprising the updated version of core firmware to the at least one electronic device via a communication link;
system. The core firmware includes instructions,
The instruction overwrites at least a portion of the previous version of the core firmware that has been disabled, but does not overwrite the updated version of the core firmware, so that the updated version of the auxiliary software Write to non-volatile rewritable memory,
The system according to claim 6. The memory subsystem further comprises a non-volatile memory containing instructions;
The instruction is executed when the electronic device reboots, scans the non-volatile rewritable memory for a version of the core firmware that is not disabled, and loads the version of the core firmware. ,Execute,
The system according to claim 7. A system for remotely updating core firmware and auxiliary software residing in at least one electronic device via a communication link,
A memory device residing in the at least one electronic device for storing the core firmware and the auxiliary software;
An update server,
With
The memory device is
The first memory content including the core firmware is stored in the first partition, and is small enough to be stored in the first partition, and the second memory content including the auxiliary software is stored in the first memory. A non-volatile rewritable memory for storing in a second partition large enough to store the contents;
A non-volatile memory storing a boot loading instruction to be executed when the electronic device is rebooted;
Including
The core firmware includes an update client,
When the updated client receives the updated version of the first memory content, the updated client writes the updated version of the first memory content to the second partition, overwriting the second memory content; When the first memory content included in the first partition is made unusable and an updated version of the second memory content is received, the updated version of the second memory content is transferred to the first partition. To the first memory content that has been disabled, reboot the electronic device,
The bootloading instruction comprises an instruction;
When executed, the instruction searches the non-volatile rewritable memory to obtain a version of the first memory content that is not disabled, and finds the version of the first memory content. For example, the control of the electronic device is switched to the core firmware stored in the memory content of the version,
The update server can be used to transfer an update with the updated versions of the first and second memory contents to the at least one electronic device via the communication link;
system. A system for remotely updating core firmware and auxiliary software residing in at least one electronic device via a communication link,
A memory device residing in the at least one electronic device for storing the core firmware and the auxiliary software;
An update server,
With
The memory device is
A first memory content including the core firmware is stored in a first partition and is small enough to be stored in the first partition, and a second memory content including the auxiliary software is stored in the first partition. A non-volatile rewritable memory for storing in a second partition large enough to store the memory contents;
A non-volatile memory that stores a bootloading instruction that is executed when the electronic device is rebooted;
Including
The core firmware includes an update client;
When the update client receives the updated version of the first memory content, the update client copies the first memory content to the second partition, overwrites the second memory content, and updates the updated memory content. Writing a version of the first memory content to the first partition, overwriting the first memory content, and receiving an updated version of the second memory content, the updated version of the second memory content; Write the memory contents to the second partition, reboot the electronic device,
The bootloading instruction includes an instruction;
When executed, the instruction searches the non-volatile rewritable memory to obtain a version of the first memory content that is not disabled, and finds the version of the first memory content. For example, the control of the electronic device is switched to the core firmware stored in the memory content of the version,
The update server can be used to transfer an update with the updated versions of the first and second memory contents to the at least one electronic device over the communication link;
system. A system for remotely updating core firmware and auxiliary software residing in at least one electronic device via a communication link,
A memory device residing in the at least one electronic device for storing the core firmware and the auxiliary software;
An update server,
With
The memory device includes:
The first memory content including the core firmware is stored in the first partition and is small enough to be stored in the first partition, and the second memory content including the auxiliary software is changed to the first memory content. A non-volatile rewritable memory that stores in a second partition large enough to store
A non-volatile memory storing a boot loading instruction to be executed when the electronic device is rebooted;
Including
The core firmware includes an update client,
When the update client receives the updated version of the first memory contents, it reduces the size of the second partition, if possible, and the reduction causes the second partition to be updated. The first memory content of the version is just large enough to be stored, the updated version of the first memory content is written to the second partition, overwriting the previous content of the second partition, and Making the version of the first memory content stored in the first partition unusable and receiving the updated version of the second memory content increases the size of the first partition, if possible. Non-volatile write not included in the second partition Write the updated version of the second memory contents to the first partition, including all portions of the available memory, overwrite the previous contents of the first partition, and reboot the electronic device ,
The bootloading instruction includes an instruction;
When executed, the instruction searches the non-volatile rewritable memory to obtain a version of the first memory content that is not disabled, and finds the version of the first memory content. For example, the control of the electronic device is switched to the core firmware stored in the memory content of the version,
The update server can be used to transfer an update with the updated versions of the first and second memory contents to the at least one electronic device via the communication link;
system. 12. A system according to any one of claims 6 to 11, wherein the writing to the non-volatile rewritable memory is checked for correctness. The update client can be used to notify the update server whether the at least one electronic device can be updated at a given time, the update server received from the update client 13. The system of claim 12, wherein in response to the information, if the electronic device is not ready to be updated, the update of the electronic device is postponed. 14. The system of claim 13, wherein the update server can prioritize updates and the update client is ready to update electronic devices that cannot be updated without prioritization. A memory subsystem for use in electronic equipment,
Non-volatile rewritable memory that stores core firmware and auxiliary software,
The core firmware includes instructions;
The instruction writes an updated version of the core firmware to the non-volatile rewritable memory, overwriting at least a portion of the auxiliary software, but not over a previous version of the core firmware. The updated version of the core firmware is loaded and executed when the electronic device is rebooted by examining the previous version of the core firmware and disabling the previous version of the core firmware.
Memory subsystem. A memory subsystem for use in electronic equipment,
The memory subsystem comprises a non-volatile rewritable memory;
The nonvolatile rewritable memory stores core firmware,
The non-volatile rewritable memory is large enough to store the core firmware and auxiliary software, but large enough to store the core firmware, an updated version of the core firmware, and the auxiliary software simultaneously Not
The core firmware includes instructions;
The instructions write the updated version of the core firmware to the non-volatile rewritable memory, check the updated version of the core firmware, and not overwrite the previous version of the core firmware. By making the version of the core firmware unavailable, the updated version of the core firmware is loaded and executed when the electronic device is rebooted.
Memory subsystem. The core firmware includes instructions;
The instruction overwrites at least a portion of a previous version of the core firmware that has been disabled, but does not overwrite the updated version of the core firmware, so that an updated version of the auxiliary software is transferred to the non-volatile memory. Write to rewritable memory,
17. A memory subsystem according to claim 15 or claim 16. Further comprising a non-volatile memory containing instructions;
The instructions are executed when the electronic device reboots and scan the non-volatile rewritable memory to obtain an unusable version of the core firmware. Load and run a version of the core firmware,
The memory subsystem of claim 17. A memory subsystem for storing instructions for use in an electronic device capable of executing stored instructions and receiving an updated version of the instructions, comprising:
The memory subsystem comprises a non-volatile rewritable memory;
The non-volatile rewritable memory allows the electronic device to restart, or continues to update the non-volatile rewritable memory if the electronic device reboots while an update is in progress A first memory content including at least instructions necessary to enable the storage to be stored in the first partition;
A second memory content that is small enough to be stored in the first partition and that includes all instructions required for normal operation after reboot of the electronic device that is not included in the first memory content is the first memory content. Stored in a second partition large enough to store the memory contents of
The instruction stored in the first memory content is:
When executed after an updated version of the first memory content is received, the updated version of the first memory content is written to a second partition, overwriting the second memory content; An instruction to disable the use of the first memory content contained in the first partition;
When executed after an updated version of the second memory content is received, the updated version of the second memory content is written to the first partition to prevent the use of the first memory content. An instruction to overwrite the memory contents and reboot the electronic device;
Including
The memory subsystem further comprises a non-volatile memory storing a bootloading instruction to be executed when the electronic device is rebooted;
The bootloading instruction comprises an instruction;
When executed, the instruction searches the non-volatile rewritable memory to obtain a version of the first memory content that is not disabled, and if the first memory content of the version is found Switching control of the electronic device to instructions stored in the memory contents of that version;
Memory subsystem. A memory subsystem for storing instructions for use in an electronic device capable of executing stored instructions and receiving an updated version of the instructions, comprising:
The memory subsystem comprises a non-volatile rewritable memory;
In the nonvolatile rewritable memory,
Necessary to allow the electronic device to restart or continue to update the non-volatile rewritable memory if the electronic device reboots while an update is in progress A first memory content including at least an instruction is stored in the first partition;
A second memory content that includes all the instructions required for normal operation after rebooting the electronic device that is not included in the first memory content is sufficiently large to store the first memory content. Stored in the partition,
The instruction stored in the first memory content is:
When executed after receiving an updated version of the first memory content, the first memory content is copied to a second partition, overwriting the second memory content, and the updated version An instruction to write the first memory contents of the first memory contents to the first partition and overwrite the first memory contents;
When executed after an updated version of the second memory content is received, the updated version of the second memory content is written to the second partition to prevent the use of the first memory content. An instruction to overwrite the memory contents and reboot the electronic device;
Including
The memory subsystem further comprises a non-volatile memory storing a bootloading instruction to be executed when the electronic device is rebooted;
The bootloading instruction comprises an instruction;
When executed, the instruction searches the non-volatile rewritable memory to obtain a version of the first memory content that is not disabled, and if the first memory content of the version is found Switching control of the electronic device to instructions stored in the memory contents of that version;
Memory subsystem. A memory subsystem for storing instructions for use in an electronic device capable of executing stored instructions and receiving an updated version of the instructions, comprising:
The memory subsystem comprises a non-volatile rewritable memory;
In the nonvolatile rewritable memory,
Necessary to allow the electronic device to restart or continue to update the non-volatile rewritable memory if the electronic device reboots while an update is in progress First memory content including at least an instruction is stored in a continuous first partition starting from a start point of the nonvolatile rewritable memory or ending at an end point of the nonvolatile rewritable memory;
The second memory content including all instructions necessary for normal operation after rebooting the electronic device not included in the first memory content does not exist in the first partition of the nonvolatile rewritable memory. Occupying a portion and stored in a contiguous second partition large enough to store the first memory contents;
The instruction stored in the first memory content is:
When executed after an updated version of the first memory content is received, the second partition may be updated to the updated version by reducing the size of the second partition, if possible. The first memory content of the second partition is just large enough to be stored, the updated version of the first memory content is written to the second partition, overwriting the previous content of the second partition, and An instruction that disables the use of a version of the first memory content stored in one partition;
When executed after receiving an updated version of the second memory content, if possible, the first partition can be increased in size and non-volatile rewritable not included in the second partition An instruction to write the updated version of the second memory content, including all portions of memory, to the first partition, overwrite the previous contents of the first partition, and reboot the electronic device; ,
Including
The memory subsystem further comprises a non-volatile memory storing a bootloading instruction to be executed when the electronic device is rebooted;
The bootloading instruction comprises an instruction;
When executed, the instruction searches the non-volatile rewritable memory to obtain a version of the first memory content that is not disabled, and if the first memory content of the version is found Switching the control of the electronic device to the instruction stored in the memory content of the version,
Memory subsystem. A method of updating core firmware stored in a nonvolatile rewritable memory of an electronic device to an updated version of core firmware together with auxiliary software,
(1) overwriting at least a portion of the auxiliary software, but not overwriting a previous version of the core firmware, and writing the updated version of the core firmware into the non-volatile rewritable memory;
(2) the rebooted version of the core firmware is loaded and executed when the electronic device is rebooted by disabling the previous version of the core firmware;
With a method. A method of updating a previous version of core firmware and auxiliary software stored in non-volatile rewritable memory of an electronic device to an updated version of core firmware and auxiliary software, comprising:
(1) overwriting at least a portion of the auxiliary software, but not overwriting a previous version of the core firmware, and writing the updated version of the core firmware into the non-volatile rewritable memory;
(2) when the electronic device is rebooted by disabling the previous version of the core firmware, the updated version of the core firmware is loaded and executed;
(3) writing the updated version of the auxiliary software into the nonvolatile rewritable memory without overwriting the updated version of the core firmware;
With a method. When the electronic device is rebooted, the non-volatile rewritable memory is scanned and the version of the core firmware is loaded and executed to obtain a version of the core firmware that is not disabled. 24. A method according to claim 22 or claim 23. A method of installing the update into the software stored in non-volatile rewritable memory that is not large enough to hold both the update and the software, comprising:
Dividing the update into individually writable parts including a core part that can be stored in less than half of the non-volatile rewritable memory; and
A non-volatile rewritable memory having a core portion including an area less than half of the non-volatile rewritable memory, corresponding to the core portion of the update and an auxiliary portion having a size that can hold the core portion of the update. Including, dividing into individually rewritable parts including software parts;
Writing the core part of the update to the auxiliary part of the non-volatile rewritable memory and checking whether the core part of the update has been written correctly;
Disabling previous versions of software contained in the core portion of the non-volatile rewritable memory;
The update part not included in the core part of the update is written in the nonvolatile rewritable memory part not included in the core part of the nonvolatile rewritable memory, and the update part is correctly written. A step of inspecting
With a method. A system for remotely updating at least one electronic device via a communication link, comprising:
An update server that can be used to transfer updates comprising core firmware and auxiliary software to the at least one electronic device via the communication link;
Volatile memory for temporarily storing transfers received from the update server;
A non-volatile rewritable storage device existing in the at least one electronic device, wherein the non-volatile rewritable storage device is divided into at least a first and a second partition, and the first partition is one of a version of core firmware and auxiliary software. A non-volatile rewritable storage device storing the other of a version of core firmware and auxiliary software;
An update client running on the device;
With
The update client is
(1) Overwrite the received update core firmware stored in the volatile memory with a version of auxiliary software stored in one of the first and second partitions, and check whether the writing was successful;
(2) The next time the device is rebooted, the device is set to execute the core firmware stored in step (1),
(3) Whether the received updated auxiliary software stored in the volatile memory is overwritten with a version of the core firmware stored in the other of the first and second partitions, and whether the writing was successful Inspect the
(4) Reboot the device and execute the updated core firmware and the updated auxiliary software;
system. The update client further informs the update server whether the device can be updated at a given time;
The update server responds to the information received from the update client and defers the update of the device if the device is not ready to update.
27. The system of claim 26. 28. The update server according to claim 27, wherein the update server can prioritize updates, and the prioritization enables the update client to update electronic devices that cannot be updated without prioritization. The described system.

Images