Method for updating firmware of device supporting class a of lorawan and device thereof

Abstract

A method for updating firmware of a device supporting class A of LoRaWAN, according to an embodiment of the present invention, may comprise the steps of: transmitting data to a gateway; receiving, from the gateway, data requesting a standby time and switching to class B; checking whether the standby time is reached; switching to class B when the standby time is reached; receiving a beacon message from the gateway; synchronizing with the gateway on the basis of information included in the beacon message; receiving firmware update data from the gateway; and switching to class A when the reception of the firmware update data is completed.

Description

Method for updating firmware of a device supporting Class A of LORAWAN and the device

[0001] The present invention relates to a method for updating firmware of a device supporting class A of LoRaWAN and a device therefor, and more particularly, to a method for simultaneously updating firmware of devices supporting class A of LoRaWAN and a device therefor.

[0002] LoRa, short for Long Range, is a wireless communication technology characterized by two key advantages: long range and low power consumption. LoRa is a wireless modulation technology derived from Chirp Spread Spectrum (CSS) technology and is a communication standard developed for Internet of Things (IoT) communications. LoRa's low bit rate makes it suitable for applications requiring small data transmissions. Data transmission speeds range from 0.3 Kbps to 50 Kbps, making it primarily used for text transmission. Typically, status data is transmitted once every 2 to 30 seconds, then sleeps, waking up when an event occurs to repeatedly transmit event data. Because it remains in sleep mode most of the time, it also consumes very little battery power. LoRa boasts a much longer transmission range than technologies like Wi-Fi, Bluetooth, and Zigbee. One of LoRa's key features is its use of unlicensed frequency bands, making it freely available to anyone.

[0003] LoRa is a modulation method, not a communications standard, and therefore does not provide a protocol for communication. This has led to confusion, as users can use it arbitrarily. LoRaWAN is a communications standard designed for wide-area network communications.

[0004] LoRaWAN offers three standards, depending on the application. The first is Class A, which is bidirectional and ultra-low power, and all LoRaWAN-enabled devices must support it by default. Because Class A always determines the communication cycle at the end node, devices supporting Class A do not need to be constantly on and consume the least amount of battery. However, while Class A devices can uplink immediately, downlink is only possible when uplink occurs, resulting in very limited communication. The second is Class B, which, unlike Class A, periodically sends a beacon signal to check for the need for downlink to the end node. This allows for more flexible operation than Class A, but also consumes additional power. The third is Class C, which allows for constant downlink from the end node. Because downlink must be available immediately when a signal is sent from the gateway, Class C-enabled devices must be always on.

[0005] In particular, devices supporting Class A have low power consumption, making them suitable for Internet of Things (IoT) communication. However, they cannot use multicast, making it difficult to use the LoRaWAN standard's FOTA (firmware on-the-air). The LoRaWAN standard also defines FOTA only for Class B and Class C. While Class A devices and gateways can perform FOTA one-to-one, the more Class A devices connected to a gateway, the longer the FOTA process can take, making it inefficient.

[0006] The technical task to be achieved by the present invention is to provide a class A device and method supporting FOTA of the LoRaWAN standard.

[0007] The technical problem to be achieved by the present invention is to provide a class A device and method capable of supporting FOTA via multicast.

[0008] In addition, the technical problems to be solved by the present invention are not limited to the technical problems described above, and other technical problems may exist.

[0009] A method for updating firmware of a device supporting class A of LoRaWAN according to an embodiment of the present invention may include the steps of transmitting data to a gateway, receiving data from the gateway requesting a waiting time and switching to class B, checking whether the waiting time is reached, switching to class B when the waiting time is reached, receiving a beacon message from the gateway, synchronizing with the gateway based on information included in the beacon message, receiving firmware update data from the gateway, and switching to class A when reception of the firmware update data is completed.

[0010] A method for updating firmware of a device supporting class A of LoRaWAN according to an embodiment of the present invention may further include a step of switching to a sleep mode after the step of transmitting data to the gateway.

[0011] In a method for updating firmware of a device supporting class A of LoRaWAN according to an embodiment of the present invention, the step of receiving firmware update data from the gateway may be a step of receiving the firmware update data in a ping slot cycle.

[0012] In a method for updating firmware of a device supporting class A of LoRaWAN according to an embodiment of the present invention, the waiting time may be a time from a time point of receiving the waiting time to a time point that is at least two ping slot cycles before a firmware update time point determined by the gateway.

[0013] In a method for updating firmware of a device supporting class A of LoRaWAN according to an embodiment of the present invention, information included in the beacon message may be a transmission period of the beacon message, a ping slot period, and a time stamp.

[0014] A method for updating firmware of a device supporting class A of LoRaWAN according to an embodiment of the present invention may further include a step of entering sleep mode again after the step of switching to class A.

[0015] A device supporting class A of LoRaWAN according to an embodiment of the present invention may include a controller that transmits data to a transmitting module, a receiving module, and a gateway, receives data requesting a waiting time and a transition to class B from the gateway, determines whether the waiting time is reached, and transitions to class B when the waiting time is reached, receives a beacon message from the gateway, synchronizes with the gateway based on information included in the beacon message, receives firmware update data from the gateway, and transitions to class A when reception of the firmware update data is completed, and the controller may be characterized in that it enters a sleep mode unless data is transmitted using the transmitting module or data is received using the receiving module.

[0016] In a device supporting class A of LoRaWAN according to an embodiment of the present invention, the controller can receive the firmware update data at a ping slot cycle.

[0017] In a device supporting class A of LoRaWAN according to an embodiment of the present invention, the waiting time may be a time from the time of receiving the waiting time to a time that is at least two ping slot cycles before the firmware update time determined by the gateway.

[0018] In a device supporting class A of LoRaWAN according to an embodiment of the present invention, the information included in the beacon message may be a transmission period of the beacon message, a ping slot period, and a timestamp.

[0019] In a device supporting class A of LoRaWAN according to an embodiment of the present invention, the controller may be characterized in that it cuts off power to the receiving module and the transmitting module when entering sleep mode.

[0020] A method for supporting firmware update of a device supporting class A by a gateway of LoRaWAN according to an embodiment of the present invention may include the steps of determining a firmware update time of a device supporting class A, receiving data from the device supporting class A, determining a waiting time of the device supporting class A based on the determined firmware update time, transmitting data requesting switching to class B after a determined time and after the determined waiting time, transmitting a beacon message, synchronizing with a device supporting class A that has switched to class B, and transmitting firmware update data.

[0021] In a method for supporting firmware update of a device supporting class A by a gateway of LoRaWAN according to an embodiment of the present invention, the waiting time may be a time from a time point at which the device supporting class A receives the waiting time to a time point at least two ping slot cycles prior to the determined firmware update time point.

[0022] In a method for supporting firmware update of a device supporting class A by a gateway of LoRaWAN according to an embodiment of the present invention, the predetermined time may be a time for the device supporting class A to transition to a state for receiving data.

[0023] In a method for supporting firmware update of a device supporting class A by a gateway of LoRaWAN according to an embodiment of the present invention, the beacon message may include information about a transmission period of the beacon message, a ping slot period, and a time stamp.

[0024] In a method for supporting firmware update of a device supporting class A by a gateway of LoRaWAN according to an embodiment of the present invention, the step of transmitting the firmware update data may be a step of transmitting the firmware update data in a ping slot cycle.

[0025] According to an embodiment of the present invention, a device supporting Class A of the LoRaWAN standard can support FOTA by multicast.

[0026] According to an embodiment of the present invention, devices supporting class A of the LoRaWAN standard can simultaneously perform FOTA, thereby saving power / current consumption and time.

[0027] In addition, the effects that can be obtained from the present invention are not limited to the effects mentioned above, and other effects that are not mentioned can be clearly understood by a person having ordinary skill in the technical field to which the present invention belongs from the description below.

[0028] Figure 1a is a diagram illustrating how a device supporting Class A of LoRaWAN transmits and receives data with a gateway.

[0029] Figure 1b is a diagram illustrating how a device supporting Class B of LoRaWAN transmits and receives data with a gateway.

[0030] Figure 1c is a diagram illustrating how a device supporting Class C of LoRaWAN transmits and receives data with a gateway.

[0031] FIG. 2 is a diagram illustrating FOTA in a LoRaWAN network according to one embodiment.

[0032] FIG. 3a and FIG. 3b are diagrams showing a device supporting class A performing FOTA one-to-one with a gateway according to one embodiment.

[0033] FIG. 4 is a flowchart showing a cell management module included in a battery module according to an embodiment of the present invention measuring leakage current.

[0034] FIG. 5 is a flowchart illustrating a process for performing a firmware update of a device supporting class A according to one embodiment of the present invention.

[0035] FIG. 6 is a flowchart illustrating a process by which a gateway according to one embodiment of the present invention performs a firmware update of a device supporting class A.

[0036] Figure 7 is a configuration diagram of a device supporting class A according to one embodiment of the present invention.

[0037] Hereinafter, a preferred embodiment of the present invention will be described in detail with reference to the attached drawings.

[0038] However, the technical idea of ​​the present invention is not limited to some of the embodiments described, but can be implemented in various different forms, and within the scope of the technical idea of ​​the present invention, one or more of the components between the embodiments can be selectively combined or substituted for use.

[0039] In addition, terms (including technical and scientific terms) used in the embodiments of the present invention may be interpreted as having a meaning that can be generally understood by a person of ordinary skill in the technical field to which the present invention belongs, unless explicitly and specifically defined and described, and terms that are commonly used, such as terms defined in a dictionary, may be interpreted in consideration of the contextual meaning of the relevant technology.

[0040] Additionally, the terms used in the embodiments of the present invention are intended to describe the embodiments and are not intended to limit the present invention.

[0041] In this specification, the singular may also include the plural unless specifically stated otherwise in the phrase, and when it is described as “A and / or at least one (or more) of B, C”, it may include one or more of all combinations that can be combined with A, B, C.

[0042] Additionally, in describing components of embodiments of the present invention, terms such as first, second, A, B, (a), (b), etc. may be used.

[0043] These terms are intended only to distinguish one component from another, and are not intended to limit the nature, order, or sequence of the component.

[0044] And, when a component is described as being 'connected', 'coupled' or 'connected' to another component, it may include not only cases where the component is directly connected, coupled or connected to the other component, but also cases where the component is 'connected', 'coupled' or 'connected' by another component between the component and the other component.

[0045] Additionally, when described as being formed or arranged "above or below" each component, "above" or "below" includes not only cases where the two components are in direct contact with each other, but also cases where one or more other components are formed or arranged between the two components. Furthermore, when expressed as "above" or "below", it can include the meaning of a downward direction as well as an upward direction based on one component.

[0046] Figure 1a is a diagram illustrating how a device supporting Class A of LoRaWAN transmits and receives data with a gateway.

[0047] Referring to FIG. 1A, a device (120) supporting Class A can wake up from a sleep state at regular intervals and transmit data to a gateway (110) via an uplink. The device (120) supporting Class A can transition to a state for receiving data after two predetermined periods of time. Specifically, if the device (120) supporting Class A fails to receive data after the first predetermined period of time, it can transition to a state for receiving data after the second predetermined period of time. The device (120) supporting Class A can enter a sleep mode when there is no data to transmit or receive.

[0048] A device (120) supporting Class A can turn off both the configuration for transmitting data and the configuration for receiving data before transmitting data. Thereafter, the device (120) supporting Class A can turn on only the configuration for transmitting data when transmitting data, turn it off again after data transmission is complete, and then turn on the configuration for receiving data after a certain period of time. The device (120) supporting Class A can also turn off the configuration for receiving data after data reception is complete.

[0049] A device (120) supporting Class A may need to transmit data in order to receive data. Therefore, a device (120) supporting Class A is mainly used for services centered on data transmission or when operating on a battery without using constant power.

[0050] Figure 1b is a diagram illustrating how a device supporting Class B of LoRaWAN transmits and receives data with a gateway.

[0051] Referring to FIG. 1B, a gateway (110) broadcasts a beacon message at regular intervals, and a device (130) supporting class B receives the beacon message. The beacon message may include an ID of the gateway (110), a transmission cycle of the beacon message, a ping slot cycle, a timestamp, etc. A device (130) supporting class B that receives the beacon message may be synchronized with the gateway (110) using the information included in the beacon message. A device (130) supporting class B may receive data by turning on a configuration for receiving data at each ping slot cycle.

[0052] In addition, a device (130) supporting class B can also support a method (125) in which a device (120) supporting class A transmits and receives data. That is, a device (130) supporting class B can receive a beacon message from a gateway (110) and be synchronized with the gateway (110) to receive data at every ping slot cycle, and can also wake up from a sleep state at regular intervals to transmit data to the gateway (110) and receive data after two fixed periods of time.

[0053] A device (130) supporting Class B can also enter sleep mode except for the time it is transmitting and receiving data. However, since a device (130) supporting Class B wakes up at the time it receives a beacon message and at each ping slot cycle, its battery consumption may be greater than that of a device supporting Class A.

[0054] Figure 1c is a diagram illustrating how a device supporting Class C of LoRaWAN transmits and receives data with a gateway.

[0055] Referring to FIG. 1C, a device (140) supporting Class C may always be able to receive data from a gateway (110). That is, the device (140) supporting Class C may not switch to sleep mode. The device (140) supporting Class C may have a shorter delay time for receiving data than the device supporting Class A and the device supporting Class B, but may consume more power. The device (140) supporting Class C may need to be powered by a power source rather than a battery.

[0056] FOTA of the LoRaWAN standard supports Class B and Class C, allowing gateways to perform batch updates for devices supporting Class B and devices supporting Class C.

[0057] FIG. 2 is a diagram illustrating FOTA in a LoRaWAN network according to one embodiment.

[0058] In a LoRaWAN network, FOTA can be performed by a gateway in batch updates for devices supporting class B or higher. Referring to FIG. 2, an application server (201) transmits firmware (210) to be updated to a server / gateway (203) of a LoRaWAN network, and the server / gateway (203) simultaneously transmits the firmware (210) to each device (205) supporting class B or higher. The devices (205) supporting class B or higher may be synchronized with the server / gateway (203) in advance. Devices performing FOTA may not switch to sleep mode.

[0059] In LoRaWAN networks, the frame field (Fport) of the port is preset for FOTA. Specifically, 200 is set for channel setup, and 201 is set for synchronization. In order to prepare for cases where some devices miss packets, LoRaWAN networks support technologies such as Forward Error Correction (FEC), Low Density Parity Check (LDPC), and Reed-Solomon encoding. Devices can not only decode received data to recover from errors, but can also use additionally transmitted redundancy information to restore the original data even if some packets are lost or damaged.

[0060] FIG. 3a and FIG. 3b are diagrams showing a device supporting class A performing FOTA one-to-one with a gateway according to one embodiment.

[0061] As previously explained, devices supporting Class A can receive data after a predetermined time has elapsed after transmitting the data. Devices supporting Class A can perform FOTA at the first available reception time after the first predetermined time has elapsed, or, if FOTA cannot be performed at the first available reception time, at the second available reception time after the second predetermined time has elapsed.

[0062] Figure 3a shows that a device supporting class A performs FOTA at the first possible reception time, and Figure 3b shows that a device supporting class A performs FOTA at the second possible reception time.

[0063] However, if FOTA cannot be performed during two receivable times, FOTA can be performed at a time when data reception is possible after the next data transmission.

[0064] FIG. 4 is a diagram illustrating a gateway updating a device supporting class A using FOTA according to one embodiment of the present invention.

[0065] Referring to FIG. 4, a gateway (401) and devices 1 to 3 (403, 405, 407) supporting class A may be included in a network according to the LoRaWAN standard. The gateway (401) may be connected to each of devices 1 to 3 (403, 405, 407) supporting class A to transmit and receive data, but devices 1 to 3 (403, 405, 407) supporting class A may not be connected to each other. According to one embodiment, the gateway (401) may need to perform a firmware update of devices 1 to 3 (403, 405, 407) supporting class A. Since devices supporting class A do not support multicast, firmware updates must be performed individually, but according to the present invention, firmware updates can be performed by switching classes.

[0066] First, the gateway (401) can determine the timing of a firmware update for devices 1 to 3 (403, 405, 407) supporting class A connected to the gateway (401) (S410). In Fig. 4, devices 1 to 3 (403, 405, 407) supporting class A are illustrated as devices supporting class A within a network according to the LoRaWAN standard, but more devices may be included, and the following process may be performed only for devices requiring a firmware update.

[0067] Device 1 (403) supporting class A can wake up from sleep state at regular intervals and transmit data to gateway (401) (S415).

[0068] The gateway (401) can transmit data requesting a switch to class B after a waiting time and a waiting time to the device 1 (403) supporting class A after a set time (S420). The set time may be the time when the device 1 (403) supporting class A switches from sleep mode to data reception mode (or wake-up mode) to receive the data. In addition, the waiting time may be the time from the time when the device 1 (403) supporting class A receives the waiting time to a time that is at least two ping slot cycles before the firmware update time determined by the gateway (401).

[0069] The same procedure as for device 1 (403) supporting class A may be performed for device 2 (405) supporting class A and device 3 (407) supporting class A (S425 to S440).

[0070] Devices 1 to 3 (403, 405, 407) supporting class A can switch to class B when the received waiting time is reached (S445). Since the gateway (401) knows the class switching point of devices 1 to 3 (403, 405, 407) supporting class A, it can operate like a gateway for class B.

[0071] The gateway (410) can broadcast a beacon message (S450). Devices 1 to 3 (403, 405, 407) supporting Class A that has been converted to Class B can receive the beacon message and check the ping slot cycle.

[0072] Devices 1 to 3 (403, 405, 407) supporting class A that have been switched to class B upon receiving a beacon message and a gateway (410) can be synchronized (S455).

[0073] Devices 1 to 3 (403, 405, 407) supporting class A that has been converted to class B can perform firmware updates through data transmitted in the ping slot cycle (S460).

[0074] Once the firmware update is complete, devices 1 to 3 (403, 405, 407) supporting Class A that were switched to Class B can be switched back to Class A (S465).

[0075] Devices 1 to 3 (403, 405, 407) supporting Class A that have been converted back to Class A can switch to sleep mode and wake up from sleep state at regular intervals to transmit data.

[0076] According to FIG. 4, the class switching timings of devices 1 to 3 (403, 405, 407) supporting class A coincide, enabling FOTA to be performed via multicast. Since the gateway and devices 1 to 3 (403, 405, 407) supporting class A can perform FOTA via multicast, power consumption can be minimized and the overall FOTA time of the network can be reduced, enabling efficient FOTA. If a device supporting class A that has missed FOTA is discovered, FOTA can be performed separately.

[0077] FIG. 5 is a flowchart illustrating a process for performing a firmware update of a device supporting class A according to one embodiment of the present invention.

[0078] Referring to FIG. 5, a device supporting Class A can wake up from a sleep state at regular intervals and transmit data to a gateway (S510). After transmitting data, the device supporting Class A can switch to sleep mode. The device supporting Class A can switch to a mode for receiving data after the first predetermined time. If the device supporting Class A does not receive data after the first predetermined time, it can switch to a mode for receiving data after the second predetermined time.

[0079] A device supporting Class A may receive data requesting a wait time and switching to Class B from a gateway (S520). The device supporting Class A may receive data requesting a wait time and switching to Class B after a first predetermined time or a second predetermined time. Here, the wait time may be the time that the device supporting Class A must wait before switching to Class B. The wait time may be the time from the time that the device supporting Class A receives the wait time to a time that is at least two ping slot cycles before the firmware update time determined by the gateway.

[0080] A device supporting Class A can determine whether the waiting time has been reached (S530). A device supporting Class A can wait until the waiting time has been reached.

[0081] A device supporting Class A can switch to Class B when the waiting time is reached (S540). When a device supporting Class A switches to Class B, it can receive beacon messages.

[0082] A device supporting Class A that has transitioned to Class B can synchronize with the gateway based on information contained in the beacon message (S550).

[0083] Devices supporting Class A that have switched to Class B can receive firmware update data (S560). Devices supporting Class A that have switched to Class B can receive firmware update data at each ping slot cycle. The firmware update data transmitted at each ping slot cycle can be received by all devices supporting Class B that receive data at each ping slot cycle. In other words, all devices supporting Class B can receive firmware update data simultaneously.

[0084] A device supporting Class A that has switched to Class B can switch back to Class A when receiving firmware update data is complete (S570). A device that switches back to Class A can enter sleep mode.

[0085] FIG. 6 is a flowchart illustrating a process by which a gateway according to one embodiment of the present invention performs a firmware update of a device supporting class A.

[0086] Referring to FIG. 6, the gateway can determine the timing of a firmware update for a device supporting class A (S610).

[0087] The gateway can receive data from a device supporting Class A (S620). The data transmitted by the device supporting Class A may be, for example, measured data.

[0088] The gateway can determine the standby time of a device supporting Class A based on the determined firmware update time (S630). The standby time may be the time from the time the device supporting Class A receives the standby time to a time at least two ping slot cycles prior to the firmware update time determined by the gateway.

[0089] The gateway can transmit data requesting a switch to Class B after a predetermined waiting time and a predetermined waiting time (S640). The predetermined time may be the time at which a device supporting Class A transitions to a state ready to receive data. The predetermined time may be the first predetermined time, or the first and second predetermined times. In other words, if a device supporting Class A receives data at the first predetermined time, it may not need to transmit data again at the second predetermined time.

[0090] The gateway can transmit beacon messages (S650). The gateway can transmit beacon messages at regular intervals starting from the point when it determines that a device supporting Class A has transitioned to Class B.

[0091] Thereafter, the gateway can synchronize with a device supporting class A that has been converted to class B using the information contained in the beacon message (S660).

[0092] The gateway can transmit firmware update data when the determined firmware update time arrives (S670). The gateway can transmit firmware update data at the ping slot cycle.

[0093] Figure 7 is a configuration diagram of a device supporting class A according to one embodiment of the present invention.

[0094] Referring to FIG. 7, a device (700) supporting class A may include a transmitting module (710), a receiving module (720), and a controller (730). The device (700) supporting class A may further include sensors, etc.

[0095] The transmitting module (710) and the receiving module (720) are connected to a controller (730) and can be turned on or off respectively by the controller (730). That is, the power can be turned on or off. The transmitting module (710) can be turned off except when transmitting data, thereby preventing power loss, and the receiving module (720) can also be turned off except when receiving data, thereby preventing power loss.

[0096] The controller (730) can transmit data to the gateway and receive data from the gateway requesting a wait time and switching to Class B. The controller (730) can check whether the wait time has been reached and, if so, switch to Class B. The controller (730) can receive a beacon message from the gateway. The beacon message can include a transmission cycle of the beacon message, a ping slot cycle, a timestamp, etc. The controller (730) can synchronize with the gateway based on the information included in the beacon message. The controller (730) can receive firmware update data from the gateway and, upon completion of receiving the firmware update data, switch back to Class A. The controller (730) can receive the firmware update data in the ping slot cycle.

[0097] In one embodiment, the waiting time is the time that a device (700) supporting class A waits before switching to class B, which the gateway can calculate and transmit to the device (700) supporting class A. When the waiting time elapses and the device (700) supporting class A switches to class B, the device (700) supporting class A can synchronize with the gateway and receive data in the ping slot cycle.

[0098] In one embodiment, the controller (730) may transition to class A and enter sleep mode.

[0099] Although the above description focuses on examples, these are merely examples and do not limit the present invention. Those skilled in the art will appreciate that various modifications and applications not exemplified above are possible without departing from the essential characteristics of the present invention. For example, each component specifically shown in the examples can be modified and implemented. In addition, differences related to such modifications and applications should be construed as being included within the scope of the present invention defined in the appended claims.

Claims

1. Step of transmitting data to the gateway; A step of receiving data from the gateway requesting a waiting time and a transition to class B; A step of checking whether the above waiting time is reached; Step of switching to class B when the above waiting time is reached; A step of receiving a beacon message from the gateway; A step of synchronizing with the gateway based on information included in the beacon message; A step of receiving firmware update data from the gateway; and A method for updating firmware of a device supporting Class A of LoRaWAN, comprising a step of switching to Class A upon completion of receiving the above firmware update data.

2. In paragraph 1, A method for updating firmware of a device supporting Class A of LoRaWAN, further comprising a step of switching to sleep mode after the step of transmitting data to the gateway.

3. In the first paragraph, the step of receiving firmware update data from the gateway comprises: A method for updating firmware of a device supporting Class A of LoRaWAN, the method comprising the steps of receiving the above firmware update data in a ping slot cycle.

4. In paragraph 1, A method for updating firmware of a device supporting Class A of LoRaWAN, wherein the waiting time is the time from the time of receiving the waiting time to the time at least two ping slot cycles before the firmware update time determined by the gateway.

5. In paragraph 1, A method for updating the firmware of a device supporting Class A of LoRaWAN, wherein the information contained in the above beacon message is the transmission cycle of the beacon message, the ping slot cycle, and the timestamp.

6. In paragraph 1, A method for updating firmware of a device supporting Class A of LoRaWAN, further comprising a step of entering sleep mode again after the step of switching to Class A.

7. Transmission module; receiving module; and A controller that transmits data to a gateway, receives data from the gateway requesting a waiting time and a transition to class B, checks whether the waiting time is reached, and transitions to class B when the waiting time is reached, receives a beacon message from the gateway, synchronizes with the gateway based on information included in the beacon message, receives firmware update data from the gateway, and transitions to class A when reception of the firmware update data is completed. A device supporting Class A of LoRaWAN, characterized in that the controller enters sleep mode unless data is transmitted using the transmission module or data is received using the reception module.

8. In paragraph 7, The above controller, A device supporting Class A of LoRaWAN, which receives the above firmware update data in a ping slot cycle.

9. In paragraph 7, A device supporting Class A of LoRaWAN, wherein the above waiting time is the time from the time of receiving the waiting time to the time at least two ping slot cycles before the firmware update time determined by the gateway.

10. In paragraph 7, The information contained in the above beacon message is the transmission period of the beacon message, the ping slot period, and the timestamp, and is a device supporting Class A of LoRaWAN.

11. In paragraph 7, The above controller A device supporting Class A of LoRaWAN, characterized in that the power of the receiving module and the transmitting module is cut off when entering sleep mode.

12. Step for determining the timing of firmware update for devices supporting Class A; A step of receiving data from a device supporting the above class A; A step of determining a standby time of a device supporting class A based on the determined firmware update time; A step of transmitting data requesting a transition to class B after a predetermined waiting time and after the determined waiting time; Step of transmitting a beacon message; A step of synchronizing with a device supporting Class A that has been converted to Class B; and A method for supporting firmware update of a device supporting Class A by a gateway of LoRaWAN, comprising the step of transmitting firmware update data.

13. In paragraph 12, A method for a gateway of LoRaWAN to support firmware update of a device supporting Class A, wherein the above waiting time is the time from the time when the device supporting Class A receives the waiting time to the time at least two ping slot cycles before the determined firmware update time.

14. In paragraph 12, A method in which a gateway of LoRaWAN supports firmware update of a device supporting Class A, wherein the above-determined time is the time for the device supporting Class A to transition to a state for receiving data.

15. In paragraph 12, A method for supporting firmware update of a device supporting Class A by a gateway of LoRaWAN, wherein the beacon message includes information about the transmission period, ping slot period, and timestamp of the beacon message.

16. In paragraph 12, The step of transmitting the above firmware update data is: A method for supporting firmware update of a device supporting Class A by a gateway of LoRaWAN, the method comprising the step of transmitting the above firmware update data in a ping slot cycle.

Images