{"id":848,"date":"2023-06-25T01:11:55","date_gmt":"2023-06-25T01:11:55","guid":{"rendered":"https:\/\/zli.one\/?p=848"},"modified":"2023-07-02T03:51:43","modified_gmt":"2023-07-02T03:51:43","slug":"848","status":"publish","type":"post","link":"https:\/\/zli.one\/?p=848","title":{"rendered":"LoRa IoT Device Firmware Update through Cloud Over-the-Air Interfaces"},"content":{"rendered":"\n
<\/span>
\n
\"\"<\/figure>
\n

LoRa IoT Device Firmware Update through Cloud Over-the-Air Interfaces<\/strong><\/h2>\n\n\n\n

Firmware is an integral part of devices, which refers to the software that instructs the hardware to function and commu- nicate with other software running on a device. Firmware updates are necessary to address security or performance issues during the lifetime of IoT (Internet of Things) devices. Over-the-Air (OTA) updates enable firmware updates to be completed remotely and securely, without the need to re- move devices from their deployment.<\/p>\n\n\n\n

This paper introduces a LoRa (Long Range) OTA procedure to enable cloud-based resources to initiate and complete updates to LoRa-connected IoT devices. This differs from existing OTA over LoRa solutions by allowing the LoRa gateway to simply push updates from upstream servers man- aging the deployment of devices. Upstream servers expose APIs to allow devices communicating over a TTS instance to initiate the OTA procedure. A PyCom FiPy was chosen as the IoT device on which to perform OTA.<\/p>\n\n\n\n

\n
Paper<\/a><\/div>\n<\/div>\n<\/div><\/div>\n<\/div><\/div>\n\n\n\n

Background<\/strong><\/p>\n\n\n\n

\n
\n
    \n
  • LoRa is a long-range, low-power networking protocol that allows IoT devices to communicate securely. It allows devices to be managed by base stations while allowing them to function for years without depleting on-board batteries.<\/li>\n\n\n\n
  • Over-the-Air (OTA) updates have enabled security patches and mission-critical updates to be delivered to increasingly important IoT devices.<\/li>\n\n\n\n
  • As part of managing these devices, it makes sense to be able to carry out OTA updates over LoRa.<\/li>\n\n\n\n
  • Our Goal: <\/strong>Enable LoRa OTA between Cloud and LoRa Devices.<\/li>\n<\/ul>\n<\/div>\n\n\n\n
    \n
    \"\"\/<\/figure>\n<\/div>\n<\/div>\n\n\n\n

    Procedure:<\/strong><\/p>\n\n\n\n

    \n
    \n
      \n
    1. Device connects with server over WiFi<\/li>\n\n\n\n
    2. Device requests manifest<\/li>\n\n\n\n
    3. Server sends builds & sends manifest<\/li>\n\n\n\n
    4. Device receives manifest and updates application and firmware files accordingly\n
        \n
      1. Requests files that are not on device from server<\/li>\n\n\n\n
      2. Backs up old files that needs to be updated<\/li>\n\n\n\n
      3. Deletes obsolete files per manifest directives<\/li>\n<\/ol>\n<\/li>\n\n\n\n
      4. For every firmware file, write firmware to OTA partition on device and set flag to boot from OTA instead of partition<\/li>\n\n\n\n
      5. Machine resets to complete update<\/li>\n<\/ol>\n<\/div>\n\n\n\n
        \n
        \"\"<\/figure>\n<\/div>\n<\/div>\n\n\n\n

        Implementation Steps<\/p>\n\n\n\n

        \"\"<\/figure>\n\n\n\n

        Setup Configurations<\/p>\n\n\n\n

        LoRa Socket:<\/strong><\/p>\n\n\n\n

          \n
        • LoRaWAN Mode – US-compliant bandwidth, channels, and frequencies (Zone: US915)<\/li>\n\n\n\n
        • LoRa OTAA (Over the Air Authentication)<\/li>\n\n\n\n
        • Blocking set – device waits for packets to be received<\/li>\n\n\n\n
        • Socket timeout set to 15 seconds – client triggers retransmission after 15 seconds of not receiving an expected packet<\/li>\n<\/ul>\n\n\n\n
          \n
          \n

          Triggers\/ACKs\/NACKs:<\/strong><\/p>\n\n\n\n

            \n
          • No OTA protocol for LoRa: start, stop, data format etc.\n
              \n
            • Example WiFi OTA code only send arbitrary bytes as trigger – we do the same thing<\/li>\n\n\n\n
            • Using arbitrary bytes<\/li>\n<\/ul>\n<\/li>\n\n\n\n
            • LoRa also does not have ACKs – we set our own bytestring to ACK\n
                \n
              • After server receives ACK, disposes of the last binary chunk \/ the last packet sent<\/li>\n<\/ul>\n<\/li>\n\n\n\n
              • LoRa also does not have NACKs – we set another bytestring to serve as NACK\n
                  \n
                • After server receives NACK, retransmits the last binary chunk \/ the last packet sent<\/li>\n\n\n\n
                • Use of NACK is not ideal, but it works very well! Retransmission is guaranteed in case of packet drop\/transmission failure<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<\/div>\n\n\n\n
                  \n
                  \"\"<\/figure>\n<\/div>\n<\/div>\n\n\n\n

                  Data Segmentation:<\/strong><\/p>\n\n\n\n

                    \n
                  • Data segmentation of the binary is done on the server<\/li>\n\n\n\n
                  • Our current chunk size is 40 bytes<\/li>\n<\/ul>\n\n\n\n

                    Achieved:<\/strong><\/p>\n\n\n\n

                    \n
                    \n
                      \n
                    • Transfer of files from webserver to LoRa device<\/li>\n\n\n\n
                    • Concatenation of chunks on end device to a file<\/li>\n\n\n\n
                    • Writing of files into OTA (firmware) partition<\/li>\n\n\n\n
                    • Retransmission of the last message from the server to the device if the device times out<\/li>\n<\/ul>\n<\/div>\n\n\n\n
                      \n
                      \"\"<\/figure>\n<\/div>\n<\/div>\n\n\n\n

                      Demo<\/p>\n\n\n\n

                      \n