Improving data communication on construction sites via LoRaWAN

Abstract

Easily-accessible and reliable data communication in construction processes ensures high building quality, efficient workflow and secure working environments. The setup of network infrastructure on construction sites provides the necessary condition for timely and effective data communication. This paper researches a solution for on-site networking by implementing an IoT network on a reference construction site in Germany. In contrast to high-cost and high-bandwidth network infrastructure, a Long Range Wide Area Network–LoRaWAN with low cost and low bandwidth was deployed on the site. With additional IoT servers and LoRa-enabled devices, the reference construction site is able to communicate remotely with a robotic lab. In order to validate this concept of LoRaWAN on construction sites, an intra-site logistics and task scheduling system was developed to test the network performance. This paper conducts a preliminary study on the application of the IoT network technology–LoRaWAN in the logistics automation in construction. The test results can be used as references for other automation applications, such as internet of robot, intelligent process management, decision making system, etc.

1 Introduction

Automation control systems are currently limited to in-shop prefabrication in the construction industry. By introducing network technologies to the construction site, automated machinery or robots can be networked on site for dynamic and collaborative tasks. This paper demonstrates a IoT network technology for on-site networking and data communication by implementing a Long Range Wide Area Network - LoRaWAN on a reference construction site in Germany. In contrast to high-cost and high-bandwidth network infrastructure, LoRaWAN is known as a low-cost, low-bandwidth and low-power-consumption IoT network technology. The technical characteristics of the LoRaWAN was researched in this study in order to fill the communication gap in construction processes. An automated system of intra-site logistics and task scheduling was developed as a proof of concept by interconnecting the reference construction site and a robotic lab via LoRaWAN. This paper conducts a preliminary study on the application of LoRaWAN in the logistics automation in construction. The test results can be used as references for other automation applications, such as internet of robot, intelligent process management, decision making system, etc.

In the following sections, Sect. 1 reviews the state of the art of data communication on construction sites. Section 2 introduces the technical characteristics of LoRaWAN. Section 3 presents the setup of the LoRaWAN and its architecture for the intra-site logistics and task scheduling system. Section 4 analyses the the test results. In the end, Sect. 5 discusses the further development of this research.

1.1 Data communication in construction projects

Good communication is key to the success in many projects, especially a construction project with complex tasks, dynamic working environments and a large number of project members with different professional backgrounds. In such complicated projects, inaccurate, non-accessible and second-hand data frequently leads to wrong decisions and late reactions, in the worst case, to serious safety incidents.

The 2018 industry report - Construction Disconnected (Thomas et al. 2018) by Plangrid surveyed nearly 600 construction professionals and came to a conclusion that poor project data and miscommunication led to 48% of the reworks in construction projects. The non-productive reworks cost billions of dollars every year ($31.3 billion in rework in the U.S. alone in 2018). Poor communication also wasted a lot of work time of the respondents. The report revealed an urgent need to utilize technologies on construction sites to improve data communication.

In the era of the Internet of Everything, data communication is no more limited to the information flow between humans. In a construction project, reliable real-time communications are required between machines and machines, machines and people in many aspects, such as construction process monitoring, warehouse management, on-site properties management, safety control in human-machine collaboration and so on. However, the setup of network infrastructure on construction sites confronts many constraints and limitations in reality, for example, no access to existing city infrastructure, dynamically changing working environment, and little budget for high-quality network service. Normally, permanent infrastructure of utilities is too costly and time-consuming to deploy for a temporary construction site (Brilakis 2007). One of the ideal solutions to improve the on-site communication should be a flexible, easily-implementable, low-cost, reliable and safe network infrastructure, which is capable of interconnecting other remote sites and sharing data with a single source of truth.

Various telecommunication technologies have been implemented as a possible solution for construction site, from cellular/mobile technology (such as 2G GSM to 4G LTE), to DECT (Digital Enhanced Cordless Telecommunications), to WLAN (Wireless Local Area Network), to GEO (Geostationary Earth Orbit) Satellite. A research paper from Salford Center for Research and Innovation presented a review of the advantages and disadvantages of the above mentioned telecommunications (Beyh and Kagioglou 2004). Drawbacks for the cellular technology include but are not limited to strong dependence on the service provider and uncontrollable cost. DECT is affordable and easily-implementable, nevertheless, is limited in signal range, and so as the WLAN, which provides fast internet and high bandwidth but requires a large number of Network Access Points to reach a short coverage perimeter (Beyh and Kagioglou 2004; Ochsner 2002). The satellite internet technology on one hand provides an easily-deployable and long-range interconnection, on the other hand, it is weather and location dependent and requires frequent maintenance (Brilakis 2007).

In the EU-funded research and development project COSMOS (Construction Site Mobile Operations Support), a hub-based satellite WAN was studied to bridge the link between headquarters with LAN and construction sites with WLAN, which supported the remote communication of sites in undeveloped areas (Meissner et al. 2003). The COSMOS developed a high-bandwidth and long-distance network system, allowing the intra-site and site-office communication. The data was shared in networked servers and offline data can be re-synchronize whenever the user re-connecting to the internet. The drawbacks of the COSMOS system stated in the project were the expensive satellite link which constitutes a complex installation of the infrastructure. Another project, which focused on wireless networking for site-office data communication, demonstrated an alternative solution –wireless internet via the application of Cisco Aironet 1300 (nowadays Cisco Aironet 1560¹) outdoor wireless bridge– supporting the 802.11 a/b/g standard (Brilakis 2007). The bridges, known as communication nodes, can be spaced apart up to 65km and propagate the wireless signal to and from a project site, so that the remote sites can own an internal high-bandwidth LAN and interconnect other sites. However, the downside is the unlimited internet fee paid monthly according to internet usage.

1.2 IoT wireless network technology

The increasing popularity and maturity of IoT technologies have aroused attention of the construction industry. Some IoT devices have already been deployed on construction sites in the fields of process monitoring, machinery maintenance, on-site safety, assets tracking, logistics etc. These internet-enabled devices are able to communicate over different IoT communication protocols, such as MQTT and CoAP, and over various wireless protocols, namely Bluetooth, WiFi, RFID, ZigBee, LoRaWAN and so on (Rouse 2020). The most attractive parts of the IoT technologies are, (a) scalable, flexible and easy implementation of networks to make ‘dumb’ things ‘smart’, (b) efficient usage of data for analysis, (c) low-power consumption and low-frequency maintenance. By utilizing IoT technologies, traditional construction sites can save a lot of effort to network large numbers of non-IP things on site. With only small adaptations on the current facilities, the construction sites become smarter via the application of distributed IoT devices. Because each technology has its own advantages and limits, choosing the suitable IoT network should depend on the specific requirements of different application scenarios (Teizer et al. 2018; BehrTech 2020).

Fig. 1

Comparison of different network technologies in data rate, range and cost

As shown in Fig. 1, LoRa, categorized under unlicensed LPWAN (Low Power Wide Area Network), meets the requirements of (a) low cost to deploy large numbers of IoT devices on construction sites, (b) low-frequency maintenance to keep thousands of things running, (c) long battery life for battery-powered device, (d) long range of internet coverage up to 5km in urban area or 15km in rural area (under ideal condition) for remote networking and (f) independency of supplier service (Semtech 2020). However, the biggest limitations of LoRaWAN are the low bandwidth and low data rates, which only allows a data volume from 250 bps to 50 kbps with limited duty cycle. Different from fast speed and high-bandwidth 4G and 5G technology, LoRa network is not suitable for low-latency and large-volume data transmission, such as video streaming, photo sending or real time machine operating, however, is ideal for long-term, high-latency data use cases, such as real-time environmental monitoring, process monitoring, machine maintenance, logistics tracking and assets management etc.

Nowadays, the category of LPWAN has been supporting a major portion − 45% of the billions of devices in the realm of IoT. LoRaWAN, as one of the LPWAN technologies, is designed to optimize the battery life, capacity, range and cost, which offers an efficient, flexible and economical solution for the small-volume data communication, which can be applied to sensors and actuators (LoRaAlliance 2018).

2 LoRa network and its application

2.1 Introduction of LoRa and LoRaWAN

LoRa technology, which is a energy-efficient radio modulation technique based on Chirp Spread Spectrum for long range, low power and secure data transmission, is created and governed by the LoRa Alliance (EverythingRF 2018). With the long-range communication links provided by LoRa, LoRaWAN defines the communication protocol and the network architecture. The LoRaWAN utilizes the unlicensed regional ISM (Industrial, Scientific and Medical) band with fixed bandwidth channels of either 125KHz or 500KHz. In Europe, the 10 channels range from 867 to 869 MHz, 8 for multi data rates from 250 bps to 5.5 kbps, 1 at 11 kbps and a FSK (frequency shifting keying) channel at 50 kbps (LoRaAlliance 2020).

The architecture of LoRaWAN is a star-like topology as shown in Fig. 2. Once a LoRa-enabled IoT device sends a message packet, the distributed gateways in the hearing range can receive the message packet and forward it to a network server via backhaul such as WiFi, Ethernet or cellular network. Based on its own priority criteria, the network server will select a gateway with the best signal or data rate, delete redundant packets from different gateways, send acknowledgements and transmit downlinks–sending messages back–to the IoT device via the chosen gateway. The processing of the received data and the generation of the downlink data are done by the application server. For data security, the LoRaWAN has in total two levels of security for both the network server and the application server–each level with one session key. The two session keys-NwkSKey (Network Session Key) and AppSKey (Application Session Key) are generated when a device joins the LoRaWAN (TheThingsNetwork 2020a). The NwkSKey for the network server guarantees the authenticity of the devices, while the AppSKey for the application server ensures no end user’s application data is accessible to the network operator (SmartMakers 2018).

Fig. 2

LoRaWAN architecture and its two security layers (SmartMakers 2018)

LoRa-enabled IoT devices can utilize one of the two activation modes to join the LoRaWAN (NewieVentures 2018), namely OTAA (Over-the-Air Activation) and ABP (Activation by Personalization). OTAA is a more secure mode than ABP, for it will first send a join request to exchange the two session keys for a join admission and data encryption. The two keys are re-generated on every new activation. While in ABP mode, these keys are already stored at the IoT device and on the servers. The keys stay static until manually changed (TheThingsNetwork 2020c). Figure 3 shows how a device joins the LoRaWAN in OTAA mode.

Fig. 3

LoRa-enabled IoT device joins the LoRaWAN in OTAA mode (Naoui et al. 2016; Zhou et al. 2019)

Additionally, there are three operation modes (Table1) which can be chosen during the programming of the IoT device –Class A, Class B and Class C (TheThingsNetwork 2020b). The selection of different operation modes is based on the requirements of specific applications.

According to the technical document written by Semtech², LoRaWAN has a big capacity of supporting about 10,000 devices, 10 messages per device per day.

Table 1 Characteristics of different operation mode

2.2 The applications of LoRaWAN in construction

Several IoT communication technologies have been tested and applied on construction sites, for example RFID (Radio-frequency Identification) for building components tracking (Song et al. 2006), BLE (Bluetooth Low Energy) for on-site staff management (Dror et al. 2019), Zig-Bee for temperature monitoring on construction sites (Jiang and Hua 2013). However, the short range, high power consumption, low security technologies have limited their applications on the construction sites (Teizer et al. 2018).

As previously mentioned in Sect. 1.2, there are no perfect network solutions for all the construction scenarios, however, it is important to choose a suitable technology according to the specific requirements. The requirements can be supporting for the major communication needs for construction sites, satisfying the mobility of the construction team, being available to the entire team members, reducing the communication cost and improving the internal as well as global communication with clients and suppliers (Beyh and Kagioglou 2002).

While LoraWAN is currently serving in water metering and traffic congestion in smart cities, as well as in livestock tracking in smart agriculture, the LoRaWan has been seldom explored in the field of construction with its application potentials of strong interoperability, large scalability ,easy accessibility, low cost and low maintenance. A study of real-time positioning via LoRaWAN for construction site logistics (Teizer et al. 2018) provided two use cases of geolocating and crane monitoring. However, the study only focused on the feasibility tests, no systematic solutions for data communication were given. Another study focusing on the geolocation of construction tools on construction sites and LoRaWAN performance (Roland et al. 2019) only presented a rough LoRaWAN architecture and data collection architecture. Systematic workflow and evaluation was briefly described.

As a result, the following sections present a systematic research of data communication improvement for construction via LoRaWAN. The infrastructure set up and test results can be used as a reference for other automation and digitization.

3 Intra-site logistics and task scheduling system via LoRaWAN

3.1 Concept introduction

The goal of the system is to provide a long-range data communication concept for logistics and task scheduling between the reference construction site and a robotic lab –Big Robotic Lab– via LoRaWAN in Aachen, Germany. The reference construction site (RCS)³, which covers an area of 10,000 square meters is an open-space living lab for automation construction research and teaching at RWTH Aachen university. The Big Robotic Lab (BRL) situated 1.2 km away from the RCS serves as an indoor lab for robotic fabrication (Fig. 4), simulating as a remote facility from the RCS in this paper. In the past, the two sites utilized separate systems and LANs for logistics and inventory management without data communication. When a tool, prefabricated component, or machine needed to be transported from the BRL to the RCS or vice versa, the methods for communication was mobile phone or email, which was inefficient. The WiFi range on both sites can not cover the transportation area for the moving GPS devices. However, installing a SIM card for each GPS devices to update information while travelling is expensive. This paper presents an economic and efficient telecommunication concept to digitize and automate the logistics and task scheduling system for tool delivery between these two sites via LoRaWAN. With the LoRaWAN deployed on the RCS, the GPS devices are able to communicate directly with the two sites as well as share data in the same servers and systems. The LoRa-enabled GPS device can be applied both on a truck for intra-site transportation or on a logistic robots for on-site delivery.

Fig. 4

Locations of the two sites – Big Robotic Lab and Reference Construction Site

The intra-site logistics and task scheduling system of tool delivery consisted of four main components (Fig. 5):

• 1. LoRa-enabled GPS devices, travelling along the main transportation route between sites for receiving new tasks, reporting current status and updating tools location;

• 2. LoRa gateway, installed at the RCS for transferring LoRa packets between the servers and the GPS devices;

• 3. LoRaWAN, deployed at the RCS for long-range intra-site data communication;

• 4. Web applications, installed on the servers for data management, data visualization and user interface.

Fig. 5

LoRaWAN architecture on the RCS

With the gateway mounted on the top of the crane with a height of 18 m above ground − 210m above mean sea level–a larger coverage range and good line of sight to the traveling GPS devices can be achieved. The GPS devices sent uplinks to the LoRaWAN with fixed intervals to report current status and received downlinks for new tasks and information. The web application visualized the information of:

• 1. Tool inventory (e.g. current location and amount);

• 2. Queuing tasks (e.g. tools needed from where and whom);

• 3. Location and status of the GPS devices (e.g. available or busy).

Via long-range LoRaWAN, the system can assign a tool delivery task to any available GPS devices in the WAN. In this research, the system will always choose the GPS devices which are the nearest to the wanted tools. After receiving the task on the GPS device, the driver has the option to accept or cancel the new mission. If the driver accepts and completes the mission, the tool information will be updated in the inventory system. Afterwards, the driver may receive another new delivery task and so on.

3.2 LoRaWAN architecture and systematic dataflow

The RSC was previously internet-equipped by 4G LTE, so that all the on-site facilities connected to the 4G router can have access to the internet. In Fig. 6, the LoRa gateway and Raspberry Pi with all the LoRa servers installed on it were wirelessly connected to the 4G main router. Both the Gateway and Raspberry Pi were assigned with a static IP address, so that the devices under the same LAN can have an easy and stable access to the backbone of the LoRaWAN and its databases. Besides, with the Dynamic DNS configured on the 4G router, the servers can be shared and connected by other devices on the internet as well.

Fig. 6

Network topology at the RCS

3.2.1 Gateway

A 10-channel outdoor LoRa gateway - Dragino DLOS8⁴ was wirelessly connected to the main router to access the internet with 4G and to the IoT devices with LoRa.

As to ensure a good radio signal for communication between the antennas of the LoRa gateway and devices, a direct line of sight should be considered when positioning the gateway. An elliptical area around the line of sight path –Fresnel zone– (Fig. 7) should be considered and any obstacles within this volume, such as trees, buildings, or hills, can weaken the radio transmission. As a result, the coverage area of a LoRa gateway is larger in a low-dense rural region than in a high-dense city. Higher position of the gateway antennas can create a better line of sight. In another research of range and coverage of LoRaWAN by Smartmaker (SmartMakers 2019), the gateways were installed at 3 different heights − 5, 10, 45 m, proving that generally a gateway at a higher position reaches a larger coverage (Table 2). However, regarding the different geographical conditions, these numbers are only provided for referencing.

Table 2 Range tests of three gateways installed at 5, 10 and 45 m (SmartMakers 2019)

Fig. 7

The Fresnel zone between the RCS and the BRL

To consider an optimized gateway position for the connection between the RCS and the BRL, a Fresnel zone was calculated with the following equation (MobileFish 2018):

$$\begin{aligned} R = 8.657*\sqrt{\frac{D}{f}} \end{aligned}$$

(1)

R - Fresnel zone radius in m

D - 2 point distance in km

f - Frequency in GHz

$$\begin{aligned} R = 8.657*\sqrt{\frac{1.2}{0.868}}\approx 16.55 ~ { m} \end{aligned}$$

(2)

The highest point among the two sites is the top of a construction crane at the RCS with a height of 18 m, which leaves space for a Fresnel zone of 16.55 m radius with few trees, buildings and flat area in between (Figs. 7, 8). In reality, taking the terrain, the buildings and trees in between into consideration, the situation was not as optimized as the calculation. In the real range tests, with the gateway mounted at 18 m, the result demonstrated a worse performance than the ideal situation. However, the following reasons show that it is still recommended to mount the LoRa gateway on the top of the crane in other construction application scenarios:

• 1. Providing the highest and safest installation position on the construction site to reach the best line of sight.

• 2. Providing easy-access and instant power supply from the crane to the gatewa.

• 3. Strengthening the LoRaWAN with more tower cranes equipped with the LoRa gateways.

Fig. 8

(1) Gateway mounted on the top of a crane. (2) View from the BRL to the RCS in the downlink test

3.2.2 LoRa-enabled GPS devices

Powered by 4.2v LiPo battery, the LoRa-enabled GPS device was mainly composed of a TTGO LoRa32 board⁵ and a sparkfun GPS SAM-M8Q⁶. The first prototype was in a dimension of 90 × 75 × 30 mm (L*W*H), small enough for both hand holding and machine attachment. The operating mechanism was programmed in the Arduino environment with the Arduino-LMIC⁷, which is a modified version of the IBM LMIC (Lora MAC-in-C) library.

Because Class A only listens to coming messages at specific time (1 or 2 s) after an uplink transmission, which is the most power-saving mode among Class A, B and C, the GPS device utilized Class A as its operation mode in order to compensate for the large power consumption of the GPS module.

Another important parameter –the spreading factor (SF)– also has a strong influence on the data transmission. From SF12 to SF7, the SF with each step lower increases 2 times more bytes in one sending but results in more sensitive signal for longer distance transmission (Augustin et al. 2016). Besides, the SF with lower number cost less energy and less time to transmit a message packet (Qoitech 2019). Considering the short distance − 1.2 km between the BRL and the RCS, the spreading factor in this study was programmed to SF7,which ensured a stable and fast update interval of 20 s. In contrast, SF12 led to a much longer interval − 1 m 30 s to transmit one packet in the tests.

OTAA was chosen as the activation mode in this research. Compared to ABP, it is a more secure activation mode to join the network with a globally unique DevEUI –a 64-bit end-device identifier normally provided by the device manufacturers, an unique AppEUI –a 128-bit end-device identifier provided by the application server in order to identify the end application and a data encryption AppKey –a 128 bit AES key to encode message between end device and the application server (Pfeffer 2018).

The size of an uplink payload was programmed as 10 bytes, first byte for the availability of the node, second byte for the confirmation of the new task and the rest 8 for the device location –the latitude and longitude. The encoded payload was decoded into JSON format on the application server via a customized decoder, and sent out to other applications via MQTT (Message Queuing Telemetry Transport⁸), which is a common IoT communication protocol used by many IoT platforms and applications.

When a new task is coming, the GPS device will ask the driver if he or she wants to accept a specific task. If yes, the driver will press a green button to confirm, otherwise press a red button to reject the task. The operation results will be received and processed in the logistics and task scheduling system. The green light on the GPS device indicates a task to be finished and the yellow light shows a pending new task to be confirmed or cancelled. When the task is finished, the red button should be pressed again to report the completed mission and wait for a new task (Figs. 9, 10).

It is interesting to mention that the design and programming system of the GPS device allows many application extensions by exchanging or adding more sensors on the standardized microcontroller, by changing MQTT topics and payload contents in the script. These standardized and open systems are also commonly used in the development of the automated machinery and robots, which indicates that LoRa network technology is also highly applicable in construction robotics.

Fig. 9

Different status of the device - pending task, current task and no task

Fig. 10

Flowchart of the device working function

3.2.3 Servers and applications on Raspberry Pi

The Raspberry Pi connected to the 4G router with a static IP address served as the center of the whole system. The Chirp Stack LoRaWAN Network Servers⁹, including the gateway bridge, the network server and the application server were all installed on the Raspberry Pi. As a result, more than one gateway can be easily installed at the RSC by simply pointing at the fixed IP address, making the whole network architecture flexible and scalable.

As mentioned above, the data sent by the GPS device was decoded on the application server into JSON format and sent out via MQTT, so that other platforms or web applications or devices connecting to the MQTT broker can listen to messages under specific topic name in the LoRaWAN. In this study, the topic name of an uplink event from the GPS device is ‘application/13/device/ (the DevEUI of the device) /event/up’. This topic structure makes it easy for the system to identify and receive data from different devices, then classify the data for different applications. Additionally, the whole system is flexible and scalable by registering large number of LoRa-enabled devices under various applications. For example, all the temperature-monitoring devices can be registered under number 10–Temperature Monitoring Application–with a topic name of ‘application/10/device/ (the DevEUI of the device) /event/up’ to be subscribed. By speaking the same IoT language, the data can be easily saved and shared in the databases and be visualized on dashboards.

3.2.4 Web application

In this study, NodeRED¹⁰ was applied as a web-based user interface and data dashboard. NodeRED is a JavaScript-based visual programming tool for wiring together hardware devices, APIs and online services with visualized nodes on a browser-based palette. It supports JSON format and MQTT communication protocol, which makes it a suitable tool for the system.

On the NodeRED interface, there were 3 main sections (Fig. 11). Data was stored in 3 databases on the local Raspberry Pi via SQLite¹¹:

• 1. Tool inventory

• 2. Task

• 3. GPS device

Fig. 11

NodeRED Interface of the logistics and task scheduling system

By storing the device information in the GPS Device Database (Fig. 12), the web application always queries the newest status of every seen device and visualizes the status on the dashboard. Based on the newest information, for example, if the available device is currently in the range of the RCS, the system will assign a task aimed at the tools at the RCS from the list of New Task in the Task Database (TaskDB) to this device and ask for a response. Before receiving a response from the device, the pending tasks are stored in the list of Pending Task in the TaskDB. If the device accepts, the task will be transferred to another list of Task in Progress and be deleted from Task in Progress after the task has been accomplished. In the opposite case, if the device denies or does not reply to the system, the pending task will be returned from Pending Task to New Task. After the tools are delivered, the tools location will be updated in the inventory system.

Fig. 12

Data flow between the Databases of the logistics and task scheduling system

Furthermore, the system can automatically inform the site manager with voice messages for any coming delivery, so that the waiting time in the logistics chain can be eliminated.

3.2.5 Application extensions

Nowadays, modular and mobile robots are becoming more and more popular to solve the dynamic and complex tasks on construction sites. The low cost and easily implementable LoRa-enabled device gives solutions to enhance the mobility and remote communication of these robots. The scalability of the modular robot provides standardized APIs for function extensions. As a result, the LoRa-enabled device with various sensors can easily be attached to the construction robots.

The previously mentioned network and data architecture formed the foundation for many other applications. This study researched the potential of other on-site use cases. For example, by embedding the LoRa-enabled device, a mobile logistic robot is able to move around on the 10.000 m$^{2}$ RCS with constant communication to the servers and central databases. The real-time battery status and loading data of this modular robot can be collected by a current sensor and a load cell sensor to detect abnormal working situations. Consuming low battery energy, the embedded LoRa device can utilize the battery of the robot directly with little impact on the previous energy consumption. Additionally, the network connection status and signal strength of the LoRa device are also important indicators to monitor equipment theft or damage.

To test the connectivity of LoRaWAN, the following section presents the test results of the logistics and task scheduling system as a concept validation.

4 Results and challenges

4.1 Test runs between the RCS and the BRL

This section presents the results of two 2-h test runs of the GPS device. Using OTAA and Class A, the GPS device travelled back and forth between the RCS and the BRL with the LoRa gateway respectively at the height of 5 m and 1 8m on the construction crane. With a video recording on the dashboard, real-time location of the device on the OpenStreetMap¹² was captured and network performance data was recorded, such as signal quality - RSSI (Received Signal Strength Indication) and SNR (Signal-to-Noise Ratio), details of uplink and downlink messages etc.

The LoRa RSSI indicates the received signal power by a receiver from a sender and is normally a negative value measured in dBm. For example, if the RSSI has the value of − 30 dBm, then the received signal is strong, on the contrary, − 120 dBm means very weak (Roland et al. 2019).

The LoRa SNR represents the ratio between the received power and the noise floor power level, which is measured in dB and typically range from − 20 to 10 dB. Table 3 shows the limit of LoRa SNR according to the SF number. If the value is under the SNR limit, the receiver can not receive the signal from the sender. SF7 was chosen in the tests of this study, which means, theoretically, a successful packet transmission will only happen when the SNR value is above − 7.5 dB.

Table 3 The limit of LoRa SNR according to the SF number (MobileFish 2018)

Figure 13a–c demonstrates the comparison of the planned route (from RCS to BRL, then back to RCS) and the recorded routes in the two test runs. The main roads for city transportation between the two sites were chosen in the tests. The actual recorded routes were shown in the form of polylines, because the device only updated new information every 20 s. As a result, every break point of the polylines was the time when the server received an uplink from the GPS device. It is important to mention, although the 20 seconds was programmed in the code, the actual update interval was strongly dependent on the actual quality of the radio signal.

Fig. 13

Comparison of the planned route and the recorded routes in the test runs

In Fig. 13b, with the gateway at 5 m-mounted at the top of a container, the entire planned route can not be covered by the LoRa signal. At several points, it took more than 120 s for the server to receive a new uplink message. When the GPS device reached the first blue circle in Fig. 13b − 1.36 km away from the gateway, the server completely lost the updates from the device. Even when the device went back in the coverage range, the device failed to rejoin the LoRaWAN automatically. After 30 min of lost traveling until the second blue circle, a manual reset helped the device join the LoRaWAN again.

In Fig. 13c, with the gateway at 18 m mounted at the top of a crane, the LoRaWAN kept receiving uplinks from the device along the planned route. Although transmitting time was longer when the signal became weaker–longer at the BRL, shorter at the RCS, the network covered the whole transportation area successfully. The furthest distance in the tests was 1.5 km away from the gateway.

In the downlink tests, the gateway at 5 m showed a failure of the device to receive any downlinks at many locations. Figure 14 presents the results of the success and failure of sending uplinks and receiving downlinks at different locations. Corresponding SNR and RSSI at these locations were shown in Fig. 14 as well. Several critical points in the tests can be defined as: receive interval longer than 120 s; failed to receive downlinks; completely lost signal. A rough assumption can be drawn from the recorded SNR and RSSI of these critical points that (a) failure of receiving downlinks occurred when SNR under around − 5 dB and RSSI under around − 110 dBm, (b) lost of signal occurred when SNR under around − 8 dB, RSSI around around − 116 dBm (Fig. 15).

Fig. 14

Example results of the uplink and downlink tests

Fig. 15

Critical points and thresholds of the signal

With the gateway at 18 m “better line of sight between the sites and the installed gateway, the uplink transmission kept a relative stable interval around 20–40 s and downlinks were received successfully around the BRL and the RCS.

The web-interface and data architecture performed well as planned in searching the available devices, assigning new tasks and transferring data across lists and databases. Nevertheless, critical problems still existed in the LoRa part of this application, such as the lost package rate of 20% at the location of the BRL, while at the RCS the lost package rate was 5%.

4.2 Conclusion and Improvement

In conclusion, the LoRaWAN on the RCS showed great application potentials of intra-site-networking in this study. For the cost, the price of an outdoor gateway is no more than 300 ${\EUR }$ and each node costs around 50 ${\EUR }$, which makes the large scale of deployment quite affordable for a construction project. Although LoRaWAN can not serve all the communication needs for construction sites, it performs really well in the long range data communication with small size data and increases the data availability to all authorized members of the team. Additionally, the LoRaWAN shows the ability to improve not only the communication internally but also the global communication with clients and suppliers with its special network architecture, which will be further developed in the next phase of the research.

The summarized challenges of the tests in this paper are shown below for further improvement:

• 1. Higher lost package rate happened at the locations, which were either far away from the gateway or with many obstacles in the Fresnel zone;

• 2. Due to the actual height difference in altitude, the gateway was not positioned high enough, although mounted on the top of the crane;

• 3. Only a few devices ran between the two sites. It is unable to test the limitation when more devices enter one LoRaWAN;

• 4. Adaptive data rate was disabled to ensure a fast and stable uplink or downlink, however, this also weaken the strength of signal for longer distance;

• 5. Lost device can not rejoin the LoRaWAN automatically until manually reset;

• 6. The GPS needs time to fix the position after every reset. The length of fixing time depends on the clearance of the sky.

The possible improvements for an in-depth study are listed accordingly:

• 1. Design a smart application system which has tolerance and coping mechanisms to the technical shortcomings of LoRa Network. For example, in the current task scheduling system, unconfirmed tasks are stored in a temporary list, it will be returned to the original list and then reassigned when no feedback received by the system within a certain amount of time;

• 2. Optimize the position of the gateway as well as the position of the device, or consider a concept with more LoRa gateways around the city when possible;

• 3. Prototype more devices to the test the LoRaWAN capacity;

• 4. Develop an algorithm to set adaptive data rate to 0 or 1 according to the real-time signal strength;

• 5. Develop an algorithm to rejoin the network automatically;

• 6. Reduce the GPS fixing time by changing related parameters or replace with a better GPS.

5 Future development

As mentioned in the previous sections, LoRaWAN offers an efficient, flexible and economical solution for long-range data communication of sensors, actuators and tags, which are also crucial components in construction robots and automated machines. This paper demonstrated the feasibility and tested the performance of the deployment of LoRaWAN on the construction site for intra-site communication, which leaves a huge research space for other suitable use cases. Due to the limitations in technical characteristics of LoRaWAN, the suitable applications are limited to small-volume and high-latency data use cases, for example, real-time monitoring of machine status, automatic warning of theft events on rented equipment, predictive maintenance of robots and so on. The fundamental study of the LoRaWAN in the automation of construction logistics aims to provide the network performance data for further development on other automation application in construction, which makes effort to promote the digitization transformation of the construction industry.