Search

EP-4557701-B1 - COMMUNICATION NETWORK, METHOD AND DEVICE FOR OPERATING WITH A DISTRIBUTED MEMORY SPACE

EP4557701B1EP 4557701 B1EP4557701 B1EP 4557701B1EP-4557701-B1

Inventors

  • NICA, ELVIS GABRIEL
  • Viscotel, Laura-Anca

Dates

Publication Date
20260513
Application Date
20240215

Claims (15)

  1. A communication network (401) for operating a distributed memory system, DMS, the communication network (401) comprising a plurality of non-operating system, non-OS, embedded devices having at least one memory (390) wherein the at least one memory (390) of the plurality of non-OS embedded devices is configured to have a first portion of memory (310, 330, 350, 370) reserved for the non-OS embedded device and a second portion of memory (320, 340, 360, 380) reserved and available for at least one other non-OS embedded device from the plurality of non-OS embedded devices within the communication network (401) to use; wherein a first non-OS embedded device (400) of the plurality of non-OS embedded devices comprises: a first receiver (406) configured to receive a data chunk; a first transmitter (422); and a signal processor (408) operably coupled to the first receiver (406), the first transmitter (422) and the at least one memory (390), and configured to determine whether the at least one memory (390) has memory capacity (320, 340, 360, 380) to store the received data chunk; and in response to the at least one memory (390) not having memory capacity (320, 340, 360, 380) to store the received data chunk, the first signal processor (408) and first transmitter (422) are configured to send a storage request message to at least one of the plurality of non-OS embedded devices (450); and wherein the storage request message comprises at least one of: a write_data_request command; a broadcast storage request message; a multicast storage request message; a storage request message that is directly sent to an identified one of the plurality of non-OS embedded devices indicated by a data mapping algorithm employed by the signal processor.
  2. The communication network (401) of Claim 1 wherein the first signal processor (408) is configured to divide the received data chunk into fixed-size parsed data chunks and the storage request message is configured to include at least a portion of the fixed-size parsed data chunks, wherein the at least one of the plurality of non-OS embedded devices is configured to store the at least a portion of the fixed size parsed data chunks for use by the first non-OS embedded device.
  3. The communication network (401) of Claim 1 or 2 wherein a second non-OS embedded device (450) is the at least one of the plurality of non-OS embedded devices and comprises: a second receiver (456) configured to receive the storage request message from the first non-OS embedded device (400), at least one memory (390) operably coupled to the second receiver (456); and a second signal processor (458) operably coupled to the second receiver (456) and the at least one memory (390) and configured to determine that the at least one memory (390) has available memory capacity (320, 340, 360, 380) to store the received data chunk, and the at least one memory (390) is configured to store the received data chunk in response thereto.
  4. The communication network (401) of Claim 3 wherein the second non-OS embedded device (450) further comprises a second transmitter (472) operably coupled to the second signal processor (458) and the at least one memory (390), wherein the second signal processor (458) is further configured to: transmit a data chunk request to the first non-OS embedded device (400) in response to the received storage request message and a determination that the at least one memory (390) has available memory capacity (320, 340, 360, 380) to store the received data chunk; and receive the received data chunk in response to the transmitted data chunk request.
  5. The communication network (401) of Claim 4 wherein, in response to the first non-OS embedded device (400) having received multiple requests for the data chunk from the plurality of non-OS embedded devices, the processor (408) of the first non-OS embedded device (400) is configured to select a request from one of the plurality of non-OS embedded devices being indicative of at least one of: a quality of service, QoS, a proximity-based criteria of a sending device, a load-based analysis.
  6. The communication network (401) of any of preceding Claim, wherein the storage request message comprises an over-the-air, OTA, system update data file transfer that is sent to a plurality of different non-OS embedded devices in the communication network (401), wherein the data file transfer is divided into multiple data chunks and respective data chunks of the multiple data chunks are stored temporarily or permanently on a different plurality of non-OS embedded devices across the communication network (401).
  7. The communication network (401) of Claim 6 wherein the first non-OS embedded device is configured to receive the OTA system update data file transfer from at least one of the plurality of different non-OS embedded devices in the communication network (401) and, once validated, load the OTA system update data file transfer into its at least one memory (390) by an overwrite operation of an existing system data file.
  8. The communication network (401) of Claim 7 wherein the first non-OS embedded device is configured to perform a write operation of the existing system data file to the plurality of different non-OS embedded devices in the communication network (401) that provides a back-up of the existing system data file prior to an overwrite operation of the existing system data file.
  9. The communication network (401) of Claim 7 or 8 wherein at least one of: the OTA system update data file transfer, a back-up of an existing system data file prior to an overwrite operation of the existing system data file, is configured to be available to the plurality of different non-OS embedded devices in the communication network (401).
  10. The communication network (401) of any preceding Claim wherein the signal processor (408, 458) and transmitter (422, 472) of at least one of: the first non-OS embedded device (400), the second non-OS embedded device (450) is configured to determine that the non-OS embedded device (450) where it resides requires data, and in response thereto sends a data request message in the communication network (401) to other non-OS embedded devices, wherein the data request message is a request for one of: a data chunk or a whole data file.
  11. The communication network (401) of any preceding Claim wherein the communication network (401) is configured as an Internet of Things, loT, network.
  12. A method for operating a distributed memory system, DMS, by a communication network (401), the method comprising: providing a plurality of non-OS embedded devices operational within the communication network (401) with at least one memory (390); configuring the at least one memory (390) of the plurality of non-OS embedded devices to comprise: a first portion of memory (310, 330, 350, 370) reserved for the non-OS embedded device where the at least one memory (390) resides; and a second portion of memory (320, 340, 360, 380) reserved and available for at least one other non-OS embedded device from the plurality of non-OS embedded devices within the communication network (401) to use; wherein a first non-OS embedded device (400) of the plurality of non-OS embedded devices comprises: a first receiver (406) configured to receive a data chunk; a first transmitter (422); and a signal processor (408) operably coupled to the first receiver (406), the first transmitter (422) and the at least one memory (390); the method further comprising the signal processor determining whether the at least one memory (390) has memory capacity (320, 340, 360, 380) to store the received data chunk; and in response to the at least one memory (390) not having memory capacity (320, 340, 360, 380) to store the received data chunk, the first signal processor (408) and first transmitter (422) sending a storage request message to at least one of the plurality of non-OS embedded devices (450); and wherein the storage request message comprises at least one of: a write_data_request command; a broadcast storage request message; a multicast storage request message; a storage request message that is directly sent to an identified one of the plurality of non-OS embedded devices indicated by a data mapping algorithm employed by the signal processor.
  13. The method of Claim 12 wherein the second non-OS embedded device (450) further comprises a second transmitter (472) operably coupled to the second signal processor (458) and the at least one memory (390), the method further comprising the second signal processor (458): transmitting a data chunk request to the first non-OS embedded device (400) in response to the received storage request message and a determination that the at least one memory (390) has available memory capacity (320, 340, 360, 380) to store the received data chunk; and receiving the received data chunk in response to the transmitted data chunk request.
  14. The method of Claim 13 wherein, in response to the first non-OS embedded device (400) having received multiple requests for the data chunk from the plurality of non-OS embedded devices, further comprising the processor (408) of the first non-OS embedded device (400) is selecting a request from one of the plurality of non-OS embedded devices being indicative of at least one of: a quality of service, QoS, a proximity-based criteria of a sending device, a load-based analysis.
  15. The method of any of Claim 12 to 14, wherein the storage request message comprises an over-the-air, OTA, system update data file transfer that is sent to a plurality of different non-OS embedded devices in the communication network (401), further comprising dividing the data file transfer into multiple data chunks and storing respective data chunks of the multiple data chunks temporarily or permanently on a different plurality of non-OS embedded devices across the communication network (401).

Description

Field of the invention The field of the invention relates to a communication network, a method and devices for operating a distributed memory space (DMS), where neither the communication network nor the devices use an operating system. Examples described herein are applicable to, but not limited to, a method, devices and a communication network for creating and operating with a DMS, for example where the communication network is an Internet of Things (IoT) communication network. Background The Internet of Things (IoT) is a communication network of interrelated loT devices that connect and exchange data with other loT devices and the cloud. IoT devices are typically embedded with technology, such as sensors and software and can include mechanical and digital machines and consumer objects. Increasingly, organizations in a variety of industries are using an loT to operate more efficiently, deliver enhanced customer service, improve decision-making and increase the value of their business. With the loT, data is transferable over a network without requiring human-to-human or human-to-computer interactions. An entity, node or device or a 'thing' in an loT network can take many forms, including a person with a heart monitor implant, a farm animal with a biochip transponder, an automobile that has built-in sensors to alert the driver when tyre pressure is low, etc., or indeed any other natural or man-made object that can be assigned an Internet Protocol (IP) address and is able to transfer data over a network. Thus, typically, an loT network consists of web-enabled smart devices that use embedded systems, such as processors, sensors, memory and communication hardware, to collect, send and act on data they acquire from their environments. An embedded device is a highly specialized device that is designed for one or very few specific purposes and is usually embedded or included within another object or as part of a larger system. Embedded devices and systems have extensive applications in commercial, consumer, industrial, automotive, health-care and many other industries because of their diminutive and inconspicuous nature. Generally, whatever operating system or firmware an embedded device has can only run one specific application or purpose in order to perform its function, and this is because the device is meant to be small. Hence, the embedded device should consume small amounts of power and also has little computing power and has limited storage. Hereinafter, the term 'device' is intended to encompass all such forms of communication entity including said embedded devices. One identified issue in an IoT network, as in other similar known communication networks, relates to the known Over-The-Air (OTA) software system update process. Usually, the OTA software system update process uses a large amount of the flash memory of a device, not least as new data or software needs to be uploaded and stored whilst the existing data or software is functional and in situ. Often, in some applications, the flash memory is not large enough for a specific image update, and in this instance another (additional, external) storing device is used and physically connected to the loT device to assist in the update process. In order to avoid this convoluted situation, and in order to execute the OTA software system update process on a single device, it may alternatively be equipped with a larger external flash, which may be quite slow and expensive. However, if the OTA system software update transfer of a new system file encounters an error or the update process is interrupted, the update progress is lost, and the OTA software system update transfer must be re-started. Moreover, if the same image is needed by multiple devices in the network, the OTA software system update transfer is performed repeatedly for each loT device. FIG. 1 illustrates one simple example flowchart 100 of a known process that highlights the two main memory areas that are needed for an over-the-air (OTA) software/firmware system update process for updating devices in an IoT network. The example flowchart 100 of an over-the-air (OTA) software/firmware system update process for updating devices in an loT network commences with a device that is reset at 140, followed by a bootloader process at 150 that initiates the software processes within the device. Thus, when a device receives an OTA software/firmware system update, it first stores a new system update data file, say in a specially designated memory area, then it triggers the bootloader that is responsible for transferring control to the new system data file. A determination is then made at 160 as to whether or not the new system update is valid. If at 160 the new system update is not valid, e.g., an error has occurred during the OTA software/firmware system update download process, the bootloader transfers control to the existing system data file instead of the new system data file, so that the device remains fun