# A Design of a Parcel Delivery System for Point to Point Delivery with IoT Technology
## 5 IoT Platform Interlocking Process  
In this paper, we adopted SKT's IoT platform, ThingPlug, which utilizes LoRaWAN installed in South Korea, considering the size of the data and the size of the commercial network transmitted by the IoT device. SKT provides commercial network linkage through its officially certified LoRa module. In this paper, the LoRa module of SEONG JI INDUSTRIAL was used. The LoRa module is connected to the Micro Controller Unit (MCU) and the Universal Asynchronous Receiver/Transmitter (UART)  
Figure 6: Image of the IoT device prototype. to send and receive messages through serial communication. The message sent from MCU to the LoRa module follows the Command-Line Interface (CLI) command format defined in the user manual. ThingPlug's LoRa commercial network interworking is accomplished through Open Test Bed (OTB) certification and Quality Assurance (QA) testing. Looking at the test items required by OTB certification, the first thing to do is to identify the debug message of the LoRa module from the MCU and design and implement it so that the CLI command can be sent. During OTB authentication, all debug messages sent by LoRa module must be printed out because the debug message is verified through the customer's host PC. Second, if you receive the reset downlink control command, we must reset the module after five seconds of delay. If an IoT device that is on a commercial network shows abnormal symptoms of operation, the ThingPlug server sends an order to reset an IoT device. MCU parses a debug message sent from an LoRa module and performs device reset through the CLI command. Since the reset command received from the server is a confirmed message type, the reset must be performed after waiting about five seconds for the LoRa module to receive the command and send the ACK. In addition, we should implement MCU command for perform the following actions:  
1. Data Send 65 Bytes. 2. Data Send 66 Bytes. 3. Link Check Request. 4. Device Time Request. For example, max payload is 65 bytes, so sending 65 bytes as shown in (1) can proceed without error but sending 66 bytes as shown in (2) must be able to check the error debug message. In addition, we need to check the message type. There are two kinds of messages: confirmed and unconfirmed. Confirmed message need to check packet was received. If the terminal device or server sends a confirmed message, they should send an unconfirmed message with the ACK to make sure that the message was processed. If there are no ACK, they send the confirmed message again. If retransmissions happened eight times, the return error and process will end. In addition, codes should be implemented that allow remote modification of the number of retransmissions. Because it is an additional remote-controlled IoT device, functions had to be implemented so that the device can perform all tasks when a variety of commands were issued from server. To do this, you need a code to verify that various functions work properly. It is necessary to verify that frame count messages, which are larger than or smaller than the existing values, were received from the device in the ThingPlug server by correctly parsing the corresponding messages, and that the frame count was set to be larger than the existing values and then processed the message normally. In addition, if the same message was received during processing after receiving the message, a code was required to confirm whether the message was dropped, and the uplink message was retransmitted and that the ACK was sent to the server. There is a condition that the firmware of the LoRa module should be kept up to date to stabilize the IoT device, and that the PCB produced by itself should be used instead of the PCB provided with the IoT device. When communication with ThingPlug is required during the implementation of OTB certification items, open the device to the test network to conduct the experiment.