Design and Implementation of a LoRa Communication System Supporting Edge Computing on the Smart Multi-Platform IoT Gateway

Nội dung text: Design and Implementation of a LoRa Communication System Supporting Edge Computing on the Smart Multi-Platform IoT Gateway

1. JST: Smart Systems and Devices Volume 31, Issue 2, September 2021, 010-018 Design and Implementation of a LoRa Communication System Supporting Edge Computing on the Smart Multi-Platform IoT Gateway Vinh Tran-Quang1*, Huy Dao Nguyen, Dat Tran Tien Hanoi University of Science and Technology, Hanoi, Vietnam *Email: vinh.tranquang1@hust.edu.vn Abstract LoRa technology was developed over 10 years ago, with many communication protocols optimized for LoRaWAN. However, in the protocols, all data from the end devices are sent directly or forwarded through a gateway to the LoRaWAN server and processed centrally there. Accordingly, the gateway only acts as a forwarder. This mechanism increases the processing load on the server, increases latency, and is not suitable for applications with a large number of end devices or that require real-time applications. In this paper, we design and develop a new LoRa communication protocol that supports edge computing at the gateway. At the same time, the authors design and manufacture a Smart Multiplatform IoT Gateway (SMGW) and LoRa nodes that allow the implementation and evaluation of the proposed protocol in practice. The test results on a system of 50 LoRa nodes and the SMGW show that the proposed protocol works well when evaluating its performance in terms of reliability, latency, and power consumption. This proposed system is suitable for applications that require edge computing and is easily extendable to other IoT applications. Keywords: LoRa protocol, edge computing, multiplatform gateway, IoT system. 1. Introduction and 10-20 km in suburban environments [9]. The longest range recorded for LoRa to transmit data was In*the past 10 years, the 4.0 industry and the 766 km [10]. LoRa devices also consume power at low Internet of Things (IoT) have become more popular levels, ranging from 10 to 15 mA in the receiving than ever. The advantages of IoT applications are process and varying from 20 to 120 mA in the changing the way we live and work day by day. As a transmission process [11]. While patented LoRa forecast shown recently, the number of IoT devices wireless radio frequency technology stands for the will almost triple from 8.74 billion in 2020 to more physical layer protocol, LoRaWAN [12], which was than 25.4 billion in 2030 [1]. The essential difference developed by the LoRa Alliance, stands for the media in requirements between "the Internet" and "the access control layer protocol. In the LoRaWAN Internet of Things" [2] is that in IoT devices, there are architecture, there are three fundamental components: fewer things available, i.e., less memory, less power of the LoRa node, LoRa gateway and LoRa server. The processing, less bandwidth and less available energy. LoRa server in a LoRa network system needs to process One reason for these requirements is to optimize the all packets sent by LoRa nodes (end devices). It is not a energy consumed since maximizing the device lifetime problem if our IoT system is on a small scale. However, is our priority. Furthermore, when the number of once the number of end devices is enormous, the devices is colossal, we need to share bandwidth for traditional LoRa system will not only have a large each device. It seems that the devices in the IoT system latency of message transmission but will also overload need to "do more with less", and traditional wireless the LoRa server because it must process a huge number devices, such as Wi-Fi or cellular networks, are of messages, reducing system performance obviously not suitable for IoT devices. The rapid significantly. LoRa gateways, which are now only growth of IoT devices has generated a need for suitable responsible for transparent forwarding messages low-power wide-area (LPWA) technologies that are between end devices and LoRa servers, have a good long-ranged and consume ultralow power to substitute ability for processing data, and we do not need to be traditional wireless technologies [3-5]. To date, many concerned with their power consumption. LPWAs have been invented, such as ZigBee [6], which consumes low power but is limited in distance, and To exploit LoRa gateway resources that BLE [7], which consumes ultralow power and works traditional systems are wasting, this paper will propose over a very short distance. Each technology has and implement a new improved protocol that is easy to outstanding advantages and is suitable for a special deploy and allows us to parse, store packets from end application. LoRa technology [8] was invented to devices for additional purposes such as edge satisfy IoT requirements as much as possible. LoRa can transmit data within 3 km in urban environments ISSN: 2734-9373 Received: May 20, 2021; accepted: June 30, 2021 10
2. JST: Smart Systems and Devices Volume 31, Issue 2, September 2021, 010-018 computing and still ensure all functions as LoRaWAN Applications does. Web Mobile Desktop App The goal of this research is to build a complete IoT system, including designing and manufacturing hardware devices, designing communication protocols Server and data processing algorithms, and embedding these Network server Application server proposals on the devices. The rest of this paper is organized as follows. Section 2 presents the overall Join server Server Database architecture of the Lora communication system, flow of activity between end devices, gateway, and server. Section 3 and 4 present the implementation of the SMGW proposals in both end device and the gateway. The Forwarder tests are conducted in Section 5. Finally, Section 6 is Database Controller Transmitter the conclusion of the paper. Edge Server Receiver 2. LoRa Communication System Architecture Computing Connector 2.1. System Architecture and Components End Device The overall architecture of the proposed LoRa Other system is illustrated in Fig. 1. It still maintains the Sensor Controller LoRa components architecture of a traditional system based on LoRaWAN consisting of 4 component layers that Fig. 1. LoRa communications system architecture and include end devices, LoRa gateways, servers, and components. applications. The functions of each component are described below: - End device (LoRa node): The end devices with integrated sensors that measure the parameters of the environment in agriculture (i.e., humidity, temperature, pressure) or the parameters of the human body (i.e., blood pressure, pulse heart, weight). These parameters are processed by the central processor, usually a microcontroller, and then packaged with standard formatted data packets to be sent to the LoRa gateway by its LoRa module using our proposed LoRa communication protocol. - Smart multiplatform IoT gateway (SMGW): data packets sent by end devices are received by an SMGW. The SMGW plays an important role in this proposed Fig. 2. Layout and a prototype of the LoRa node system since it performs many processing functions 2.2. End Device (LoRa Node) rather than simply forwards data to servers as do traditional LoRa systems. It will parse packets to We designed and manufactured a LoRa node obtain needed data for edge computing purposes, send prototype that uses STM32L072 as a microcontroller, acknowledgments, send commands from server to end an RFM95 module for the LoRa communication devices if available and transmit data to server. module, and MAX7Q for the GPS receiver module. Fig. 2 shows the LoRa node device after designing, - Server: The server receives data from the SMGW manufacturing, assembling all components, firmware via back-haul transport, for example, over Wi-Fi, loading, and testing. Ethernet, or 4G/LTE. Servers store and process data and provide services to applications. 2.3. Smart Multi-Platform IoT Gateway (SMGW) - Application: This layer interacts directly with the We propose and develop a smart and user, provides interfaces that allow the user to monitor multicommunication IoT platform gateway that can the measured parameters online and allows the user to provide multiple radio interfaces to allow connection to manage and control the end devices by sending control different IoT end devices using different radio commands directly to the end devices over LTE or communication technologies, such as LoRa, ZigBee, through the SMGW. V2X, or Wi-Fi. The SMGW receives data from sensor nodes (the sensor nodes in this paper are the LoRa nodes that are integrated sensors), processes the data and then forwards it to the server; and receives control commands 11
3. JST: Smart Systems and Devices Volume 31, Issue 2, September 2021, 010-018 from the server and forwards them to sensor nodes. In PS 3V3 5V BUCK INPUT particular, the SMGW has the ability to perform edge CONVERTER +12VDC computing or machine learning on data received from HDMI HDMI Output sensor nodes, which is scalable for many different IoT DDR3 DDR3 4G/16bit PORT0 USB PORT systems. With such requirements, the SMGW is 1600MHz E8199-001-01 designed with a functional block diagram architecture, USB1 USB HUB PORT1+2 USB DUAL PORT (4 ports) GSB311231HR as shown in Fig. 3. Fig. 4 is a SMGW prototype. Given PORT3 V2X_UART PCIe V2X Mini Slot the limited scope of this paper, we do not present in I2C1 CPU EEPROM AM5728BABCXEA SDIO 3.0 detail the design and assembly process of the LoRa node USB2 LTE Module WiFi Module and the SMGW devices. (Quectel EC25) UART (Quectel EC25) LORA_SPI PCIe LoRa Mini Slot 2.4. Messages Flow and LoRa Components Activity I2C2 ZIG_UART PCIe ZigBee Mini In this system, end devices (LoRa node), the SENSORS Slot Ethernet RGMN ETHERNET PHY SMGW and the server are the three main components PHY RJ45 Ethernet that interact with each other in a flow of activity, as described in Fig. 5. Fig. 3. Function block diagram of the Smart Multiplatform IoT Gateway (SMGW). First, LoRa node packages sensed data (step 1) and then sent them to the SMGW (step 2). Then, a receive window will be opened to receive the corresponding acknowledgement (ACK) message (step 5). The ACK message may contain a control command (CMD) from the server. If so, the node executes the control command and responds with an ACK to notify the server if the CMD command was successfully executed by the node or not (step 4). If the gateway does not receive any ACK message corresponding to the command, a message containing that command is retransmitted in the next receive window. Fig. 4. A SMGW prototype. At the SMGW, after receiving the data packet LoRa Node SMGW Server sensing and from the nodes, the SMGW conducts data processing 1 (step 3), for example, combining data, performing data packaging data aggregation, running edge computing algorithms or AI algorithms and then sending the processed data to the Open 2 receive server (step 6). More details about the processing flow window Processing 3 at the SMGW will be presented in Section 4. 5 raw data 2.5. Data Packet Format 4 6 The data format and message structure used in this proposed LoRa communication system are defined and described as shown in Fig. 6. There are 4 fields in Fig. 5. Message flow and activities among the main the physical layer, namely, Preamble, Phy Header, Phy LoRa components. Header CRC, and CRC, which are preserved as in Phy Payload Phy Header PHY Preamble Phy Header (max 20 CRC CRC LoRaWAN [12]. These fields are added automatically Layer bytes) when data are processed at the LoRa module's physical layer. This format is applied to both uplink and MHDR MAC Payload downlink messages. (1 byte) (max 19 bytes) As we can observe from Fig. 6, a Phy Payload Frame Frame Mtype RFU Major Frame Port starts with a MAC Header (MHDR) field of 1 byte in Header PayLoad (3 bits) (3 bits) (2 bits) (1 byte) size. This is the MAC layer header field containing (7 bytes) (Max 11 bytes) MAC information that defines the purpose of the message, Layer Device Frame Frame Frame which includes the MType, RFU, and major fields. Address Control Counter Length The MType field (3 bits) identifies the type of message (4 bytes) (1 byte) (2 byte) (1 byte) that will be handled on the corresponding handler. RFU ACK Details of the message types are shown in Table 1. The (7 bits) (1 bit) RFU field (3 bits) is reserved for future usage. The major field (2 bits) contains the implemented protocol Fig. 6. Data format and message structure for the version. proposed LoRa communication protocol. 12
4. JST: Smart Systems and Devices Volume 31, Issue 2, September 2021, 010-018 Table 1. MType classification control purposes. The device address subfields have a size of 4 bytes, where the first 2 bytes are the gateway Mtype Type of message address, and the last 2 bytes are the address of the node. 000 Join-request message, sent from node The frame control subfields (1 byte) contain protocol control information. In the proposed protocol, the first 001 Join-accept message, sent from gateway 7 bits are reserved, and the last bit is the ACK bit, to notify that node has joined successfully which enables the acknowledgment of the ACK 010 Unconfirmed data message, sent by node, message. The frame counter subfields (2 bytes) contain no ACK the sequence number of the packet. The frame length 011 Confirmed data message, sent by node, subfields (1 byte) represent the payload length. ACK requirement 3. LoRa Protocol Implementation on End Devices 100 Unconfirmed command message, sent by 3.1. LoRa Communications Protocol gateway, no ACK requirement 101 Confirm command message, sent by After the end device (sensor node) starts gateway, ACK requirement activating, the node is in sleep mode to save as much power as possible. If there is an event (the event here 110 Reserved for future usage is triggered when data from the sensor is transmitted to 111 Reserved for future usage the processor), the node will wake up, take data from the sensor, pack data in the format presented in Start Section 2, and start data transmission. When the transmission finishes, the node will open a receive Start other Sleep communications window in a certain timeout duration. If the receive No Yes window time expires and the node does not receive any Event ? Retry_cnt > MAX ACK message from the gateway, it will retransmit the No Yes current packet in a certain time. If the transmission Start Tx Retry_cnt ++ fails, the node will discard the current packet and start Yes No waiting for another event from the sensor. If a node Start Rx & Wait ACK Time out ? receives a packet in timeout duration, it starts processing the packet. First, the data fields are parsed. DevAddr? No Msg ? After that, we check if the address of the devices is as Yes Yes No expected, whether the message is an ACK or not and ACK ? Validating ? what the ordinal number of the message is. If these Yes conditions are satisfied, the node keeps checking No CMD ? whether the packet has commanded or not. If there is a Pkt Numb? Yes command in the packet, the node will execute this Excute & Send ACK command and send a command ACK to the gateway. A flowchart of the LoRa communication protocol End implemented on the end device is shown in Fig. 7. Fig. 7. Flowchart of the LoRa communication protocol The communication process, which is designed implemented on the end device. based on class A of LoRaWAN, is revised to make the process as simple as possible. Fig. 8 illustrates the Receive Delay process of transmission and reception of the proposed protocol on the end devices. Tx Rx (uplink) (downlink) 3.2. Firmware Structure t Based on the LoRa communication protocol ToA Time out duration proposed above, we develop the source code and (Time on Air) deploy it on our end device. The firmware on the Fig. 8. Receiving time slot on the end device. device is developed in Keil C IDE, which supports The MAC Payload, next to the MAC header field, various microcontrollers, and compiled by the ARM up to 19 bytes in size, contains MAC layer data. This GCC compiler, which is for microcontrollers using the field is preceded by a frame header of 7 bytes in size ARM architecture. The firmware structure on the end containing subfields for control purposes. Next is a 1- device is divided into 6 layers, as shown in Fig. 9. byte frame port field, which is designed for future use. The application layer is the highest layer that is Finally, the frame payload field with a maximum size responsible for deploying and implementing the of 11 bytes contains the frame data, which are the data proposed communication protocol. The application the user needs to send. The frame header field is 7 layer consists of services such as LoRa service, GPS bytes in size divided into 4 subfields and used for service, GSM/4G service and other services. The 13
5. JST: Smart Systems and Devices Volume 31, Issue 2, September 2021, 010-018 midware layer is responsible for controlling and 4. LoRa Protocol Implementation on SMGW scheduling tasks of each service so that each can work 4.1. SMGW Components and Communication Flow independently and is easy to maintain if one of them has problems in the future. In this layer, we use Free- In a traditional LoRaWAN network, the gateway RTOS, a real-time operating system that is compatible only acts as an intermediary device to forward data with the ARM architecture. The abstraction layer is from the end devices to the server. In the proposed developed with additional tools, e.g., debugging tools system, the gateway plays an important role; it allows and diagnostic tools. The component driver layer us to receive raw data from end devices, perform contains libraries for developing drivers for LoRa, functions of data aggregation, edge computation, etc., GPS, or GSM modules. The peripheral driver layer to reduce the amount of raw data from many end consists of driver libraries for users to use peripheral devices that need to be sent to the server. This is also modules in microcontrollers, i.e., UART, SPI, TIMER, the reason for the research team to design and and GPIO. Finally, the hardware layer is the physical manufacture the Smart Multiplatform IoT Gateway part in the end device. This lowest layer receives data (SMGW) device and to develop and deploy the new from a higher layer, performs modulation or LoRa communication protocol on this device. demodulation of the received data, and passes it on to The SMGW components, functions, and flow of the higher layer. communication among them are illustrated in Fig. 10. Applications The gateway controller is the main part and central processor in the SMGW. All messages transmitted and LoRa Service GPS Service Other Service received will be parsed and packed here. The Gateway Forwarder takes responsibility for communicating with end devices and the Gateway Controller. This is Middleware a gate of LoRa communication. It sends the uplink CMSIS-RTOS formatted message which is received via a receiver module to the Gateway Controller and sends downlink formatted messages to the end devices. The gateway- server connector is responsible for communicating Abtraction Layers Component Drivers with the server via back-haul transport, i.e., Wi-Fi, DEBUG SX127x MAX7Q Ethernet, or 4G/LTE. The message processed by the Gateway Controller or computed by the Edge Computing module is moved to the Gateway-Server Peripheral Drivers Connector for encryption and then sent to the server. If SPI USART LPUSART GPIO the server sends a command, this module decrypts it and moves the command to the gateway controller for handling. The gateway database is responsible for Hardware storing and saving parsed and processed data. Edge Computing: This module takes data saved in the Gateway database to compute and send to the Fig. 9. Firmware structure developed and deployed on Gateway-Server Connector. the end device LoRa node. Fig. 10. The SMGW components' functions and communication flow. 14
6. JST: Smart Systems and Devices Volume 31, Issue 2, September 2021, 010-018 4.2. Flow of Activity on Gateway Controller the command table. Those commands that have received ACK will be deleted from the IPC table. Messages received from nodes are pushed into a These processes are illustrated by the flowchart in FIFO buffer, and the Gateway Controller fetches data Fig. 13. If there are no commands left in the command from this buffer continuously. These data packets are table, the SMGW will send ACK messages only. parsed, and their type is identified via its MAC header. Each message will be handled differently depending Start on its type. There are 2 types of messages we need to New period has started focus on: if the type of message is a data message, it is processed as the flowchart in Fig. 11, and if the type of Fetch Packet message is an ACK message, it is processed as the No flowchart in Fig. 14. Msg ? Yes 4.2.1. Data Message Processing No No Data ? ACK ? The data messages are validated by their gateway Yes Yes No address (GWAddr) and packet number (PktNumb). If Validation ? ACK Checking Process these conditions are not satisfied, these data messages Yes will be discarded. After checking the conditions, data Store for Data Process messages will be parsed and divided into fields in Prepare ACK Msg format in Section 3. Needed fields and related GWAddr? No information will be stored in the Gateway Database so CMD ? that the applications can take these data and apply Yes PktNumb? algorithm models for edge computing purposes. Add CMD to ACK Msg After successfully processing and storing the Send ACK Msg Send ACK Msg received data message, the gateway controller generates an ACK message and sends it to the List CMD in IPC Table corresponding node in its receiving window. To save New period has started power, the node's LoRa communication module is End configured to always stay idle until an event occurs. Therefore, the CMD command that the gateway wants to send to the node will be sent with an ACK message. Fig. 11. Flowchart of LoRa communication This integration will save node power, but it will also implemented on the SMGW. delay command execution as a trade-off. All the CMD DevAddr (a) CMD commands from the server are pushed in a table whose (4 bytes) header is presented in Fig.12 (a), and we call it the configuration and control table. When the gateway DevAddr generates an ACK message, it must check the device (b) CMD Start Time Timeout (4 bytes) address and command in this table to verify that there is a control command to send to this node. The Fig. 12. The commands header table (a) and the IPC DevAddr column contains addresses of the nodes to header table (b). which we need to send the control command, and the CMD column is the CMD code of the command. These Start codes are designed to follow the preconventional syntax between the gateway and the nodes. The CMD New period has started code in the table is encapsulated into an ACK message and sent to the corresponding node. To ensure that the Check TimeOut of CMD in node has received the control command, an ACK In-Progress-CMD Table message from the receiving node is sent to the SMGW No for confirmation. Therefore, we need a table to manage Expired ? the sent commands. This is the In-Progress-Command (IPC) table with its header shown in Fig. 12 (b). Yes Remove and add to the top of The IPC table contains commands that wait for CMD Table an ACK from the node. DevAddr is the address of the node that must be sent the ACK. The CMD field New period has started contains a list of waiting ACK commands. The start time field is the time when the command started End waiting for ACK. The timeout field is the ACK timeout. If that duration exceeds timeout, that Fig. 13. The flowchart of IPC processing. command will be moved and posted in the first row of 15
7. JST: Smart Systems and Devices Volume 31, Issue 2, September 2021, 010-018 Start Root File System Layer: This layer is designed with libraries to control operations of communication New period has started modules, including LoRa-SX1301, 4G/LTE, Wi-Fi, GPS MAX7Q, and Ethernet modules. All the functions Wait for ACK that communicate with the Linux operating system are No also implemented in this layer. ACK ? Yes Linux Kernel and Peripheral Drivers: This layer No includes the Linux kernel and drivers for peripheral GW Addr? End interfaces such as SPI, UART, GPIO, USB (for mouse, Yes keyboard), HDMI (LCD), PCIe, and RJ45 (Ethernet). Check DevAddr & PktNumb New period has started in in-progress-CMD-table Boot-loader Layer: This layer is responsible for No Yes setting the configurations on the microprocessor (CPU Exist ? Remove that CMD from table AM5728) and controlling the hardware layer in response to higher layer tasks and requirements. Fig. 14. Flowchart of ACK message processing. Hardware Layer: This is the physical layer of the Applications SMGW that is responsible for processing electrical LoRa Service PF Service Other Services signals, performing modulation, demodulation of radio signals, and so on. Root File System 5. Test Results and Analysis Linux Component Drivers C In this section, we present the results of services/ MAX7 4G/ Libraries SX1301 Wi-Fi commands Q LTE comprehensive tests to evaluate the performance of the proposed system. The field test consists of 50 LoRa devices installed with the proposed LoRa Linux Kernel & Peripheral Drivers communications protocol as described in Section 3 and SPI Ethernet USART GPIO the SMGW device installed with the LoRa communication protocol as described in Section 4. The evaluation parameters include reliability (packet loss), Boot Loader latency, and power consumption. 5.1. Packet Loss Hardware To evaluate communications reliability over Fig. 15. Firmware structure on the SMGW. distance of transmission and packet loss rate, we set up the following configurations and scenarios. The 4.2.2. ACK Message Processing SMGW is in a fixed place, and three LoRa nodes are If the message sent to the SMGW is an ACK deployed around it, as shown in Fig. 16. The distance message, the SMGW will trigger a process to handle the from gateway to nodes ranges from 500 m to 3500 m ACK message. This process is performed as shown in in the urban environment around West Lake, Hanoi, the flowchart presented in Fig. 14. Following this Vietnam. The spreading factor, bandwidth, coding procedure, the SMGW compares the GWAddr in the rate, transmit power and size of the payload of the received ACK message with its own address. After nodes are 10, 125 kHz, 4/5, 17 dBm and 100 bytes, validating the received ACK message, which means that respectively. In the test, we sent 200 messages every the CMD has been sent successfully, it will discard the 30 sec. command code in the IPC table and start a new period. As shown in Fig. 17, all the nodes have the same shape of the graph, showing the relationship between 4.3. Firmware Structure on the SMGW transmission distance and packet loss rate. This means Based on the proposed LoRa communication that all the test nodes have good communication protocol and the process of handling data messages reliability if the distance is less than 2.5 km and the and control messages on the SMGW as described packet loss ratio starts increasing dramatically if the above, we develop the source code and deploy it on our distance is more than 2.5 km. In theory, the transmission SMGW. The firmware is developed and embedded in distance of LoRa ranges from 2 km to 3 km in urban the Linux operating system with the structure divided environments, and the results of this test have proven into 4 layers, as presented in Fig. 15. that our proposed system, in practice, still ensures the transmission distance, consistent with the theory. Applications Layer: This layer is designed Although there is a high packet loss ratio when the similar to the application layer on the Node. It includes distance is over 3 km, we can reduce this ratio by using source code to run necessary services such as Lora a higher gain antenna or by placing the gateway at a service, PF service, GPS service, and 4G/LTE service. higher position to ensure line-of-sight propagation. 16
8. JST: Smart Systems and Devices Volume 31, Issue 2, September 2021, 010-018 Fig. 16. Transmission range testing scenario Fig. 18. Calculation of ToA in the LoRa Modem Calculator Tool. Fig. 19. Latency and processing delay as a function of Fig. 17. Average packet loss ratio as a function of the number of nodes. distance. 5.1. Latency and Processing Delay parameters are calculated as the formulation shown in the SX127x data sheet [11]. In this test, we use the In the next test, we will measure and evaluate two LoRa Modem Calculator Tool [11] to calculate the parameters: the round trip time (RTT) and the exact value of the ToA parameter corresponding to the processing time on the SMGW. The RTT is the configuration in this test scenario. As shown in Fig. 18, duration, measured in milliseconds, calculated from in this test scenario is 985.09 ms. when a node sends a message to the time it receives a response from a server. The formulation for 𝑇𝑇𝑇𝑇𝑇𝑇 The results analyzed in Fig. 19 show that as the calculating is as shown in Equation (1), in which number of nodes connecting and sending data to the is the propagation time, which is equal to the time gateway increases, the processing time on the SMGW 𝑅𝑅𝑅𝑅𝑅𝑅 increases, and therefore the RTT increases. This is on𝑝𝑝 air ( ) in this test, and is the processing time 𝑇𝑇on the SMGW. obvious because as the number of nodes increases, the 𝑇𝑇𝑇𝑇𝑇𝑇 𝑇𝑇𝑠𝑠 amount of data sent to the gateway increases, leading = 2 ì + = 2 ì + (1) to an increase in processing time and resources on the gateway. However, in the proposed system, the To𝑅𝑅𝑅𝑅𝑅𝑅 measure 𝑇𝑇processing𝑝𝑝 𝑇𝑇𝑠𝑠 time𝑇𝑇 𝑇𝑇𝑇𝑇, we𝑇𝑇 𝑠𝑠use the same configuration for the SMGW and nodes as in the processing time on the SMGW ranges from 20 ms for 𝑠𝑠 distance and reliability test scenario𝑇𝑇 above. In this test, 10 nodes to 250 ms for 50 nodes. This result is each node randomly transfers 100 bytes to the SMGW. acceptable and absolutely satisfies the requirement of The distance between nodes and gateway is fixed at latency (the latency is less than 300 ms in a common 1 km. The number of nodes ranges from 5 to 50. We LoRa system with the same configuration). capture the time when a node starts sending a message 5.2. Power Consumption and the time when the node receives an ACK message from the SMGW to calculate RTTs. We also capture The power consumption of a node depends on the time the SMGW received messages from the nodes two main components: the operation of the processor and the time the SMGW sent ACK messages to and the transceiver operation of the LoRa module. In calculate the processing time on the SMGW. The the proposed system, the node uses an 𝑇𝑇𝑇𝑇𝑇𝑇 17
9. JST: Smart Systems and Devices Volume 31, Issue 2, September 2021, 010-018 STM32L072RBT6 as the processor unit (MCU), and communication technologies, such as ZigBee and the LoRa module uses the RFM95 chip for the radio NB-IoT, into the SMGW, improve the system transceiver. The results of theoretical calculations performance, and apply the proposed system in real (based on the data sheet of STM32L072RBT6 and IoT applications. RFM95) and the results of practice tests show that in a References normal operating mode, the node (only the MCU works) consumes approximately 1.8 . In sleep [1]. Arne Holst, Number of IoT connected devices mode, current consumption is 350 . For the Lora worldwide 2019-2030, Jan 20, 2021 [Online]. module, at short transmission distances,𝜇𝜇𝜇𝜇 the current consumed when transmitting is 23 mA,𝑛𝑛𝑛𝑛 and the current connected-devices-worldwide/ consumed when receiving is 11 mA. Fig. 20 is an [2]. Gubbi, J.; Buyya, R.; Marusic, S.; Palaniswamia, M. image of the LoRa node performance test and power Internet of Things (IoT): A vision, architectural consumption measurement. Table 2 summarizes the elements, and future directions. Future Gener. measurement results. Comput. Syst. 2013, 29, 1645–1660 Table 2. Power consumption of the Lora Node. [3]. T.-Q. Vinh and T. MIYOSHI, Adaptive routing Mode Power consumption protocol with energy efficiency and event clustering Sleep mode 350 ( ) for wireless sensor networks, IEICE Trans. Commun. 91 (9), 2795–2805, 2008. Listening mode 1.8 ( ) 𝑛𝑛𝑛𝑛 Transmission (Tx) 34 (mA) 𝜇𝜇𝜇𝜇 [4]. T.-Q. Vinh and T. MIYOSHI, A novel gossip-based Reception (Rx) 11 (mA) sensing coverage algorithm for dense wireless sensor networks, Computer Networks 53 (13), 2275-2287. [5]. T.-Q. Vinh and T. MIYOSHI, Energy balance on adaptive routing protocol considering the sensing coverage problem for wireless sensor networks, Commun. Electron. ICCE, 2008. [6]. Noreen, U., Bounceur, A., & Clavier, L. (2017). A study of LoRa low power and wide area network technology. Proc. In 2017 International Conference on Advanced Technologies for Signal and Image Processing (ATSIP). [7]. Want, R.; Schilit, B.; Laskowski, D. Bluetooth le finds Fig. 20. Lora node performance test and power its niche. IEEE Pervasive Comput. 2013, 12, 12–16. consumption measurement. 6. Conclusion [8]. LoRa Alliance, LoRa and LoRaWAN: A technical overview, Tech. Paper, Semtech, 1-26, 2020. [Online]. In this paper, we have introduced and proposed a Available at: Semtech- complete IoT system including LoRa nodes and smart .com/documentation/tech-papers-and-guides/. multiplatform IoT gateway (SMGW) devices. We also developed and proposed the LoRa communication [9]. Q. Zhou, K. Zheng, L. Hou, J. Xing, and R. Xu, Design protocol and implemented it on the proposed system. and implementation of open LoRa for IoT, IEEE Access, vol. 7, pp. 100 649–100 657, July 2019. In the proposed IoT system, different communication technologies, such as WiFi/LTE and LoRa, can be supported by the SMGW, thanks to its ability to [10]. LoRa Alliance, LoRaWANđ distance world record decode and process messages right at the SMGW. The broken, twice. 766 km (476 miles) using 25mW functions allow the implementation of complex data transmission power. Available: processing algorithms such as performing edge alliance.org/LoRaWAN-news/LoRaWANr-distance/ computing or supporting artificial intelligence-based [11]. Semtech, Sx1276/77/78/79 -137 MHz to 1020 MHz data processing models at the SMGW. low power long range transceiver. Rev. 6 - January 2019. Tech. Rep. August 2016. [Online]. Available: The test results with the prototypes of the SMGW and LoRa nodes show that the LoRa communications transceivers/sx1276. protocol works well based on the evaluation of [12]. LoRa Alliance, LoRaWAN Specification (V1.1). reliability, packet loss rate, delay, and power [Online]. Available: consumption. The proposed system is also scalable to hub/LoRaWANtm-specification-v11, accessed Oct. meet the requirements of different IoT applications. In 10, 2020. the future, we will integrate other radio 18