Method and system for facilitating multiple communication techniques using single chip radio

Abstract

A method and system are provided for dynamically updating firmware of a single protocol-based single chip radio device existing in an Internet of Things (IoT) environment with multiple technologies using an intelligent firmware update based on a size of flash memory, one or more hardware resources available at a controller level, and a current IoT context associated with the IoT environment. The method comprises the following steps: receiving a firmware updating data packet; determining a size of a flash memory of a single protocol and one or more hardware resources of a controller level based on the received firmware update packet; associating the received firmware update data packet with the size of the flash memory; dynamically selecting one or more firmware resources from the received firmware data packet based on the association to update firmware of the single protocol based single chip radio device; and updating firmware of the single protocol-based one-chip radio device using the one or more firmware resources.

Description

Technical Field

[0001] The present disclosure relates to wireless communication technologies. More specifically, the present disclosure relates to enabling multiple wireless communication technologies to be used in a device using a single-chip radio. Background Art

[0002] In an Internet of Things (IoT) environment, there may be devices operating different protocols for communication. In an example herein, the IoT environment may include a first device communicating using Bluetooth and a second device communicating using Thread, where a hub device may communicate with the first device and the second device using a single-chip radio with their respective communication protocols. However, if a third device with ZigBee (not equipped in the hub device) joins the IoT environment, the hub device cannot communicate with the third device without upgrading the single-chip radio.

[0003] Currently, multiple technologies operate on a single combined chipset with different radios. However, there are no methods and systems for using a single-chip radio to facilitate multiple communication technologies. This results in waste of resources (such as waste of hardware resources, etc.) and increased costs due to different radios. In addition, existing methods and systems cannot migrate existing market devices to use new technologies. In an example, an existing IoT hub cannot be upgraded to support Thread technology to support upcoming technologies.

[0004] Current solutions enable multiple IoT protocols to operate on a single chip by using software modules, but do not disclose how to dynamically update the firmware with multiple technologies for devices currently used in the IoT environment. There are solutions that require distributing physical storage devices to users, which may require significant manufacturing, marketing, and distribution efforts and costs.

[0005] The above information is presented as background information only to assist in understanding the present disclosure. It is not determined nor asserted that any of the above is available as prior art with respect to the present disclosure. Summary of the Invention

[0006] Aspects of the present disclosure are to at least address the above problems and / or disadvantages, and at least provide the following advantages. Accordingly, one aspect of the present disclosure is to provide a method and system for dynamically updating the firmware of a single-protocol single-chip radio device existing in an IoT environment with multiple technologies using intelligent firmware updates based on the size of the flash memory, one or more hardware resources available at the controller level, and the current IoT context related to the Internet of Things (IoT) environment.

[0007] Additional aspects will be set forth in part in the following description, and in part will be obvious from the following description, or may be learned by practice of the presented embodiments. Solution to the problem

[0008] According to one aspect of the present disclosure, there is provided a method for dynamically updating the firmware of a single-protocol single-chip radio device present in an IoT environment. The method includes: receiving a firmware update data packet, wherein the firmware update data packet includes one or more firmware resources associated with one or more connection protocols; based on receiving the firmware update data packet, determining the size of the flash memory of the single-protocol single-chip radio device and one or more hardware resources at the controller level; associating the received firmware update data packet with the size of the flash memory, one or more hardware resources available at the controller level, and the current IoT context associated with the IoT environment; based on the association, dynamically selecting one or more firmware resources from the received firmware data packet to update the firmware of the single-protocol single-chip radio device; and using the dynamically selected one or more firmware resources to update the firmware of the single-protocol single-chip radio device.

[0009] The dynamic selection of one or more firmware resources is based on at least one of the following: hardware / radio availability, use of devices in the IoT environment, location and behavior of devices in the IoT environment, geographical location of the single-protocol single-chip radio device, application load on the single-protocol single-chip radio device, firmware resources, priority of devices in the IoT environment, user preferences, or user selection.

[0010] The method further includes: using a network coprocessor (NCP) to create space for the firmware update data packet to a radio coprocessor (RCP).

[0011] The method further includes: backing up one or more devices connected to the single-protocol single-chip radio device.

[0012] Updating the single-protocol single-chip radio device using multiple protocols further includes: using the backup to restore the connection of one or more devices previously connected to the single-protocol single-chip radio device before the update.

[0013] The method further includes: discarding one or more firmware resources from the selected one or more firmware resources based on a failure to update the firmware of the single-protocol single-chip radio device.

[0014] One or more connection protocols include at least one of Zigbee, Thread, or Bluetooth Low Energy (BLE).

[0015] One or more hardware resources include a radio, a channel range, and a network coprocessor / radio coprocessor (NCP / RCP) at the controller level of a single-chip radio device based on a single protocol.

[0016] The method further includes: flashing one or more selected firmware resources into a flash memory.

[0017] The one or more selected firmware resources are first resource information. The method further includes: recalculating one or more blocks present in a firmware update data packet based on detecting a flash failure; obtaining second resource information by discarding one or more firmware resources from the one or more selected firmware resources; flashing the second resource information back into the flash memory; and updating the firmware of the single-chip radio device based on the single protocol using the second resource information.

[0018] According to another aspect of the present disclosure, there is provided a single-chip radio device based on a single protocol present in an IoT environment. The single-chip radio device based on the single protocol includes: a memory; a firmware control module coupled to the memory; and one or more processors configured to be electrically connected to the firmware control module and the memory. The memory stores one or more computer programs including computer-executable instructions that, when executed by the one or more processors, cause the single-chip radio device based on the single protocol to: receive a firmware update data packet, wherein the firmware update data packet includes one or more firmware resources associated with one or more connection protocols; based on receiving the firmware update data packet, determine the size of the flash memory of the single-chip radio device based on the single protocol and one or more hardware resources at the controller level; associate the received firmware update data packet with the size of the flash memory, one or more hardware resources available at the controller level, and a current IoT context associated with the IoT environment; based on the association, dynamically select one or more firmware resources from the received firmware data packet to update the firmware of the single-chip radio device based on the single protocol; and update the firmware of the single-chip radio device based on the single protocol using the dynamically selected one or more firmware resources.

[0019] The one or more computer programs further include computer-executable instructions that, when executed by the one or more processors, cause the single-chip radio device based on the single protocol to dynamically select one or more firmware resources based on at least one of the following: hardware / radio availability, usage of the device in the IoT environment, location and behavior of the device in the IoT environment, geographical location of the single-chip radio device based on the single protocol, application load on the single-chip radio device based on the single protocol, firmware resources, priority of the device in the IoT environment, user preferences, or user selection.

[0020] One or more computer programs further include computer-executable instructions that, when executed by one or more processors, cause a single-chip radio device based on a single protocol to use a network coprocessor (NCP) to create space for a firmware update data packet for a radio coprocessor (RCP).

[0021] One or more computer programs further include computer-executable instructions that, when executed by one or more processors, cause a single-chip radio device based on a single protocol to back up one or more devices connected to the single-chip radio device based on a single protocol.

[0022] One or more computer programs further include computer-executable instructions that, when executed by one or more processors, cause a single-chip radio device based on a single protocol to restore connections to one or more devices that were previously connected to the single-chip radio device based on a single protocol prior to an update.

[0023] One or more non-transitory computer-readable storage media are provided that store computer-executable instructions that, when executed by one or more processors of a single-chip radio device based on a single protocol, cause the single-chip radio device based on a single protocol to perform operations. The operations include: receiving a firmware update data packet, where the firmware update data packet includes one or more firmware resources associated with one or more connection protocols; based on receiving the firmware update data packet, determining the size of a flash memory and one or more hardware resources at a controller level of the single-chip radio device based on a single protocol; associating the received firmware update data packet with the size of the flash memory, one or more hardware resources available at the controller level, and a current IoT context associated with an IoT environment; based on the association, dynamically selecting one or more firmware resources from the received firmware data packet to update the firmware of the single-chip radio device based on a single protocol; and updating the firmware of the single-chip radio device based on a single protocol using the dynamically selected one or more firmware resources.

[0024] A detailed description of various embodiments of the present disclosure is disclosed in conjunction with the following drawings, and other aspects, advantages, and significant features of the present disclosure will become apparent to those skilled in the art. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] In accordance with the following description with reference to the drawings, the above and other aspects, features, and advantages of some embodiments of the present disclosure will become more apparent, in which:

[0026] Figure 1 Devices including a firmware controller for dynamically updating the firmware of a device in accordance with embodiments of the present disclosure are described;

[0027] Figure 2 Describes a main firmware data packet according to an embodiment of the present disclosure;

[0028] Figure 3 Describes an association engine for determining a firmware update data packet of a device according to an embodiment of the present disclosure;

[0029] Figure 4 Describes a scenario in which a coprocessor daemon (CPCD) processes information in a device according to an embodiment of the present disclosure;

[0030] Figure 5A Describes an implementation of a radio coprocessor (RCP) module and related modules and layers according to an embodiment of the present disclosure;

[0031] Figure 5B Describes an implementation of an RCP module and related modules and layers according to an embodiment of the present disclosure;

[0032] Figure 5C Describes an implementation of an RCP module and related modules and layers according to an embodiment of the present disclosure;

[0033] Figure 6A Shows a flowchart depicting a process for dynamically updating the firmware of a single - protocol, single - chip radio device present in an Internet of Things (IoT) environment according to an embodiment of the present disclosure;

[0034] Figure 6B Shows a flowchart depicting a process for dynamically updating the firmware of a single - protocol, single - chip radio device present in an Internet of Things (IoT) environment according to an embodiment of the present disclosure; and

[0035] Figure 7 Describes a device configured with ZigBee and Thread according to an embodiment of the present disclosure.

[0036] It should be noted that throughout the drawings, like reference numerals are used to describe the same or similar elements, features, and structures. Detailed Description

[0037] The following description with reference to the accompanying drawings is provided to assist in a comprehensive understanding of various embodiments of the present disclosure defined by the claims and their equivalents. The following description includes various specific details to aid understanding, but these specific details should be regarded as merely exemplary. Thus, those of ordinary skill in the art will recognize that various changes and modifications can be made to the various embodiments described herein without departing from the scope and spirit of the present disclosure. Additionally, descriptions of known functions and structures may be omitted for clarity and conciseness.

[0038] The terms and words used in the following description and claims are not limited to their literal meanings, but are used solely by the inventors to achieve a clear and consistent understanding of the present disclosure. Thus, it should be clear to those skilled in the art that the following descriptions of the various embodiments of the present disclosure are for illustrative purposes only and are not intended to limit the present disclosure as defined by the appended claims and their equivalents.

[0039] It should be understood that, unless the context clearly indicates otherwise, the singular forms "a" and "the" include plural referents. Thus, for example, a reference to "a component surface" includes a reference to one or more such surfaces.

[0040] To explain this specification, definitions (as defined herein) will be applied, and where appropriate, terms used in the singular will also include the plural and vice versa. It should be understood that the terms used herein are for the purpose of describing particular embodiments only and are not intended to be limiting. Unless otherwise stated, the terms "comprising", "having", and "including" should be construed as open-ended terms.

[0041] The words / phrases "exemplary", "example", "illustrative", "in an instance", "etc.", "for example", "i.e." are used herein solely to mean "serving as an example, instance, or illustration". Embodiments or implementations of the subject matter described using the words / phrases "exemplary", "example", "illustrative", "in an instance", "etc.", "for example", "i.e." are not necessarily to be construed as preferred or advantageous over other embodiments.

[0042] Embodiments herein may be described and illustrated in terms of blocks that perform one or more of the described functions. These blocks (which may be referred to herein as managers, units, modules, hardware components, etc.) are physically implemented by analog and / or digital circuitry (e.g., logic gates, integrated circuits, microprocessors, microcontrollers, memory circuits, passive electronic components, active electronic components, optical components, hardwired circuits, etc.) and may optionally be driven by firmware. The circuitry may be embodied, for example, in one or more semiconductor chips or on a substrate support such as a printed circuit board. The circuitry constituting the blocks may be implemented by dedicated hardware or by a processor (e.g., one or more programmed microprocessors and associated circuitry), or by a combination of dedicated hardware for performing some of the functions of the block and a processor for performing other functions of the block. Without departing from the scope of the present disclosure, each block of an embodiment may be physically divided into two or more interacting and discrete blocks. Similarly, without departing from the scope of the present disclosure, the blocks of an embodiment may be physically combined into more complex blocks.

[0043] It should be noted that the elements in the drawings are shown for the purpose of this specification and for ease of understanding, and may not necessarily be drawn to scale. For example, a flowchart / sequence diagram shows a method in terms of steps required to understand aspects of the embodiments disclosed herein. Additionally, in terms of the construction of a device, one or more components of the device may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details relevant to understanding the embodiments so as not to obscure the drawings with details that would be apparent to a person of ordinary skill in the art from the description herein. Additionally, in terms of a system, one or more components / modules that make up the system may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details relevant to understanding the embodiments so as not to obscure the drawings with details that would be apparent to a person of ordinary skill in the art from the description herein.

[0044] The drawings are used to assist in the easy understanding of various technical features, and it should be understood that the embodiments presented herein are not limited by the drawings. Thus, the present disclosure should be construed to extend to any modifications, equivalents, and alternatives, except those specifically set forth in the drawings and the corresponding description. The use of words such as first, second, third, etc. to describe components / elements / steps is for purposes of description and should not be construed as ordering / placing / occurring sequentially unless otherwise stated.

[0045] Embodiments herein implement methods and systems for using intelligent firmware updates to dynamically update the firmware of single-protocol single-chip radio devices present in an Internet of Things (IoT) environment with multiple technologies. Now referring to the drawings, and more specifically to Figures 1 to 4 , Figures 5A to 5C , Figure 6A , Figure 6B and Figure 7 , in which embodiments are shown, and like reference numerals throughout these Figure 1 consistently denote corresponding features.

[0046] Embodiments herein disclose methods and systems for using intelligent firmware updates to dynamically update the firmware of single-protocol single-chip radio devices present in an IoT environment with multiple technologies based on the size of the flash memory, one or more hardware resources available at the controller level, and the current IoT context associated with the IoT environment. The device referred to herein can be any device present in the IoT environment that is capable of communicating with one or more other devices using multiple communication technologies. In an example scenario, assume that a user previously purchased a smart home hub device and there is a new technology available (not present in the hub device). Embodiments herein will enable the user to upgrade the existing hub device without adding additional hardware chips.

[0047] Embodiments of the present invention disclose a method for dynamically updating the firmware of a single-protocol based single-chip radio device (e.g., a smart home hub) present in an IoT environment. The method includes receiving a firmware update data packet by a single-protocol based single-chip radio device, wherein the update data packet includes one or more firmware resources associated with one or more connection protocols (e.g., Zigbee, Thread, Bluetooth Low Energy (BLE), Wi-Fi, Wireless Local Area Network (WLAN) (Lite), Z-wave, Ultra Wideband (UWB), etc.). In response to receiving the firmware update data packet, the method further determines the size of the flash memory of the single-protocol based single-chip radio device and one or more hardware resources available at the controller level (e.g., but not limited to radio, channel range, network coprocessor / radio coprocessor (NCP / RCP)). The method also associates the received firmware update data packet with the size of the flash memory, one or more hardware resources available at the controller level, and the current IoT context associated with the IoT environment; and dynamically selects one or more firmware resources from the received firmware update data packet based on the association to update the firmware of the single-protocol based single-chip radio device.

[0048] Embodiments herein may dynamically update (flash) a single-chip radio device based on a single protocol using multiple protocols, wherein the updated firmware includes one or more selected firmware resources, and the one or more selected firmware resources are selected based on a current user context.

[0049] Firmware resources may relate to a set of rules for communication between one or more devices. Firmware resources may include components required to implement and execute a specific protocol.

[0050] Firmware resources may include the code, libraries, configuration, and data required to implement and execute a specific protocol.

[0051] The firmware resource may include at least one of a read-only memory (ROM) size, signature information, a channel number, a boot loader, or a priority.

[0052] Embodiments herein may also restore connectivity to one or more devices that were previously connected to the single-protocol based single-chip radio device prior to the update.

[0053] Based on the associations between technologies available on other devices at a location, embodiments herein may dynamically decide whether to support technologies for supporting distributed hardware present in that location.

[0054] Embodiments herein may use the terms "technology" and "protocol" interchangeably to refer to communication technologies that devices (as described herein) may use to communicate.

[0055] The central device described in this document can be a device and / or application that can be connected to one or more other devices present in an IoT environment. The central device can communicate with one or more other devices present in the IoT environment and / or control one or more other devices present in the IoT environment.

[0056] It should be understood that each block in the flowcharts and combinations of flowcharts can be executed by one or more computer programs including computer-executable instructions. One or more computer programs can be stored entirely in a single memory, or one or more computer programs can be divided into different parts stored in multiple different memories.

[0057] Any function or operation described in this document can be processed by one processor or a combination of processors. One processor or a combination of processors is a circuit that performs processing and includes, for example, an application processor (AP, such as a central processing unit (CPU)), a communication processor (CP, such as a modem), a graphics processing unit (GPU), a neural processing unit (NPU) (such as an artificial intelligence (AI) chip), a Wi-Fi chip, a Bluetooth TM chip, a global positioning system (GPS) chip, a near field communication (NFC) chip, a connection chip, a sensor controller, a touch controller, a fingerprint sensor controller, a display driver integrated circuit (IC), an audio codec (CODEC) chip, a universal serial bus (USB) controller, a camera controller, an image processing IC, a microprocessor unit (MPU), a system on a chip (SoC), an IC, and other circuits.

[0058] Figure 1 A device including a firmware controller for dynamically updating the firmware of the device according to an embodiment of the present disclosure is described.

[0059] Referring to Figure 1 , the device 100 can be a single-protocol single-chip radio device present in an IoT environment. The IoT environment can be one of a consumer IoT environment or an industrial IoT. In the examples in this document, the consumer IoT environment can include one or more portable devices (such as smart phones, wearable devices, etc.). In the examples in this document, the consumer IoT environment can include one or more home devices (such as appliances, home automation systems, home monitoring systems, etc.). In the examples in this document, the industrial IoT environment can be a small industrial environment, which can include one or more heavy machines, transportation tools, smart cities, etc. In the examples in this document, the industrial IoT environment can be a large industrial environment, which can include one or more components / machines for automation, one or more components / machines for factories, one or more components / machines / devices for healthcare, etc.

[0060] The device 100 shown in the figure includes a firmware control module 101, multiple protocol daemons 102, a multiplexing / demultiplexing daemon 103, a flash memory 104, a memory 105, and an RCP module 106. In the embodiments herein, the RCP module 106 may be an 802.15.4 module (chip). In the embodiments herein, the RCP module 106 may be connected to a single antenna (Tx / Rx). The daemons 102, 103 may perform multiplexing and demultiplexing operations on the transmitted and received data respectively. The device 100 may be connected to a server 107, and the server 107 may be connected to the device 100 using a wireless communication protocol (such as but not limited to Wi-Fi, cellular, etc.).

[0061] The firmware control module 101 may be described as at least one of a processor or a controller.

[0062] The protocol daemon 102 corresponds to the software stack of the supported technology, such as the Zigbee daemon, Thread daemon, Bluetooth daemon, etc. for supporting the underlying technology. The multiplexing / demultiplexing module / daemon (referred to as the CPCD daemon herein) will perform serialization and re-serialization, and multiple communication technologies communicate through a single universal asynchronous receiver / transmitter (UART), as Figure 4 shown. The protocol daemon 102 may be a program that runs as a background process. The protocol daemon 102 may be awakened to process requests received from an external program / application / device or an internal program / application.

[0063] The server 107 may determine the communication protocols supported by the device 100 (i.e., the communication protocols supported by the RCP module 106). Examples of the communication protocols supported by the RCP module 106 may be (but not limited to) Zigbee, Thread, Bluetooth, BLE, LoRa, UWB, matter-compatible protocols / technologies, etc. This may involve the server 107 determining the metadata of each supported communication protocol, where the metadata includes at least one of (but not limited to) read-only memory (ROM) size, signature information, channel number, bootloader, priority, etc. Tables 1 and 2 are examples of describing the supported communication protocols and the corresponding metadata respectively. Table 1 Table 2

[0064] Server 107 may prepare a primary firmware image, where the primary firmware image includes firmware resources of a communication protocol and metadata. In the embodiments herein, the firmware resources may include metadata. In the embodiments herein, server 107 may store the primary firmware image in a suitable location (such as but not limited to a data server, server 107, cloud, etc.). In the embodiments herein, server 107 may transmit the primary firmware image to device 100.

[0065] Assume that firmware control module 101 receives a primary firmware data packet from server 107.

[0066] Figure 2 And Table 3 describes the content of a primary firmware data packet with multiple protocol connection resources according to an embodiment of the present disclosure.

[0067] Refer to Figure 2 And Table 3, the primary firmware data packet includes firmware for BLE, ZigBee, Thread, etc. Firmware control module 101 may store the received primary firmware data packet in a suitable location, such as storing it in memory 105. Table 3

[0068] Firmware control module 101 may determine the hardware resources present in and currently available in device 100. Firmware control module 101 may determine the hardware resources by obtaining the hardware resources from memory 105 and / or flash memory 104. Examples of the hardware resources may be but not limited to the size of flash memory 104, one or more hardware resources available at the controller level of device 100, the firmware (i.e., image) that has been currently flashed (i.e., present in flash memory 104), etc. Table 4 is an example table describing examples of one or more hardware resources available at the controller level of device 100. Table 5 is an example table describing the currently flashed firmware (i.e., Zigbee in the current example). Table 4 Table 5

[0069] Firmware control module 101 may further include an association engine 101A. The association engine 101A may determine the association between multiple factors, and by using the determined association, the association engine 101A may determine the firmware update data packet of device 100 (as Figure 3 shown).

[0070] Figure 3 Describes an association engine for determining a firmware update data packet of a device according to an embodiment of the present disclosure.

[0071] Reference Figure 3 ,multiple factors can include the received main frame image (as shown in the example of Table 3), the firmware image currently flashed on the flash memory 104 (as shown in the example of Table 5), the hardware resources available on the device 100 (as shown in the example of Table 4), the previous feedback status (as shown in the example of Table 6), the list of devices / accessories paired with the device 100 (as shown in the example of Table 7), dynamic distributed hardware, and the current context of the device 100 (such as but not limited to the location of the device 100 (at home / in the office / on the go / in a vehicle), etc.), device behavior, device resources, etc.). The determined firmware update data packet can include the firmware to be flashed into the flash memory 104 based on the multiple factors and one or more related resources. In the example herein, the determined firmware update data packet can include ZigBee, Thread, and multiple related resources.

[0072] In an example scenario, a home can have multiple centers; for example, Center 1, Center 2, and Center 3, and so on.

[0073] Center 1: (equipped with) Zigbee

[0074] Center 2: (equipped with) Zigbee, BLE

[0075] Center 3: (equipped with) Zigbee, BLE

[0076] Suppose the user purchases an additional new center (in the current example, a Thread-enabled television (TV)). Based on the capabilities of the existing nearby centers (i.e., Center 1, Center 2, and Center 3), the device 100 can perform dynamic updates using the Thread protocol so that the home environment can also support Thread technology.

[0077] Device behavior refers to the protocol used by the center at a specific time and / or location. In the example, assume that Center 1 will use ZigBee and Thread from 6 am to 10 pm, and Center 1 will use BLE + Thread for updates during the remaining time. Based on this behavior observation, the embodiments herein can determine which protocol needs to be supported at what time and location, and can update the firmware of the center accordingly.

[0078] In the example herein, the association engine 101A can receive inputs such as but not limited to the current location, the RSSI of the device, the link quality of the device, etc. Theoretically, any parameter can be an input to the association engine 101A.

[0079] In an example scenario, the association engine 101A can dynamically select firmware data packets based on available flash resources, the received main frame image, the current hub (i.e., the device to which device 100 is currently connected), and the protocols supported in the vicinity of device 100 (e.g., in a nearby room, inside a vehicle, in an office, etc.).

[0080] In an example scenario, the association engine 101A can dynamically select firmware data packets based on the load of the application computer processing unit (CPU).

[0081] In an example scenario, assume that device 100 is a portable hub. When the user is in the office / at home / on the go, etc., the association engine 101A can dynamically select firmware data packets based on the user's device.

[0082] In an example scenario, the association engine 101A can dynamically select firmware data packets based on the current time and change the behavior and distance between device 100 and the hub. Table 6 Table 7

[0083] The firmware control module 101 can further include a firmware update module 101B (as Figure 1 shown). The association engine 101A can provide the determined firmware update data packet to the firmware update module 101B. The firmware update module 101B can use the determined firmware update data packet to initiate flashing into the flash memory 104; that is, the firmware update module 101B can dynamically update device 100 using the firmware update data packet determined based on the association to support multiple protocols.

[0084] In an embodiment herein, the firmware update module 101B can back up the image currently flashed on the flash memory 104 to the memory 105 before initiating the flashing into the flash memory 104. In an embodiment herein, the firmware update module 101B can back up other devices connected to device 100 to the memory 105 before initiating the flashing into the flash memory 104.

[0085] In an example herein, the firmware update module 101B can flash the determined firmware update data packet into the flash memory 104, and the determined firmware update data packet can include ZigBee, Thread, and multiple resources. The process of flashing into the flash memory 104 can include the firmware update module 101B using the network coprocessor (NCP) to create space for the firmware update data packet in the radio coprocessor (RCP).

[0086] After successfully flashing the flash memory 104, the firmware update module 101B can use the previously obtained backup from the memory 105 to restore the connections of other devices previously connected to the device 100.

[0087] Consider the scenario where the flashing process fails (possibly due to, for example, but not limited to, flash memory limitations, etc.). The firmware update module 101B can recalculate one or more blocks present in the firmware update data packet and / or discard one or more firmware resources from the selected one or more firmware resources, and attempt to flash the flash memory 104 again. When a firmware flashing failure is detected, the association engine 101A can prepare a new optimal firmware based on the previously determined firmware update data packet and the cause of the failure. In the embodiments herein, the firmware update module 101B can recalculate one or more blocks present in the firmware update data packet by discarding lower-priority blocks from the firmware update data packet.

[0088] Figure 4 A scenario of a coprocessor daemon (CPCD) processing information in a device according to an embodiment of the present disclosure is described.

[0089] Referring to Figure 4 , the CPCD 401 includes a multiplexing module 402, a demultiplexing module 403, and a channel selector module 404. The channel selector module 404 can select a specific channel based on a pool of supported channel lists, where the selected channel is a communication frequency band reserved for communication.

[0090] The multiplexing module 402 can be used on the Tx side, where the multiplexing module 402 can serialize various technologies based on time-division multiplexing (TDM). The multiplexing module 402 can include a message queue interface, where the message queue interface can implement synchronization between a fast transmitter and a slow remote receiver. This helps to queue data packets. Once the message queue is full, the multiplexing module 402 can provide a quality of service (QoS) indication to the corresponding application (such as, for example, but not limited to, ZigBee, Thread, BLE, etc.) to stop sending data packets.

[0091] The demultiplexing module 403 can be used on the Rx side for demultiplexing. The demultiplexing module 403 can decode the data packet based on the corresponding header. The demultiplexing module 403 can then transmit the decoded data packet to the corresponding application stack (for example, but not limited to ZigBee, Thread, BLE, etc.). The demultiplexing module 403 may include a message queue interface, wherein the message queue interface can achieve synchronization between a fast transmitter and a slow remote receiver. This helps to queue the data packets. Once the message queue is full, the demultiplexing module 403 can provide a quality of service (QoS) indication to the corresponding application (for example, but not limited to ZigBee, Thread, BLE, etc.) to stop sending data packets.

[0092] Figure 5A , Figure 5B and Figure 5C Implementations of the RCP module and related modules and layers according to various embodiments of the present disclosure are described.

[0093] Reference Figure 5A , Figure 5B and Figure 5C , the RCP module 106 can use ZigBee and Thread on a single chip. Assume that the RCP module 106 is sending a message. The RCP module 106 can provide the message to be sent to the multiplexing module 402 / demultiplexing module 403 through the TTY interface. The multiplexing module 402 / demultiplexing module 403 can multiplex the message (i.e., CPC the message) and provide the message to the corresponding application. If the message is to be sent using ZigBee, the message is provided to the ZigBee network module and the NCP host, and the NCP host further transmits the message to the central device. If the message is to be sent using Thread, the message is provided to the Thread border router, and the Thread border router further transmits the message to the central device.

[0094] Assume that device 100 is receiving a message. The central device can receive the message. If the message is received via Thread, the central device can send the message to the Thread border router. The Thread border router routes the message to the multiplexing module 402 / demultiplexing module 403, which demultiplexes the message and provides the message to the RCP module 106. If the message is received via ZigBee, the central device can send the message to the ZigBee network module and the NCP host. The ZigBee network module routes the message to the multiplexing module 402 / demultiplexing module 403, which demultiplexes the message and provides the message to the RCP module 106.

[0095] Figure 6A andFigure 6B is a flowchart depicting a process for dynamically updating the firmware of a single - protocol, single - chip radio device present in an Internet of Things (IoT) environment in accordance with various embodiments of the present disclosure.

[0096] Referring Figure 6A and Figure 6B , in operation 601, device 100 receives a firmware update data packet from server 107. The firmware update data packet includes one or more firmware resources associated with one or more connection protocols. After receiving the firmware update data packet, in operation 602, device 100 determines the size of the flash memory of device 100 and one or more hardware resources at the controller level.

[0097] In operation 603, device 100 associates the received firmware update data packet with the size of the flash memory, one or more hardware resources available at the controller level, and the current IoT context associated with the IoT environment.

[0098] In operation 604, device 100 dynamically selects one or more firmware resources from the received firmware data packet to update the firmware of device 100 based on the association. Device 100 dynamically selects one or more firmware resources based on at least one of the following: hardware / radio availability, usage of the device in the IoT environment, location and behavior of the device in the IoT environment, geographical location of the single - protocol, single - chip radio device, application load on device 100, firmware resources, priority of the device in the IoT environment, user preferences, or user selection.

[0099] In operation 605, device 100 backs up the image currently flashed on flash memory 104 to memory 105, and backs up other device connection information (such as but not limited to the Extended Unique Identifier (EUI) (Media Access Control (MAC) address), configuration, etc.) relative to device 100 to memory 105.

[0100] In operation 606, device 100 uses a Network Co - Processor (NCP) to create space for the firmware update data packet to the Radio Co - Processor (RCP).

[0101] In operation 607, device 100 updates its firmware using one or more dynamically selected firmware resources and activates the updated firmware. If device 100 successfully updates the firmware in operation 608, then in operation 609, device 100 uses backup to restore the connections of one or more devices that were previously connected to device 100 before the update, and in operation 610, the device continues to operate using the updated firmware. If a failure occurs during firmware update in operation 608, then in operation 611, before attempting to flash the firmware again, device 100 discards one or more firmware resources from the selected one or more firmware resources and / or recalculates one or more blocks present in the firmware update data packet. The various actions in method 600 may be performed in the order shown, in a different order, or simultaneously. Additionally, in some embodiments of the present disclosure, some of the actions listed in Figure 6A and Figure 6B may be omitted.

[0102] In an example, assume the user has a mobile phone (i.e., device 100). Assume that at the user's home, the user can use the mobile phone to perform device-to-device (D2D) control of IoT devices using Zigbee / Thread, while outside the user's home, the user wants to listen to music via BLE. When it is determined that the user is at home, embodiments herein dynamically download Zigbee and Thread firmware to a single chip and switch the device to the IoT control mode. Additionally, when it is determined that the user is outside the home, embodiments herein dynamically download BLE firmware to a single chip and switch the device to the BLE mode for BLE audio streaming.

[0103] In an example scenario, assume device 100 is a device with Zigbee. Table 8 describes the available hardware resources in device 100. Table 8

[0104] The user of the device uses ZigBee for IoT indoors (as shown in Table 9) and uses UWB and BLE for tracking user activities outdoors (as shown in Table 10). Assume the user and their device are currently indoors; i.e., Table 9 is considered the current metadata. Table 9 Table 10

[0105] The manufacturer of device 100 pushes new firmware to device 100 (as shown in Tables 11 and 12). Device 100 downloads the firmware and stores the downloaded firmware in the memory. Table 11 Table 12

[0106] Device 100 obtains the current metadata (Table 9) and the hardware resources on the RCP module 106, and determines which technologies are supported by the hardware (Table 8). Device 100 can dynamically generate various use cases based on the user context (such as but not limited to the user's current location: indoor or outdoor). Device 100 can associate and determine which user inputs to accept for the technologies to be supported. Assume that the user has moved outdoors, where the user context can be as shown in Table 10. Accordingly, device 100 can prepare a firmware data packet containing BLE. Device 100 can back up sensor data (i.e., the devices that have been connected to device 100) in the form of a table (Table 13) for later recovery.

[0107] In an example use case, if the portable center is at home, the portable center can act as an IoT controller for Zigbee devices and Thread devices. If the portable center is outside the home and the user is carrying it, the portable center can act as a BT location tracker or a BLE audio streaming device. When the user arrives at the office, the portable center can act as a Zigbee-only controller center (based on the available Zigbee-only devices). Table 13

[0108] Device 100 can use the corresponding firmware to update the firmware on the RCP module 106. After successfully updating the firmware, device 100 can use the previously obtained backup (Table 13) to recover the connected devices.

[0109] In an example scenario, assume that device 100 is a central device. Table 14 shows the available hardware resources in device 100. Table 14

[0110] The manufacturer of device 100 pushes new firmware (as shown in Table 15 and Table 16) to device 100. Device 100 downloads the firmware and stores the downloaded firmware in the memory. Table 15 Table 16

[0111] Device 100 obtains the current metadata (Table 17) and the hardware resources on the RCP module 106, and determines which technologies are supported by the hardware (Table 14). Table 17

[0112] The cloud triggers device 100 to perform a firmware update for at least one technology (which can be done in the presence or absence of the technology); i.e., Thread in the current example. Device 100 can check the feasibility of supporting Thread based on an input or association from the cloud (which can be based on metadata (firmware and wireless transmission) and hardware resources). The metadata can be included in the firmware. Thus, device 100 can prepare firmware data packets including ZigBee and Thread (as shown in Table 18). Table 18

[0113] Device 100 can back up sensor data (i.e., devices that have been connected to device 100) in the form of a table (Table 19) for later restoration. Table 19

[0114] Device 100 can use the corresponding firmware (including ZigBee and Thread) to update the firmware on RCP module 106 (as Figure 7 shown). After successfully updating the firmware, device 100 can use the previously obtained backup (Table 19) to restore the connected devices.

[0115] Figure 7 A device configured with ZigBee and Thread according to an embodiment of the present disclosure is described.

[0116] Referring Figure 7 , in an example scenario, assume that a user purchases a television (TV) with a central function built in, and now there are three centers in the user's home, namely Center 1, Center 2, and Center 3 (i.e., the TV). If Center 1 and 2 support Zigbee and Wi-Fi matter respectively, then the firmware of the TV (recently added to the IoT environment) can be upgraded to support BLE and Thread (the other centers in the IoT environment did not support BLE and Thread previously). This enables all devices to connect to at least one center, as shown in Table 20, and the centers in the IoT environment do not have to support duplicate technologies at the same location. Table 20

[0117] In an example scenario, assume that the user has Center 1 and Center 2 in their living room, which support ZigBee, BLE, and Thread. Table 21 describes the connected devices, device types, the centers to which each device is connected, the corresponding distances from the centers, and their respective usage times. Table 21

[0118] It can be seen that specific devices are controlled by the same static center, regardless of the distance from the center. However, the distance between the center and the device (if farther) sometimes affects the operation of the device. Based on the daytime context, the embodiments herein can dynamically perform firmware updates and change protocol behavior. The distance between the device and the center can be used to ensure that the device is within range and located at the same position. For example, the motion sensor and the water pump are not used at night and are close to Center 1, the light bulb / air conditioner is only used at night and is close to Center 2, and the two centers are located at the same position (i.e., the living room). The embodiments herein can use the protocols used by Center 2 (i.e., ZigBee and Thread) to update Center 1. This can be done based on the usage time, device location, and behavior.

[0119] Continuing with this example, assume that Center 1 supports ZigBee and BLE during the day (6:00 am to 6:00 pm), while Center 2 is unavailable at night (6:00 pm to 6:00 am). Therefore, Center 1 is upgraded to ZigBee and Thread at night so that Center 1 can support the devices previously connected to Center 2. Table 22 shows the connections of the devices in the IoT environment at night. Table 22

[0120] In the example scenario, assume that Portable Device 1 (wireless charger) and Portable Device 2 (tablet computer) act as centers in the IoT environment. The user can use the portable devices as centers to control various devices at their home or in the office or on the go. These devices may have limited resources to support multiple protocols simultaneously. Therefore, when the user is at home, the user needs to control home IoT devices (e.g., Zigbee and Thread devices); thus, Device 1 is updated with Zigbee and Thread firmware. When the user is on the go, there are no IoT home devices to control; however, the user needs to stream BLE music and use tracking devices (e.g., tags) to track their assets. Therefore, the firmware of Device 1 is dynamically updated only with BLE. When the user is in the office, only Zigbee sensor devices exist. Therefore, the firmware of Device 1 is dynamically updated only with Zigbee.

[0121] In an example scenario, assume that the user is using a TV (as the center), where, during normal operation, for optimal resource utilization, the TV supports ZigBee and Thread. If the user wants to run Netflix that supports 8K content, the central function may stop working, or Netflix may not be able to run due to memory issues. In such a case, based on the application CPU load and available memory, embodiments of the present disclosure can optimize resources by upgrading the TV's firmware, thereby retaining support for ZigBee and removing Thread support.

[0122] During runtime, if device 100 observes coexistence issues between Wi-Fi 2.4GHz and BLE, using the embodiments disclosed herein, device 100 can temporarily update the firmware without BLE.

[0123] In an example scenario, assume that the BOM cost of a single 802.15.4 PHY radio is X dollars per device. If the device must support Zigbee, Thread, WLAN, BLE, four independent 802.15.4 PHY radios are required. Using the embodiments disclosed herein, all four technologies can be supported using a single radio. For example, if the four technologies are supported in a single chip, embodiments of the present disclosure can save approximately (X * (4 - 1)) dollars per device (i.e., approximately 75% savings).

[0124] Furthermore, if the device uses four independent radio PHYs, the power consumption will be higher. For example, one radio PHY requires 250 milliamperes, and four independent radio chips consume 1 ampere, while when using a single radio PHY, the power consumption remains at only approximately 250 milliamperes.

[0125] Multiple radio PHYs also require multiple antennas, which need to be arranged in a way that does not interfere with each other. In addition, coexistence circuitry is required to ensure that multiple radio chip sets do not simultaneously transmit data packets wirelessly to avoid air packet collisions (packet traffic arbitration), which does not occur in a device with a single radio PHY.

[0126] The embodiments disclosed herein can be implemented by at least one software program that runs on at least one hardware device and executes network management functions to control network elements. The elements shown in the figure include blocks, and the blocks can be at least one of a hardware device or a combination of a hardware device and software modules.

[0127] Embodiments disclosed herein describe methods and systems for dynamically updating the firmware of single - protocol single - chip radio devices present in an Internet of Things (IoT) environment with multiple technologies using intelligent firmware updates. Accordingly, it should be understood that the scope of protection extends to such programs, and in addition to the computer - readable means having messages therein, such computer - readable storage means also contains program code means for implementing one or more steps of the method when the program runs on a server or a mobile device or any suitable programmable device. The method is implemented, in at least one embodiment, by a software program written in, for example, Very High - Speed Integrated Circuit Hardware Description Language (VHDL) (another programming language) or in conjunction with such software program, or the method is implemented by one or more VHDL or multiple software modules executed on at least one hardware device. The hardware device can be any type of portable device capable of being programmed. The device may also include means that can be, for example, a hardware means (such as an Application - Specific Integrated Circuit (ASIC)), or a combination of hardware and software means (such as an ASIC and a Field - Programmable Gate Array (FPGA)), or at least one microprocessor and at least one memory having software modules therein. Method embodiments described herein may be implemented partly in hardware and partly in software. Alternatively, the present disclosure may be implemented on different hardware devices (e.g., using multiple CPUs).

[0128] Although the present disclosure has been shown and described with reference to various embodiments thereof, those skilled in the art will understand that various changes in form and detail may be made therein without departing from the spirit and scope of the present disclosure as defined by the appended claims and their equivalents.

Claims

1. A method for dynamically updating the firmware of a single - protocol single - chip radio device present in an Internet of Things (IoT) environment, the method comprising: Receiving a firmware update data packet, wherein the firmware update data packet includes one or more firmware resources associated with one or more connection protocols; Based on receiving the firmware update data packet, determining the size of the flash memory of the single - protocol single - chip radio device and one or more hardware resources at the controller level; Associating the received firmware update data packet with the size of the flash memory, the one or more hardware resources available at the controller level, and the current IoT context associated with the IoT environment; Based on the association, dynamically selecting one or more firmware resources from the received firmware data packet to update the firmware of the single - protocol single - chip radio device; and Updating the firmware of the single - protocol single - chip radio device using the dynamically selected one or more firmware resources.

2. The method according to claim 1, wherein The dynamic selection of the one or more firmware resources is based on at least one of the following: hardware / radio availability, usage of devices in the IoT environment, location and behavior of the devices in the IoT environment, geographical location of the single - protocol single - chip radio device, application load on the single - protocol single - chip radio device, firmware resources, priority of the devices in the IoT environment, user preferences, user selection.

3. The method according to claim 1 further comprises: Using a Network Co - Processor (NCP) to create space for the firmware update data packet to a Radio Co - Processor (RCP).

4. The method according to claim 1 further comprises: Backing up one or more devices connected to the single - protocol single - chip radio device.

5. The method according to claim 4, wherein, Updating the single - protocol single - chip radio device using multiple protocols further includes: using the backup to restore the connection of the one or more devices that were previously connected to the single - protocol single - chip radio device before the update.

6. The method according to claim 1, further comprising: Based on a failure in updating the firmware of the single - protocol single - chip radio device, discarding one or more firmware resources from the selected one or more firmware resources.

7. The method according to claim 1, wherein, The one or more connection protocols include at least one of Zigbee, Thread, or Bluetooth Low Energy (BLE).

8. The method according to claim 1, wherein, The one or more hardware resources include the radio, channel range, Network Co - Processor (NCP) / Radio Co - Processor (RCP) at the controller level of the single - protocol single - chip radio device.

9. The method according to claim 1 further comprises: Flashing the selected one or more firmware resources into the flash memory.

10. The method according to claim 9, Among them, The selected one or more firmware resources are first resource information, and wherein the method further includes: based on detecting a failure of the flashing: Recalculating one or more blocks present in the firmware update data packet, Obtaining second resource information by discarding one or more firmware resources from the selected one or more firmware resources, Re - flashing the second resource information into the flash memory, and Updating the firmware of the single - protocol single - chip radio device using the second resource information.

11. A single - protocol single - chip radio device present in an Internet of Things (IoT) environment, the single - protocol single - chip radio device comprising: A memory; A firmware control module, coupled to the memory; And One or more processors, configured to be electrically connected to the firmware control module and the memory, Wherein the memory stores one or more computer programs including computer - executable instructions, the computer - executable instructions, when executed by the one or more processors, cause the single - protocol single - chip radio device to: Receive a firmware update data packet, wherein the firmware update data packet includes one or more firmware resources associated with one or more connection protocols, Based on receiving the firmware update data packet, determine the size of the flash memory of the single - protocol single - chip radio device and one or more hardware resources at the controller level, Associate the received firmware update data packet with the size of the flash memory, the one or more hardware resources available at the controller level, and the current IoT context associated with the IoT environment, Based on the association, dynamically select one or more firmware resources from the received firmware data packet to update the firmware of the single - protocol single - chip radio device, and Use the dynamically selected one or more firmware resources to update the firmware of the single - protocol single - chip radio device.

12. The single-chip radio device based on a single protocol according to claim 11, wherein, The one or more computer programs further include computer - executable instructions, the computer - executable instructions, when executed by the one or more processors, cause the single - protocol single - chip radio device to dynamically select one or more firmware resources based on at least one of the following: hardware / radio availability, usage of devices in the IoT environment, location and behavior of the devices in the IoT environment, geographical location of the single - protocol single - chip radio device, application load on the single - protocol single - chip radio device, firmware resources, priority of the devices in the IoT environment, user preferences, or user selection.

13. The single-chip radio device based on a single protocol according to claim 11, wherein, The one or more computer programs further include computer - executable instructions, the computer - executable instructions, when executed by the one or more processors, cause the single - protocol single - chip radio device to use a Network Coprocessor (NCP) to create space for the firmware update data packet to a Radio Coprocessor (RCP).

14. The single-chip radio device based on a single protocol according to claim 11, wherein, The one or more computer programs further include computer - executable instructions, the computer - executable instructions, when executed by the one or more processors, cause the single - protocol single - chip radio device to back up one or more devices connected to the single - protocol single - chip radio device.

15. The single-chip radio device based on a single protocol according to claim 14, wherein, The one or more computer programs further include computer - executable instructions, the computer - executable instructions, when executed by the one or more processors, cause the single - protocol single - chip radio device to restore the connection of one or more devices that were previously connected to the single - protocol single - chip radio device before the update.

Images