Broadcast remote firmware update

Patent metadata

Field	Value
Publication number	US-11082294-B2
Application number	US-201715677138-A
Country	US
Kind code	B2
Filing date	Aug 15, 2017
Priority date	Aug 15, 2017
Publication date	Aug 3, 2021
Grant date	Aug 3, 2021

Abstract

A method of broadcasting firmware updating messages in a communication system includes the steps of receiving a broadcast remote firmware update (BRFU) setup message from an upstream source, the BRFU setup message specifying a number of transmissions of a broadcast of a firmware file; broadcasting setup information from the BRFU setup message on a first channel to downstream devices, the setup information specifying at least one other channel to which each downstream device should listen to receive a copy of the firmware file; and repeatedly broadcasting the firmware file to the downstream devices in accordance with the BRFU setup message.

First claim

That which is claimed is:

1. A method of managing firmware update communications between devices in a communication system, comprising the steps of:
retrieving, at an upstream source, a copy of a firmware file from a file storage source, wherein the upstream source is selected from one of a server and a network management tool;
sending the copy of the firmware file from the upstream source to at least one transmitting device selected from a hub, a collector, and a repeater;
receiving input of a predetermined number of times that the copy of the firmware file is to be repeatedly broadcasted by the at least one transmitting device to comprise one broadcast remote firmware update (BRFU);
receiving input of a predefined limit of BRFUs to be executed within a session;
sending a BRFU setup message from the upstream source to the at least one transmitting device, the BRFU setup message specifying a wake time at which downstream devices targeted by the BRFU setup message should wake from a sleeping state to receive the copy of the firmware file, such devices comprising targeted downstream devices, and specifying a channel to which each targeted downstream device should tune after waking;
following completion of a BRFU, quantifying a number of unsuccessful downstream devices, the unsuccessful downstream devices comprising targeted downstream devices that did not successfully store an entire copy of the firmware file;
determining whether the number of unsuccessful downstream devices falls below a predetermined threshold;
responsive to a determination that the number of unsuccessful downstream devices falls below the predetermined threshold, conducting a directed firmware update addressed to each unsuccessful downstream device, comprising the steps of
sending a direct setup message directly from the upstream source over a hailing channel to each unsuccessful downstream device, the direct setup message specifying a next wake time at which each unsuccessful downstream device should wake to again receive the copy of the firmware file and specifying a data channel to which each unsuccessful downstream device should tune after waking at the next wake time, and
causing the at least one transmitting device to perform one of broadcasting the copy of the firmware file to each unsuccessful downstream device and sending the copy of the firmware file over the data channel to each unsuccessful downstream device;

responsive to a determination that the number of unsuccessful downstream devices does not fall below the predetermined threshold, determining whether the predefined limit of BRFUs has been reached;
responsive to a determination that the predefined limit of BRFUs has not been reached, initiating another BRFU by sending another BRFU setup message to the at least one transmitting device; and
responsive to a determination that the predefined limit of BRFUs has been reached,
sending a broadcast burn command to the at least one transmitting device, and
receiving firmware information from the transmitting device, the firmware information identifying all targeted downstream devices that burned the firmware file into respective memories located in the targeted downstream devices, such downstream devices comprising successful downstream devices, and specifying a version of firmware running on the successful downstream devices.

2. The method of claim 1 , wherein the upstream source comprises one of a server and a network management tool, wherein the server communicates with a database containing the firmware file, and wherein the network management tool comprises a computer application that communicates with a cloud containing the firmware file.

3. The method of claim 1 , wherein the BRFU setup message further contains a file handling instruction, the file handling instruction directing the transmitting device to refrain from broadcasting the copy of the firmware file to the targeted downstream devices while storing the copy of the firmware file in a memory of the transmitting device itself.

4. The method of claim 1 , wherein the step of quantifying the number of unsuccessful downstream devices comprises the steps of:
receiving, at the upstream source, a BRFU status message from the at least one transmitting device;
analyzing, at the upstream source, information in the BRFU status message received from the transmitting device.

5. The method of claim 4 , wherein the step of receiving, at the upstream source, the BRFU status message from the at least one transmitting device comprises the steps of:
sending a force upload message from the upstream source to the transmitting device; and
waiting for a delay period to receive the BRFU status message in response to the force upload message.

6. The method of claim 4 , wherein the BRFU status message contains one or more of a copy of a message requesting the BRFU status message, a session identification, completion status, a number of free blocks of external memory in the targeted downstream device, and a number of times that the same firmware file has been sent or received.

7. The method of claim 6 , wherein the completion status comprises a numeric value in a message field indicating whether the targeted downstream device has a good and complete copy of the firmware file in its external memory.

8. The method of claim 1 , further comprising the steps of:
analyzing, at the upstream source, the firmware information to determine whether a count of successful downstream devices is less than a count of all targeted downstream devices; and
responsive to a determination that the count of successful downstream devices is less than the count of all targeted downstream devices, repeating the step of sending a broadcast burn command to the at least one transmitting device.

9. The method of claim 1 , wherein the sending of the copy of the firmware file to each unsuccessful downstream device commences after a delay following the next wake time specified in the direct setup message.

10. The method of claim 1 , wherein the broadcasting of the copy of the firmware file to each unsuccessful downstream device occurs over a non-frequency-hopping channel.

11. The method of claim 1 , wherein the sending of the copy of the firmware file to each unsuccessful downstream device comprises directly sending a “store and forward” command over a frequency-hopping channel individually via a hail message to each unsuccessful downstream device.

12. The method of claim 1 , wherein the BRFU setup message includes an auto-burn command, and further comprising the step of, responsive to a determination that the predefined limit of BRFUs has been reached, ending the session.

13. The method of claim 1 , wherein the BRFU setup message further includes a session identification, the session identification corresponding to a firmware version of the copy of the firmware file.

14. The method of claim 1 , further comprising the steps of:
sending a broadcast burn command to the at least one transmitting device;
receiving firmware information from the at least one transmitting device, the firmware information identifying all targeted downstream devices that burned the firmware file into respective memories located in the targeted downstream devices, such downstream devices comprising successful downstream devices, and specifying a version of firmware running on the successful downstream devices;
analyzing the firmware information to determine whether a count of successful downstream devices is less than a count of targeted downstream devices; and
responsive to a determination that the count of successful downstream devices is less than the count

Assignees

• Mueller Int Llc

Inventors

• Magley Dale Mcleod
• Splitz David Edwin
• Caron Gregory
• Dukes Brent

Classifications

• H04L67/146

  Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding · CPC title

• G06F8/654

  using techniques specially adapted for alterable solid state memories, e.g. for EEPROM or flash memories · CPC title

• H04L43/10

  Active monitoring, e.g. heartbeat, ping or trace-route · CPC title

• H04L67/34

  involving the movement of software or configuration parameters  (network booting or remote initial program loading [RIPL] G06F9/4416) · CPC title

• H04L41/082 Primary

  the condition being updates or upgrades of network functionality · CPC title