The present invention is related to the transmission of software files to a particular node in a short-range wireless network. Specifically the present invention is related to transmission of software or firmware updates to a particular node in a wireless mesh network.
Modern day computing devices are fundamentally controlled by executable software or embedded firmware. Naturally, manufacturers of such devices often find it necessary to ensure that their products have the latest versions of software or firmware installed. However, the manufacturer may find it difficult to update the firmware once the computing device is sold to a user. Typically, this is remedied by having the user of a device download an update and then install said update on said device. This process may work for some use cases however it can get cumbersome as the number of devices increases (e.g. IoT applications).
Some manufacturers have attempted to solve this problem by having computing devices periodically go online and look for updates. If an update is available the computing device may be programmed to automatically download the update and install the software. Unfortunately this method does not scale well (i.e. when there a lot of devices present) since it requires each device to have a reliable and secure connection to the internet. Another approach is for the manufacturer to push updates to each device. This method is not without scaling limitation since the manufacturer may fail to reliably send the updates to every computing device due to interruptions in the communication link, a weak communication link, a remote location of the device, a connection timeout and many other factors related to the communication link. This naturally results in bad user experience and hence may develop a negative reputation against the manufacturer.
Thus there is a current and impending need for a method for reliably sending software to an electronic device that can scale as the number of devices grows.
The present invention proposes a system for facilitating transmission of software files from an originating node to at least one target node by short-range wireless communication link. The system may comprise of a plurality of nodes, a bridge, an originating node and a target node. It is valuable to understand that there could be plurality of target nodes as well. Each node is enabled to trans-receive the data using short-range communication link.
In one embodiment, at least one node amongst the plurality of nodes is connected to a bridge, which enables the originating node to transmit the data packet in a situation when the target node is situated outside the short communication network.
In another embodiment of the present invention, the third party server is enabled to send software files to the third party device through similar manner. The third party server initiates the advertising packet and transmits it to the corresponding bridge. Thereafter, the bridge retransmits the advertising packet in the short range wireless network to reach to the third party device.
In yet another embodiment of the invention in which the third party server is present within the short-range wireless network, the bridge is not connected with any node in this embodiment and therefore the advertising packet remains within the short-range wireless network.
The invention is more fully appreciated in connection with the following detailed description taken in conjunction with the accompanying drawings, in which:
For the purpose of promoting an understanding of the principles of the present disclosure, reference will now be made to the embodiments illustrated in the drawings and specific language will be used to describe the same. It will, nevertheless, be understood that no limitation of the scope of the disclosure is thereby intended; any alterations and further modifications of the described or illustrated embodiments, and any further applications of the principles of the disclosure as illustrated therein are contemplated as would normally occur to one skilled in the art to which the disclosure relates. All limitations of scope should be determined in accordance with and as expressed in the claims.
As used herein, the term ‘short range communication link and shod range communication network refers to at least one of a Bluetooth network (including networks that comply with the Bluetooth Low Energy [BLE] standard), near field communication network, ANT network, infrared communication network, WIBREE network, Zigbee network, Ultra-Wideband communication network, or any communication network implementing an Institute of Electrical and Electronics Engineers 802.15 standard. Moreover, the originating node is referred to as third party device and target node is referred to as third party server.
The third party server 108 acknowledges the advertising packet and retransmits back to the third party device 100 through same nodes 102, 104 from which it receives the advertising packet. Thereafter, the third party device 100 computes the favorable route to reach to the third party server 108. The favorable route comprises the preferred nodes in a short-range wireless communication mesh through which the data packet is to be transmitted to reach to the third party server 108. Once the favorable route is determined, the third party device 100 transmits the data packet, containing the first batch of software files along with route information, to the third party server 108. As soon as the data packet reaches any node during its travel, each node determines the validity of the cyclic redundancy check (CRC) and software files in the data packet. Once the validation is successful, the corresponding node 102, 104 transmits an acknowledgement signal back to the third party device 100 and retransmits the advertising packet to its next destination node 104. Once the third party server 108 receives the data packet, it will perform the validity of CRC and software files. Once the validation is successful, the third party server 108 transmits the acknowledgement signal back to the third party device 100.
Thereafter, the third party server 108 store and install the batch of software files in its memory. Also, thereafter, the third party server transmits the acknowledgement message to the third party device 100 through the favorable route containing a message that the corresponding batch of the software files has been installed successfully. However, if the CRC check is failed or installation of the software files fails then the unsuccessful message is transmitted back to the third party device 100 through the favorable route. Moreover, once the acknowledgment message is received by the third party device 100 only then does it transmit the subsequent data packet containing the next batch of software files. However, if the third party device receives the unsuccessful message from the third party server 108 then it retransmits the previously sent data packet to the third party server 108. This process will repeat until all batch files are successfully installed by the third party server 108.
In another embodiment of the present invention, the third party server 108 is enabled to send the software files to the third party device 100 through similar manner. The third party server 108 initiates the advertising packet and transmits it to the corresponding bridge 106. Thereafter, the bridge 106 retransmits the advertising packet in the short-range wireless network to reach to the third party device 100.
1 Byte length: Specifies the length of the data that follows.
1 Byte Flag: Indicates the type of data that follows.
1 Byte BD/EBR/BLE: This 1 byte filed indicates the type of device which is sending the packet.
Manufacture Specific data: This is a flag which indicates the data that is going to follow the Manufacture Specific data of the node
Manufacture ID: This field contains the Manufacture ID of the node.
Network ID: It indicates the network ID of the target node.
Sender ID: Is the node address of the retransmitting node.
Destination ID: Is the address of the node which needs to update with the latest firmware.
Hops and Flags: This contains the Hop count and the carryover of the encryption,
Encrypted Data: This field contains the payload to be transferred/updated in the encrypted form and the CRC and version.
Carry over Bits: This 2 byte field contains the carry over bits of the encryption.
2 Byte CRC—Is used to check the validate the data area after AES encryption
1 Byte command version—is used by the third party device to give the command to the receiving node.
3 Byte Sequence no—is used to avoid duplication of messages
Destination address—represents the destination id of the target node.
Route address 1-7: represents the route that advertising packet travels through before reaching the target node.
In one embodiment the mechanism for storing and pushing software and firmware to the nodes is implemented with the BLE connected mode data transfer.
After the mesh route discovery the mobile application will have the route information to the node that needs to be updated. The mobile device (originating node) will then scan for the advertisements and connect to the first node (target node) on to which it needs to transfer the data.
Once the application establishes the connection with the target node the originating node initiates the Store and Push Service 701. Next, the originating node starts transferring data to the target node with a predefined block size 702. Within the first 16 bytes that are written to the target node—in every block transfer—there will be the 3-byte session ID followed by the route information and then the actual data. Once the block transfer is complete the application counts the number of blocks it has written 703. Next the CRC is performed 704 and the status is reported back from the originating node to determine if the transfer was successful 705. The originating node in turn will check the status and will verify the CRC 705. If the CRC of the block matches then the status of the transfer is a success 706 else, a fail 707. If there is a failure case the application needs to rewrite the data again 702. If it's a success the application writes to the write complete characteristics and disconnects the connection 708. The disconnection could also be initiated by the node device once the write complete write on the characteristics happens.
The node which has the block data now checks for the next node address it needs to transfer the data, listens to the advertisements it's receiving to find the node which it needs to write the data.
Once the proper node is found it established the connection and does the same operation which was done by the application. This process continues till the desired node is reached. Once the desired node is reached the node writes the data to the EEPROM and sends an acknowledgement to the mobile application with the same transaction ID with BLE Advertisement. This continues till the firmware update is completed.
Once the firmware update is completed the mobile application sends an update request to the device and device reboots with the updated firmware
It will be understood that various modifications may be made. For example, other useful implementations could be achieved if steps of the disclosed techniques were performed in a different order and/or if components in the disclosed systems were combined in a different manner and/or replaced or supplemented by other components. Accordingly, other implementations are within the scope of the disclosure.
This present disclosure claims the benefit of U.S. Provisional Application Ser. No. 62/087,161, filed on Dec. 3, 2014 and Ser. No. 62/131,843, filed on Mar. 12, 2015.
Number | Date | Country | |
---|---|---|---|
62087161 | Dec 2014 | US | |
62131843 | Mar 2015 | US |