Method for controlling and switching firmware

Abstract

A method (1) for controlling and switching versions of firmware for accessing a communication network (121) is presented, the communication network implemented on a power supply network having a logical topology in the form of a tree of node devices (130-139), the communication network (121) comprising a concentrator device (110). The method (1) uses a bit field of a network management frame to automatically, redundantly and continuously check that the node devices (130-139) are using the same version of the communication protocol on the communication network as the concentrator device (110).

Description

Technical Field

[0001] This invention relates to the field of managing firmware versions for accessing a communication network implemented on a power supply network having a logical topology in the form of a tree of node devices. Background Technology

[0002] As is known, many communication networks have a tree-like topology (at least logically) to allow for extended communication coverage. Devices in such a network are typically called nodes. A node device acts as the root of the communication network and manages it to organize shared, identical communication guarantees: beacon transmission, topology management, etc. Then, when not managing to receive information directly from the root node device (also called the "base node"), these node devices act as relays representing other nodes in the communication network.

[0003] This type of communication network is particularly found in the context of AMM (“Automated Meter Management”) type power supply networks, where communication is established between so-called smart meters and data concentrator devices (sometimes called base nodes). This is the case, for example, in the PRIME (“Evolution of Powerline Smart Metering”) specification. The concentrator device is then the root of the communication network. Exchange between the meter and the data concentrator device relies on powerline communication.

[0004] To maintain synchronization among node devices in a communication network, beacons are transmitted periodically. The beacons are transmitted during a predetermined time slot for each frame sent within the communication network.

[0005] One problem with this type of beacon synchronization mechanism is that sometimes node devices do not receive beacons and are out of sync.

[0006] Therefore, in the event of a command to switch network access firmware, some node devices may not switch. If no switch is made within the required time, the node device will terminate because it can no longer communicate on the communication network.

[0007] In this context, it is necessary to provide a method for controlling and switching the firmware version used to access the communication network, which can be automatically executed by the node device to periodically verify the version of the access firmware that the node device is using to implement the communication protocol used by the concentrator device on the communication network. Summary of the Invention

[0008] To this end, according to a first aspect, a method is proposed for controlling and switching firmware versions for accessing a communication network having a logical topology in the form of a tree of node devices and implemented on a power supply network, the communication network including concentrator devices. The method is implemented by node devices including electronic circuitry systems, and the method includes a first stage comprising the following steps:

[0009] - Trigger the first time delay and verify the reception of any frame during the first time delay.

[0010] This enables the identification of the version of the communication protocol used by the concentrator device;

[0011] - If the firmware version used by the node device is implementing the communication protocol version used by the concentrator device, then repeat the first phase; otherwise, trigger the second phase, which includes the following steps:

[0012] - Trigger a second time delay and during the second time delay verify the reception of a network management frame of the type "beacon" sent by the concentrator device or by another node device and / or a network management frame of the type "upgrade request" sent by another node device, which makes it possible to identify the version of the communication protocol used;

[0013] - If the received first predetermined number M "beacon" type network management frames and / or the received second predetermined number N "upgrade request" type network management frames enable the identification of a version of the communication protocol implemented by the concentrator device or another node device that is not implemented by the version of firmware used by that node device, then switch the node device to another version of firmware that implements the version of the communication protocol used by the concentrator device or the relay device, and then repeat the first phase.

[0014] - If the number of received “beacon” type network management frames is strictly greater than 0 and strictly less than a first predetermined number M, and the number of received “upgrade request” type network management frames is strictly greater than 0 and strictly less than a second predetermined number N, then repeat the second phase.

[0015] If no network management frame is received, switch to another version of the firmware and then repeat the first phase.

[0016] Therefore, in a particularly ingenious way, the method according to the invention uses the bit fields of the network management frame to automatically, redundantly and continuously verify that the node device is using the same version of the communication protocol as the concentrator device on the communication network.

[0017] Therefore, this invention proposes a method for controlling and switching firmware versions used to access a communication network, which can be automatically executed by a node device to periodically verify the version of the access firmware that the node device is using to implement the communication protocol used by a concentrator device on the communication network.

[0018] According to specific regulations, each network management frame includes a bit field whose value is predefined based on the version of the communication protocol used, such that the value of the bit field indicates the version of the communication protocol used by the concentrator device and / or another node device.

[0019] According to specific regulations, the received “beacon” type network management frames are predefined time slots of frames transmitted in the communication network, enabling all node devices to synchronize with the concentrator device.

[0020] According to specific regulations, the bit field is the result of cyclic redundancy check, and the value of the result indicates the version of the communication protocol used by the concentrator device and / or another node device.

[0021] According to specific regulations, the received "upgrade request" type network management frame is a predefined time slot of a frame transmitted in the communication network, and enables the concentrator device to change the node device into a relay device.

[0022] According to specific regulations, a bit field is a most significant byte that includes four least significant bits, which are used to indicate the version of the communication protocol used by the concentrator device and / or another node device.

[0023] According to specific regulations, if no network management frame is received during the second phase, the node device switches to another version of firmware that implements the communication protocol used by the concentrator device, and then repeats the first phase by reinitializing the first time delay according to a predefined value.

[0024] According to specific provisions, the method includes the preceding steps of initializing a first time delay and a second time delay based on predefined values.

[0025] According to specific regulations, this step, which consists of verifying the reception of network management frames during the second time delay period, is performed by verifying the reception of network management frames sent by multiple devices in the communication network.

[0026] According to another aspect, a node device is proposed, which includes an electronic circuit system for performing the method according to the invention.

[0027] According to another aspect, a computer program product is proposed, which includes program code instructions for performing the method according to the invention when the instructions are executed by a processor.

[0028] According to another aspect, a non-transitory storage medium is proposed, on which a computer program is stored, the computer program including program code instructions for executing the method according to the invention when the instructions are read from the non-transitory storage medium and executed by a processor. Attached Figure Description

[0029] The above and other features of the invention will become more apparent from the following description of at least one exemplary embodiment, which is made with respect to the accompanying drawings, in which:

[0030] [ Figure 1 The diagram schematically illustrates a communication network with a tree-like logical topology, deployed on a power supply network, and the present invention can be implemented within this communication network.

[0031] [ Figure 2 A method for controlling and switching firmware versions for accessing a communication network, according to the present invention, is illustrated schematically.

[0032] [ Figure 3 This schematically illustrates the structure of a network management frame of the "beacon" type sent using the first version of the communication protocol;

[0033] [ Figure 4 This schematically illustrates the structure of a network management frame of the "beacon" type sent using the second version of the communication protocol;

[0034] [ Figure 5 This schematically illustrates the structure of a network management frame of the "upgrade request" type sent using the first version of the communication protocol;

[0035] [ Figure 6 This schematically illustrates the structure of a network management frame of the "upgrade request" type sent using the second version of the communication protocol;

[0036] [ Figure 7 The diagram schematically illustrates the hardware layout of a computer system, which includes an electronic circuit system for implementing methods for controlling and switching firmware versions for accessing a communication network. Detailed Implementation

[0037] Communication Network

[0038] The invention is described in detail below in the context of a communication network whose logical topology is tree-like (i.e., hierarchical from the root device) and deployed on a power supply network to enable AMM services. However, it should be noted that the invention is applicable to any communication network whose logical topology is tree-like (i.e., hierarchical from the root device), where devices act as relays for synchronization via beacons, enabling communication to be established between any device in the communication network and the root device.

[0039] Figure 1 A communication network 121 is schematically shown, which has a tree-like logical topology and is deployed on a power supply network, and the present invention can be implemented in this communication network.

[0040] The communication network 121 is in a tree structure, with a specific node device 110 (referred to as concentrator device 110 or base node) as the root node. The communication network 121 is designed to allow multiple node devices to be connected to the concentrator device 110. Figure 1 In this context, the node device that the communication network 121 is intended to connect is an electricity meter. Therefore, the communication network 121 enables the establishment of power line communication, allowing the concentrator device 110 to automatically continue taking power consumption meter readings from the electricity meter.

[0041] It must be understood that in such a communication network, the signal transmitted by a node device is typically invisible at every point in the network. Each node device transmitting the signal then has a "neighborhood domain," which is a subset of the communication network in which any connected node device can readily receive the signal. The neighborhood domain corresponds to the range of the transmitted signal based on predefined transmission parameters of the transmitting node device (e.g., power, modulation and coding schemes, etc.) and also on the characteristics of the communication channel (attenuation, noise, impedance, etc.). Therefore, each node device in the communication network has its own neighborhood domain.

[0042] To extend the range of power line communication, node devices act as data relays between other node devices and concentrator device 110. Such relay devices are referred to as switches in the PRIME specification. Some communications between node devices and concentrator device 110 may require several consecutive data relays. Node devices that do not act as relays are called terminal devices. Therefore, this structure defines node devices attached to each other to form a tree, i.e., a hierarchy constituting communication network 121. Each node device in communication network 121 is thus associated with a hierarchical level, which typically corresponds to the number of relay devices that the node device must traverse to reach the root of communication network 121.

[0043] In addition to relaying data, the relay equipment also transmits beacons 300, which enable node devices 130 to 139 attached to the relay equipment to synchronize with the communication network 121. These beacons are transmitted in predefined corresponding time slots. The structure of these beacons 300 will be defined below.

[0044] therefore, Figure 1 The diagram above illustrates this tree-like communication network. End node device 132 is directly attached to concentrator device 110. Two other node devices 130 and 131 are also directly attached to concentrator device 110. These two node devices 130 and 131 act as relay devices between concentrator device 110 and other node devices. Node device 130 acts as a relay device between concentrator device 110 and node device 133 (which itself acts as a relay device between node device 130 and terminal device 137). Therefore, communication between concentrator device 110 and terminal device 137 passes through two consecutive relay devices, namely relay devices 130 and 133. Node device 131 acts as a relay device between concentrator device 110 and three other node devices 134, 135, and 136. Node devices 134 and 136 are terminal devices, and node device 135 acts as a relay device between node device 131 and the two terminal devices 138 and 139. Therefore, node devices 130, 131, and 132 are associated with the hierarchical level of value "0", node devices 133, 134, 135, and 136 are associated with the hierarchical level of value "1", and so on.

[0045] Node devices not attached to communication network 121 are disconnected devices, such as... Figure 1 Node device 140.

[0046] It must be understood that the logical topology of communication network 121 is not fixed. Figure 1The logical topology of communication network 121 at a given time is shown. Specifically, due to interference phenomena (such as noise, attenuation, impedance variations, crosstalk, signal collisions, etc.), node devices can disconnect from communication network 121 and then attempt to re-register within it. The logical topology of communication network 121 at this time may differ from that of communication network 121 before the node devices disconnected; some node devices may have been potentially deprived of their relay function, while others may have been potentially committed to fulfilling that function. Node devices 130 to 139 are upgraded to relay devices by sending an upgrade request 400 (Protocol Data Unit Required for Upgrade, abbreviated as PNPDU) from a node device (such as node device 140) attempting to connect to communication network 121 and not having a neighboring relay device. The structure of the upgrade request 400 will be described in detail below.

[0047] Furthermore, the concentrator device 110 uses a certain version of the communication protocol to transmit information to all node devices 130 to 139 of the communication network 121. When the concentrator device 110 changes the version of the communication protocol, it sends a command to all node devices 130 to 139 to switch network access firmware. The node devices 130 to 139 then switch to another version of firmware, which enables the implementation of the new version of the communication protocol used by the concentrator device 110. However, it is possible that node devices 130 to 139 may not receive the switching command and retain the old version of firmware. The node devices then face the risk of no longer receiving frames sent by the concentrator device and being disconnected from the communication network. To avoid this problem, a control and switching method described in detail below is proposed.

[0048] Control and switching methods

[0049] Reference Figure 1 According to the first aspect, a method 1 for controlling and switching firmware versions for accessing the communication network 121 is proposed.

[0050] This method is implemented by each node device 130 to 140 of the communication network 121. Therefore, each node device 130 to 140 includes an electronic circuit system 200 that enables it to implement method 1.

[0051] like Figure 2 As illustrated, Method 1 mainly includes a first stage I and a second stage II.

[0052] Phase I

[0053] In the first phase I, method 1 includes step 4, which consists of triggering a first time delay. Then, method 1 includes step 5, which consists of verifying the reception of any type of frame sent by concentrator device 110 and / or another node device (130-140) acting as a relay or terminal device during the first time delay T1. This type of frame allows identification of the version of the communication protocol used by concentrator device 110. Therefore, in other words, according to step 5, node devices 130-140 monitor communication network 121 and receive any type of frame sent by concentrator device 110 and / or another node device (130-140) acting as a relay or terminal device. As will be described in detail below, for the specific cases of beacon 300 and upgrade request 400, the structure of each frame allows identification of the version of the communication protocol used by concentrator device 110 on communication network 121. Therefore, each frame sent by the concentrator device 110 (or by the node devices (130-140) acting as relay devices or terminal devices) includes information that makes it possible to identify the version of the communication protocol used by the concentrator device 110 (or by the node devices (130-140) acting as relay devices or terminal devices).

[0054] When any type of frame is received, method 1 includes step 6, in which node devices 130 to 140 identify the version of the communication protocol used by concentrator device 110 and compare the version of the firmware used by node devices 130 to 140 with the version of the communication protocol used by concentrator device 110. This comparison consists of determining whether the version of the firmware used by node devices 130 to 140 implements the version of the communication protocol used by concentrator device 110.

[0055] Therefore, in other words, for node devices 130 to 140, the comparison in step 6 consists of determining whether the node device can read the frame. If node devices 130 to 140 can read any type of frame, then the node device uses a firmware version that implements the version of the communication protocol used by concentrator device 110. On the other hand, if a frame cannot be read by node devices 130 to 140, then node devices 130 to 140 are using a firmware version that does not implement the version of the communication protocol used by concentrator device 110.

[0056] If the firmware version used by node devices 130 to 140 implements the version of the communication protocol used by concentrator device 110, then node devices 130 to 140 repeat Phase I.

[0057] Phase II

[0058] If the firmware version used by node devices 130 to 140 does not implement the version of the communication protocol used by concentrator device 110, then node devices 130 to 140 trigger the second phase II of method 1.

[0059] Phase II includes step 8, which consists of triggering a second time delay T2. Then, Phase II includes step 9, which consists of verifying the reception of network management frames sent by concentrator device 110 or by another node device 130 to 140 acting as a relay device between concentrator device 110 and node devices 130 to 140 or by another node device 130 to 140 acting as a terminal device during the second time delay T2.

[0060] The network management frame enables the identification of the version of the communication protocol used by concentrator device 110 or by another node device (130-140) acting as a relay or terminal device. In other words, according to step 8, if it appears that the firmware used by node devices 130-139 does not implement the version of the communication protocol used by concentrator device 110, then node devices 130-139 precisely listen for network management frames sent by concentrator device 110 or the other node device 130-140. As will be described in detail below, according to a particularly advantageous technical arrangement of the invention, analyzing certain bit fields in the structure of the network management frame makes it possible to accurately determine the version of the communication protocol used.

[0061] Reportedly, according to specific regulations, at step 8, node devices 130 to 140 verify the reception of management frames sent by multiple devices connected to the communication network 121. In other words, according to this regulation, node devices 130 to 140 listen for network management frames sent from multiple different sources.

[0062] If (condition 12) a node device captures a first predetermined number M "beacon" type network management frames and / or a second predetermined number N "upgrade request" type network management frames, all of which indicate a version of the communication protocol not implemented by the firmware version used by node devices 130 to 140, then method 1 includes step 10, which consists of switching node devices 130 to 140 to another version of firmware that implements the version of the communication protocol used by concentrator device 110 and / or another node device 130 to 140. Then, node devices 130 to 140 repeat the first phase I of method 1.

[0063] According to a particularly favorable provision, node devices 130 to 140 repeat the first phase I (step 2) of the method while reinitializing the first time delay T1. Typically, the first time delay T1 can be reinitialized to have a duration of 6 hours.

[0064] The analysis of a first predetermined number M "beacon" type 300 management frames and a second predetermined number N "upgrade request" type 400 management frames received within the second time delay T2 is a particularly advantageous technical provision of the present invention. This is because this provision ensures that most network management frames received during the second time delay T2 do indeed indicate the same communication protocol version used by the concentrator device 110 and / or another node device 130 to 140. In other words, this provision allows for the avoidance of isolated errors when node devices 130 to 140 send network management frames that trigger firmware version changes.

[0065] Typically, the first predetermined number M can be a positive integer between 5 and 11, and more specifically between 7 and 9 (inclusive), and the second predetermined number N can be a positive integer between 4 and 9, and more specifically between 5 and 7.

[0066] If the number of received “beacon” type 300 network management frames is strictly greater than 0 but strictly less than a first predetermined number M, and the number of received “upgrade request” type 400 network management frames is strictly greater than 0 but strictly less than a second predetermined number N, then node devices 130 to 140 repeat the second phase II of method 1.

[0067] If no network management frames are received, Method 1 includes step 11, which consists of switching to another version of the firmware. Method 1 then repeats the first phase I of the method while reinitializing the first time delay T1. Typically, the first time delay T1 can be reinitialized to a duration of one hour. In other words, if node devices 130 to 139 do not receive any network management frames, step 11 is executed. In this case, and according to the operating principles of the PRIME communication network disclosed above, it is possible that node devices 130 to 140 have been disconnected from the communication network. Therefore, node devices 130 to 139 change their firmware version to reconnect to the communication network 121. Then, node devices 130 to 140 repeat phase I while reinitializing the first time delay T1 for a short period. This allows for rapid error detection. This is because the firmware version change must enable node devices 130 to 140 to reconnect to the communication network 121, and node devices 130 to 139 must receive at least one frame of any type during the first time delay T1.

[0068] Initialization of time delay duration

[0069] Advantageously, method 1 may include the previous step 2, which initializes each time delay T1 and T2.

[0070] According to a specific implementation plan, the first time delay T1 can be defined, for example, as equal to 6 hours.

[0071] According to a specific implementation scheme, the second time delay T2 can be defined, for example, as equal to 1 hour.

[0072] As mentioned earlier, the network management frames received and used are preferentially "beacon" type 300 or "upgrade request" type 400.

[0073] According to method 1 of the present invention, specific knowledge of the structure of network management frames of “beacon” type 300 and “upgrade request” type 400 is used to determine the version of the communication protocol used to send network management frames of “beacon” type 300 and “upgrade request” type 400.

[0074] Beacon Structure

[0075] Figure 3 The structure of a network management frame of type 300 “beacon” sent on communication network 121 using the first version of the communication protocol is illustrated schematically.

[0076] Figure 4 The structure of a network management frame of type 300 “beacon” sent on communication network 121 using the second version of the communication protocol is illustrated schematically.

[0077] Regardless of the version of the communication protocol used, each network management frame of the "beacon" type 300 has a bit field 301 that is the result of a cyclic redundancy check (CRC), the value of which indicates the version of the communication protocol used by the concentrator device 110 and / or the relay device.

[0078] This is because each network management frame of "Beacon" type 300 includes a payload. Regardless of the version of the communication protocol used, the payload has the same number of bytes. However, the payload differs in the position and / or number of bits of the following fields: BCN.LEVEL, BCN.POS, BCN.COST, BCN.SEQ, and BCN.FRQ. These differences lead to discrepancies in the results regarding the Cyclic Redundancy Check (CRC).

[0079] Furthermore, it was observed that, according to the first version of the communication protocol, the CRC result was determined using the entire structure of the network management frame of “beacon” type 300, in addition to the result of the CRC itself.

[0080] On the other hand, according to the second version of the communication protocol, the entire structure of the network management frame of “beacon” type 300 is used to determine the result of the cyclic redundancy check (CRC), including the result of the CRC itself (to which a default value is assigned for this determination).

[0081] Therefore, for network management frames of type "beacon" 300, if the network management frames of type "beacon" 300 are sent using the same version of the communication protocol, the cyclic redundancy check (CRC) result is the same, and if the network management frames of type "beacon" 300 are sent using two different versions of the communication protocol, the CRC result is different.

[0082] Structure of upgrade request

[0083] Figure 5 The structure of a network management frame of type 400, "upgrade request," sent on the communication network 121 using the first version of the communication protocol is illustrated schematically.

[0084] Figure 6 The structure of a network management frame of type 400, "upgrade request", sent on communication network 121 using the second version of the communication protocol is illustrated schematically.

[0085] Regardless of the version of the communication protocol used, each network management frame of "Upgrade Request" type 400 has a bit field 401, which is the most significant byte (MSB) comprising four least significant bits 402. These four least significant bits 402 are used to indicate the version of the communication protocol used by the concentrator device and / or another node device (130-139) acting as a relay device or a terminal device. More precisely, it is assumed that the four least significant bits are reserved. Therefore, two of these four bits can be used to distinguish between two versions of the communication protocol. According to specific regulations, the two bits used are the PNH.VER bits. Thus, according to the first version of the communication protocol, the two PNH.VER bits can be equal to 00, and according to the second version, the two PNH.VER bits can be equal to 01.

[0086] Node devices

[0087] According to another aspect, node devices 130 to 139 including an electronic circuit system 200 for performing method 1 are proposed.

[0088] Computer System

[0089] According to another aspect, a computer system 200 is proposed, which includes an electronic circuit system configured to implement a method 100 for controlling and switching firmware versions for accessing a communication network.

[0090] like Figure 7 As schematically shown above, computer system 200 may include, via communication bus 210, a processor 201; random access memory 202; read-only memory 203, such as ROM or EEPROM (“Electrically Erasable Programmable Read-Only Memory”); storage unit 204 (such as a hard disk drive HDD) or storage media reader (such as an SD (Secure Digital) card reader); and input-output interface manager 205.

[0091] Processor 201 is capable of executing instructions loaded into random access memory 202 from read-only memory 203, external memory, storage media (such as an SD card), or a communication network. When computer system 200 is powered on, processor 201 is capable of reading instructions from random access memory 202 and executing those instructions. These instructions form a computer program that causes processor 201 to implement the methods and steps described herein.

[0092] Therefore, all or some of the methods and steps described above can be implemented in software by executing an instruction set by a programmable machine (e.g., a processor of the DSP (Digital Signal Processor) type) or a microcontroller, or in hardware by a machine or dedicated component (e.g., an FPGA (Field Programmable Gate Array) or ASIC (Application-Specific Integrated Circuit) component). Generally, computer system 200 includes an electronic circuit system adapted and configured to implement, in software and / or hardware, the methods and steps described above with respect to the computer system 200 discussed.

Claims

1. A method (1) for controlling and switching firmware versions for accessing a communication network (121), the communication network having a logical topology in the form of a tree of node devices (130-139) and implemented on a power supply network, the communication network (121) including a concentrator device (110), the method being implemented by the node devices (130-139) including an electronic circuit system (200), and the method being characterized in that it includes a first stage (I) comprising the following steps: - Trigger (4) a first time delay (T1) and during the first time delay (T1) verify (5) the reception of any type of frame containing information indicating the version of the communication protocol used by the concentrator device (110); - If the version of the firmware used by the node devices (130-139) is implementing the version of the communication protocol used by the concentrator device (110), then the first phase (I) is repeated; otherwise, the second phase (II) is triggered, which includes the following steps: - Trigger (8) a second time delay (T2), and during the second time delay (T2), verify (9) the reception of a "beacon" type network management frame sent by the concentrator device (110) or by another node device (130-140) acting as a relay device or terminal device and / or an "upgrade request" type network management frame sent by another node device (130-140) acting as a relay device or terminal device, the network management frame containing information indicating the version of the communication protocol used by the concentrator device (110) or by another node device (130-140) acting as a relay device or terminal device; - If the received first predetermined number M of the "beacon" type network management frames and / or the received second predetermined number N of the "upgrade request" type network management frames contain information indicating a version of the communication protocol implemented by the concentrator device (110) or by another node device (130-140) acting as a relay device or terminal device, which is not implemented by the version of the firmware used by the node device (130-140), then the node device (130-140) is switched (10) to another version of the firmware that implements the version of the communication protocol used by the concentrator device (110) or by another node device (130-140) acting as a relay device or terminal device, and then the first stage (I) is repeated. - If the number of received "beacon" type network management frames is strictly greater than 0 and strictly less than the first predetermined number M, and the number of received "upgrade request" type network management frames is strictly greater than 0 and strictly less than the second predetermined number N, then repeat the second stage (II). - If no network management frame is received, switch (11) to another version of the firmware and then repeat the first stage (I).

2. The method (1) of claim 1, wherein each network management frame includes a bit field (301, 401), the value of which is predefined according to the version of the communication protocol used, such that the value of the bit field (301, 402) indicates the version of the communication protocol used by the concentrator device (110) and / or another node device (130-140) acting as a relay device or terminal device.

3. The method (1) according to claim 2, wherein the network management frame of the received "beacon" type (300) is a predefined time slot of a frame transmitted in the communication network (121), and enables all the node devices (130-139) to synchronize with the concentrator device (110).

4. The method (1) according to claim 3, wherein the bit field (301) is the result of a cyclic redundancy check, the value of which indicates the version of the communication protocol used by the concentrator device (110) and / or another node device (130-140) acting as a relay device or terminal device.

5. The method (1) according to claim 2, wherein the network management frame of the received "upgrade request" type (400) is a predefined time slot of a frame transmitted in the communication network, and enables the concentrator device (110) to change the node device (130-139) into a relay device.

6. The method (1) according to claim 5, wherein the bit field (401) is a most significant byte comprising four least significant bits (402) for indicating the version of the communication protocol used by the concentrator device (110) and / or another node device (130-140) acting as a relay device or terminal device.

7. The method according to any one of claims 1 to 6, wherein during the second phase (II), if no network management frame is received, the node device switches (11) to another version of the firmware that implements the version of the communication protocol used by the concentrator device (110), and then repeats the first phase (I) while reinitializing the first time delay (T1) according to a predefined value.

8. The method (1) according to any one of claims 1 to 6, the method comprising a prior step of initializing the first time delay (T1) and the second time delay (T2) according to predefined values.

9. The method (1) according to any one of claims 1 to 6, wherein the step comprising verifying the reception of network management frames (9) during the second time delay (T2) is performed by verifying the reception of network management frames sent by a plurality of devices of the communication network.

10. A node device (130-139) comprising an electronic circuit system (200) for performing the method (1) according to any one of claims 1 to 9.

11. A computer program product comprising program code instructions for performing the method (1) according to any one of claims 1 to 9 when the instructions are executed by at least one processor (201).

12. A non-transitory storage medium storing a computer program product, the computer program product including program code instructions, the program code instructions being configured to perform the method (1) according to any one of claims 1 to 9 when the instructions are read from the non-transitory storage medium and executed by a processor (201).

Images