## 5 Implementation
### Implementation Design
#### 5.2.2 Direct Firmware Update Distribution  
The second part is the direct firmware update distribution of Figure 4. As shown in Figure 7, direct firmware update distribution starts when the client sends an update request (step 1). According to OCF firmware update protocol, their protocol is a scheduled firmware update process [3,4]. Thus, in the IoTivity Lite GitHub [29], the client will need to send a POST request to the IoTivity server that resides in the IoT device with three parameters--package URL (_purl_), software update's action (_swapdateaction_), and the time to update (_updatetime_). The package URL will be directed to the IoT gateway address, the _swapdateaction_ will be set to \"_isac_\" (initiate secure availability check), and the _updatetime_ will be set to the time when the client wants the IoT device to update the firmware with the format \"YYYY-MM-DDThh:mm::ssZ.\" According to the scheduled time, the _swapdateaction_ will be changed to \"_isac._\" Then, it will trigger the next step of the firmware update process. Three functions exist in the IoTivity server to process the firmware update based on the step. The names of the functions are Check New Version, Download Update, and Perform Upgrade. Therefore, we created three REST APIs to utilize these functions to communicate with the IoT gateway and install the new firmware update. We explain more about three functions below:  
* **Check New Version (step 2-8)**. If it is time to update, the IoT device will request the IoT gateway to check for a new update (2). The IoT gateway will then query the local database as to whether there is any compatible update based on the manufacturer and the device specifications (3). Additionally, it will check whether the current firmware version is lower than the value in the database. If the checking conditions are all matched, the IoT gateway will send \(U_{id}\) and firmware version to the manufacturer and sign it with the gateway's secret key (\(SK_{g}\)) (4). On the manufacturer side, after receiving the request, it will verify the signature using EthCrypto.recover (5). If verified, it will connect to the IoT gateway to deliver the binary file (6). After the IoT gateway receives the binary file, it will verify the hash of the binary file and compare the hash with the \(U_{id}\) (7). If they are equal, a notification will be sent to the IoT device, and otherwise reject it (8).
* **Download Update (step 9-10)**. After receiving a notification, the IoTivity server in the IoT device will change the state of pstat and softwareupgrade resources. It will then request to download the binary file to the IoT gateway (9). After receiving the request, the IoT gateway will send the binary file to the IoT device (10).  
Figure 7: Implementation of a direct firmware update distribution.  
* **Perform Upgrade (step 11)**. In this step, the IoT device extracts and installs the new firmware. To proceed with this step, we utilize Diff3 and patch function. Before we explain further, we will explain the process on the manufacturer's side. Thus, in our implementation, when the manufacturer has a new firmware update, they use Diff3 to compare old and new firmware files and then to merge them into one new file with.patch format. Figure 8 shows an example of a.patch file. The manufacturer wants to add a new function so that the IoT device can read the temperature in Fahrenheit. In the old version, the IoT device only read in Celsius. This file will be used to update the old firmware in the IoT device. Diff3 makes the update faster. It will not replace the whole file, but it will only remove or add the lines as in the written.patch file. After creating the.patch file, the manufacturer will create a MAKE file with commands in it to execute the patch. Then, the manufacturer will insert both.patch and MAKE files into an archive (.zip) file. After the IoT device has the.zip file, it will extract the.zip file and run the MAKE file to start the.patch file.