Low Power Wide Area Networks (LPWAN) are a relatively new class of wireless communication systems designed for long-range and low-power performance. There are several LPWAN protocols like SigFox, DASH7, NB-IoT and LoRaWAN[7815384, gao2019towards]. Of these protocols, LoRaWAN is gaining much traction from industrial and academic communities due to its low deployment costs and flexible network-layer protocols. LoRaWAN realises relatively long-range wireless communications (e.g. 2 km in urban and 15 km in rural) via sub-GHz frequencies (e.g. 868 MHz in EU and 915 MHz in North America). However, nodes operating in the EU need to adhere to low duty cycle operation ( or )[LoRaWAN] and practical mobile communications scheme must adhere to this.
Much work has been done to improve throughput and reduce delays in LoRaWAN networks generally. Most of these works, however, assume that nodes and gateways are static and do not consider mobility. There is a rising class of applications that require low-power mobile solutions to provide new services, e.g. asset tracking. Semtech, the company that proposed LoRa technology, has also been designing new gateways to support nanosecond precision timestamps for acquiring geolocation information from LoRa-enabled devices for tracking scenarios. Under mobility, radio channel states vary as locations and environments change over time. Radio channels can be unreliable due to obstacles or deep fading, which can further depend on weather conditions, line-of-sight to base stations being blocked, or the speed of the vehicle hosting the data source. The low duty cycling (i.e., 1% for general data channels) regulated by LoRaWAN specification makes this situation more challenging still. If a device misses its allocated time slot for communication, it needs to wait minutes if not hours before it can upload its data in the next round, thus causing significant delays to data delivery. Consequently, new and/or improved protocols are required to ensure on-demand delivery of information during movement.
Here, instead of trying to send data via unreliable radio channels to gateways or awaiting for next gateway contact, LoRaWAN devices can send their data to gateways via other nearby devices that have better quality contact with gateways. As the capability of communicating through long-range LoRa is typically more significant than actual device mobility, it is easier to find reliable neighbours for data forwarding than retain unsent data awaiting a good connection with a gateway. By exploiting this observation, we propose two new opportunistic data forwarding approaches which can effectively reduce data delivery delays and improve network throughput.
In the first approach, we introduce a new network metric to drives decision making in terms of the helper devices chosen to forward data through - namely, Real-time Contact Aware Expected Transmission Count (RCA-ETX). This new metric can seamlessly illustrate device mobility with packet transmission delay, which is widely accepted in many objective-function-based data forwarding protocols. Furthermore, we extend RCA-ETX by combining it with a throughput-optimal stochastic backpressure scheme, and propose Real-time Opportunistic Backpressure Collection (ROBC). ROBC can cope better with uncertain links in mobile scenarios, and delivers improved performance compared to RPL with RCA-ETX. Importantly, RCA-ETX and ROBC can operate without prior knowledge of device mobility. Finally, to ensure our approaches are compatible with other LoRaWAN enabled devices, we propose two new LaRaWAN classes, namely Modified Class-C and Queue-based Class-A, to support device without and with energy constrains, respectively. Both of the proposed classes are compatible with LoRaWAN Class-A, which must be supported by all LoRaWAN enabled devices.
To demonstrate the effectiveness of RCA-ETX and ROBC, we evaluate the performance of RCA-ETX and ROBC with extensive data-driven experiments using the London Bus network [TFLOpen]. Our experimental results show that the solution can effectively reduce delays by up to in both urban and rural areas, while giving a throughput improvement up to with an overhead of up to 2.2 times the number of messages.
The rest of this paper is organised as follows. Section II discusses related work. Section III introduces the background to this work. Our main contributions, RCA-ETX and ROBC, are explained and proposed in Sections IV and V, respectively. A discussion on practical implementations and performance evaluation is given in Sections VI and VII, and we conclude the paper in Section VIII.
Ii Related Work
Opportunistic data forwarding in mobile LoRaWAN networks is a relatively new topic. In this section, we briefly review the recent research on mobile LoRaWAN networks and opportunistic data forwarding in wireless networks.
Ii-a Mobility in LoRaWAN
Low Power Wide Area Networks (LPWANs) have gained serious traction in the last decade. There are a number of works that compare state-of-art LPWAN protocols (e.g. LoRaWAN, Dash7 and NB-IoT) and evaluate how different stages of the protocol affect performance[7815384, 8254509, 8407095] and how parameter settings (e.g. spreading factors and listen-before-talk) affect the performance such as delay and data throughput [Liando:2019:KUF:3311822.3293534]. In Internet of Mobile Things, the authors do a comparative analysis of LoRaWAN, Dash7 and NB-IoT. They discuss mobility considerations and which of the three protocols are suitable for which application areas. Their results show that all of them are useful for certain use-cases and that LoRaWAN is better suited for applications like pallet tracking that require low cost, extended battery life, uplink only communication and long range coverage.
However, mobility also results in new challenges when applied in real-world scenarios. For example, Petjjrvi et al. show that velocity has an observable effect on the packet delivery ratio for speeds higher than 25 km/h due to Doppler effects [doi:10.1177/1550147717699412], while Marcelis et al. find the relationship between packet delivery ratio,mobility and distances between devices and gateways . Without reliable links between mobile devices and gateways, opportunistic data forwarding between nearby devices becomes a potential solution.
Ii-B Opportunistic Data Forwarding
In the areas of Internet of Things (IoT) and Wireless Sensor Networks (WSNs), many recent works have focused on finding fast and reliable ways to forward data given a network where the devices therein are mobile [cai2013routing, condi2014mobile]. One notable direction focuses on data forwarding in networks consisting of static sensors and mobile sinks [kusy2009predictive, li2011ubiquitous, lee2010whirlpool]. In these networks, resource-constrained sensors are typically disconnected from the Internet and have limited communication capability. These sensors therefore try to maximise the opportunity of forwarding data via nearby mobile devices (e.g. mobile phones) which have a direct connection to the Internet. Some recent works try to find the better opportunistic routes maximising the probability of successful data forwarding [tahir2017brpl] without making any assumption on mobility. Yang et al. [yang2017practical] proposed a new metric, contact-aware ETX (CA-ETX), to seamlessly merge mobility into classic scheduling protocols (specifically RPL and backpressure routing). However, their work focuses on networks which consist of mobile sinks and static sensors, and it relies on reliable radio channels and high duty-cycle communication between sensors.
Another notable direction focuses on data forwarding in disconnected mobile ad hoc networks consisting of static sinks and mobile devices where connections between them are lossy [cai2013routing, pelusi2006oppurtunistic, yuan2015hotspot]. Some recent studies exploit node contact patterns to reduce delays and improve successful data forwarding[tornell2015dtn]. These patterns can be generated based on devices’ historical motion paths [zhu2013scaling] and social behaviours[zhu2014social, zhou2017predicting]. [zhou2013exploiting] further takes duty cycles into account by assuming that devices may not be able to communicate with each other at every physical contact when they can communicate. However, these solutions rely heavily on extra information, such as geographical information and social behaviours, which are challenging to obtain and process for resource-constrained LoRa devices.
In this section, we first provide a formal definition to the Mobile LoRaWAN network with static sinks (MLoRa-SS). We then give a brief description of the LoRaWAN communication specification. Finally, we briefly describe the contact-aware ETX, the foundation of our approach, and the reasons why it cannot be directly applied to MLoRa-SS.
Iii-a System Model of MLoRa-SS
Unlike standard LoRaWAN networks, which consist of only sensor-to-sink links in a star topology, in our Mobile LoRaWAN network with static sinks (MLoRa-SS), we assume devices (i.e., LoRa end-devices therein) may move over time. Take the London bus network as an example: the average bus speeds for different routes varying between 5.4 mph and 23.1 mph. In MLoRa-SS, we aim to provide a solution that allows devices to send their data via other nearby peer devices if their direct connection to their sinks is currently weak or unavailable.
To better illustrate the dynamics of MLoRa-SS, here we give a formal definition. MLoRa-SS can be modelled as a time-varying weighted graph . In this graph, denotes all nodes in an MLoRa-SS, where denotes the set of all devices (i.e. LoRa end-devices) generating and relaying data packets, and is the set of all sinks (i.e. LoRaWAN gateways) collecting data packets from the network. denotes the set of all possible wireless links. While denotes the link between node pairs , each entry in represent the virtual links between a node and all sinks . denotes a -dimensional matrix representing the channel capacities over all wireless links between nodes at time . Each entry is dynamic and may change overtime. Figure 1 illustrates an example of .
Iii-B LoRaWAN Communication Specification
In order to run our solution under MLoRa-SS, we need to ensure our solution is compatible with the LoRaWAN specification. LoRaWAN relies on one-hop broadcasting via LoRa RF technology which is formally regulated. The overall device-to-sink link capacity of each LoRa devices is very low. When a node selects general SRD and SF12/125kHz defined in LoRaWAN specification, the maximum link capacity for such node is only 2.5 bit/s with duty cycle. Bi-directional communication between a device and a gateway under such constraints are defined in LoRaWAN specification as three device types [LoRaWAN]. All LoRa end-devices must implement Class A, whereas Class B and C are extensions to Class A as illustrated in Figure 2.
As can be seen, Class A devices open two receive windows at specific times (i.e. 1s and 2s) after an uplink transmission. A gateway can respond either in the first window or the second window. Class B devices reduce delays in down-link communications extending Class A by adding periodic receive slots. Class C devices extend Class A by keeping the receive windows open unless they are transmitting. It has the lowest delay but is less energy efficient.
Node to node communication in LoRaWAN can be enabled if sensors overhear packets from other nearby sensors for information exchange and receive window. In this work, LoRaWAN devices use a modified Class-C device. The nodes are always listening to a shared channel to overhear packets from each other and only switch channels to receive an acknowledgement from the gateway. We also explore the idea of Queue-based class-A to reduce the energy used by the nodes. In Queue-based class-A the length of receive slots is decided based on the number of messages in queue.
Iii-C CA-ETX and Challenges when applying in MLoRa-SS
Contact-Aware ETX (CA-ETX) [yang2017practical] is a network metric that extends Expected Transmission Count (ETX) [de2005high], which is a widely accepted network metric used by many routing and scheduling protocols in Wireless Sensor Networks (WSN). It takes mobility in WSNs into account when making scheduling and routing decisions and is designed for WSNs with mobile sinks (WSN-MS).
Although CA-ETX provides a novel way to incorporate mobility in the computation of ETX seamlessly, it cannot be directly applied in MLoRa-SS due to the following constraints:
Opportunistic contact in between sensors. CA-ETX is designed for WSN-MS, where sinks are mobile while sensors are assumed static. In contrast, in MLoRa-SS, sensors are allowed to move, while sinks are static. Therefore, routing protocols such as RPL or BCP may never converge to a stable routing gradient and consequently cannot provide guarantees such as minimal delay in RPL and maximum throughput in BCP.
Low maximum duty cycle and limited bandwidth. As presented in Subsection III-B
, the maximum duty cycle and link capacity are regulated under LoRaWAN specification. Therefore, sensors in MLoRa-SS are not able to exchange information periodically as in WSN-MS. This prevents nodes from obtaining necessary information of one-hop neighbours with sufficient frequency. Consequently, when computing CA-ETX, historical varianceand average are likely to be outdated, which can significantly degrade overall routing and scheduling performance.
Thus, a new network metric that copes with sparsity of information and node mobility is needed.
Iv Opportunistic Data Forwarding with RCA-ETX
Contact-Aware ETX (CA-ETX) has been proven effective in Wireless Sensors systems (WSN-MS), which are similar but very different as they consist of static sensors and mobile sinks only [yang2017practical]. Although CA-ETX is not directly applicable in MLoRa-SS, we were inspired by CA-ETX and propose an approach based on a new metric called Real-time CA-ETX (RCA-ETX). This solution overcomes the uncertain nature of MLoRa-SS while inheriting the simplicity and effectiveness of CA-ETX when being used with protocols such as RPL, which base their scheduling decisions on a gradient using an objective function.
Iv-a Operation Overview of Data Forwarding with RCA-ETX
LoRaWAN operates in the unlicensed spectrum and as such must adhere to the EU duty-cycling regulations. This means that devices in MLoRa-SS cannot send messages except in their allocated time slots. This makes opportunistic routing via neighbours much more challenging. The only permitted way of finding a neighbour to route through opportunistically is via overhearing. Consequently, given a device , it can only find another device when receiving (i.e. overhearing) broadcast messages from .
Here we first give a high-level overview of our solution. Given a mobile device , its opportunistic neighbour is defined as . On receiving a broadcast message from an opportunistic neighbour at time , computes the RCA-ETX of that link . Given denotes the RCA-ETX of the link in between and sinks , if the value of is larger than , tries to send the data stored in its queue to ; otherwise keeps holding the data until next sending opportunity, which can be either its next sending slot or on receiving another broadcast message from another nearby device.
An example of such an operation is demonstrated in Figure 3, where device broadcasts its when trying to upload data to the sinks . This message can be overheard by its opportunistic neighbours , who have no direct connection with the sinks at time , and . On receiving from , device computes of link at every time , and decides to handover its data to at after confirming that the overall RCA-ETX value of is smaller than , that is:
It is worth mentioning that, for simplicity, in the following section, Class C [LoRaWAN] is adopted to ensure successful overhearing and device-to-device communications. Further works on reducing energy consumption will be presented in Section VI.
Before introducing , we need to first define Packet Service Time (PST). Given a node and a set of gateways in MLoRa-SS, virtual link can be regarded as a queue with time-varying PST , which is the time duration for a packet to be successfully transmitted via link at time . For every virtual link PST, is computed at the beginning of every time slot reserved for its device-to-sink communication. This can be computed as
where and denotes the first and last time slots of -th contact between and any sink , respectively.
Here PST is regarded as the combination of transmission time (i.e. the PST when node in its ()-th contact with sinks) and time delay (i.e. time required before next sink contact). However, when computing PST, is not available when . To overcome this problem, we introduce a Real-time PST (RPST) , which is computed as below:
where denotes the device-to-sink communication interval, which is a given parameter; and denotes the wait time before can broadcast a message via .
Figure 4 illustrates an example of computing . As can be seen, given a device , we use estimated delay (i.e. ) instead of actual delay (i.e. ) that cannot be acquired. It is worth noting that devices use the capacity acquired at the previously successful transmission time slot or , since is also not available.
can now be acquired from at time . However, since devices are mobile and run at low-duty cycles in MLoRa-SS, the opportunity of transmission is much lower than the probability of topology changes in . Therefore, instead of the long-term average, we compute as exponentially weighted moving average (EWMA) as below
where denotes a parameter that controls weight in between current RPST and last RPST computed at previous time slots. The higher the , the faster the RPST adapts to current RPST; however, this will reduce the overall scheduling stability. For further discussion on this parameter, we refer readers to our evaluations in Section VII.
In MLoRa-SS, each device must obey the maximum data send rate (i.e. 1% duty cycle for most general data channels) regulated with a relatively long interval (e.g. ). As a result, given a link , we should not use the long-term average to estimate link capacity as in classic ETX. Our solution here is to estimate the link capacity as per RSSI values, which is available on receive broadcast message from other sensors. With the RSSI value , can be computed as
where denotes the RSSI value above which should achieve its maximum capacity ; RSSI value below which has minimum capacities (i.e. bits/s).
This equation is frequently used in many implementations such as the link stack in Contiki [dunkels2004contiki]. Users may replace Equation (5) with a hyperbolic function as per requirement; however, here we keep it simple as a proof of concept. Consequently, can be simply computed as follows:
V Real-time Opportunistic Backpressure Collection (ROBC)
The approach proposed in Section IV can be regarded as a greedy solution which tries to forward data via a neighbour with a shorter potential delay (i.e. smaller RCA-ETX). However, this shortest-path approach typically suffers from poor throughput performance [tahir2017brpl]. Furthermore, frequent topology changes also make it less effective for finding better candidates for data handovers. In contrast, solutions based on queue length (e.g. BCP) have proven more effective when coping with the uncertain dynamics of mobile scenarios[tahir2017brpl, yang2017practical].
In this section, we propose another solution by integrating RCA-ETX with backpressure algorithm for MLoRa-SS.
V-a Queue Dynamics
In MLoRa-SS, we assume each device generates amount of new data at time over the past time interval . Each device maintains a queue (i.e. data buffer) to store data that cannot be forwarded due to no viable route to the sinks . Let be the queue length of at time slot . Given a device , from time to , its queue length is updated as below:
where denotes an non-negative operator where given a real number (i.e. if , otherwise ); and are the amount of total incoming and outgoing data of device in between time and , respectively, which is defined as follows:
where denotes all ’s opportunistic neighbours (from which receives their RCA-ETX broadcast) over time and ; denotes the amount of outgoing data from to over and .
V-B ROCB Algorithm
The operation of ROBC is similar to what was proposed in Subsection IV-A. Given a device , it broadcasts its and queue length at every interval. When a device overhears this packet, it computes its ROBC weight and decides whether to pass data to or keep the data in its queue.
V-B1 Weight Calculation
Given a device , it broadcasts its RCA-ETX and queue length at every interval. When device overhears this packet, it computes its ROBC weight as
Here is called Real-time Gateway Quality (RGQ) of device . An upper bound and a lower bound (i.e. ) should be given for all sensors to guarantee ROBC stability [yang2017practical]. The intuitive idea behind RGQ is similar to PST proposed in Subsection IV-B. Since can be regarded as the average rate sensor a node sends its data to the sinks, it is exploited as a modifier to correct original queue lengths (i.e. how long a packet will have to wait until it is served).
V-B2 Opportunistic Scheduling and Data Forwarding
Based on ROBC weight computed in Eq. (10), device decides whether to handover data stored in its queue to device . If , forwards amount of data to , otherwise it keeps all of its data. This can be regarded as a scheduling problem where node decides to forward its data via an opportunistic neighbour or via itself by comparing ROBC weights to .
It is worth mentioning that traditional queue-based approaches utilise full link capacity for every transmission opportunity. However, due to the low duty cycle and the sparsity of available links in MLoRa-SS, devices only send amount of data to reduce recursive loops (where data packets are sent back and forth between two devices). Therefore, device will not send data received from back even if hears from before its next forwarding opportunity to the sinks.
Vi Customised Device Classes for Practical Operations
For simplicity, our solutions proposed in Section IV and V assume all devices use the Modified Class C extended from the specification [LoRaWAN] to ensure that device-to-device communications are always available as demonstrated in Subsection III-B. In addition to Modified Class C, we further enhance the practicality of our solution and propose a new queue-based Class A to accommodate adaptive duty cycling that saves energy as to its queue modified with RCA-ETX as in ROBC. The operational overview of these two classes are demonstrated in Fig. 5.
Modified Class C operates in a similar manner to original Class C with one change. Instead of opening its receive slots for downlink communications from gateways (i.e. Rx2), it listens to its Tx channels (i.e. Rx1) to overhear the Tx from other nearby devices within communication range. This design is compatible with LoRaWAN Class-A, which should be supported by all LoRaWAN-enabled devices.
Queue-based Class-A is a dynamic approach where the length of each receive window is adapted to the size of the local data queue, which is naturally compatible with ROBC. Given a device and time , the length of each receiving window is defined as , anywhere is computed from the local queue length as follows:
where is the maximum queue size of device . The intuition behind this approach is summarised as follows: Since devices in MLoRa-SS are mobile and the opportunity to have opportunistic neighbours is stochastic, we argue that the longer the receiving window, the higher the probability for a sensor to receive broadcast messages from its opportunistic neighbours. Therefore, for the devices that have longer queues (i.e. higher ) and longer RCA-ETX (i.e. larger ), longer receiving slots are required to increase the probability of forwarding their data packets to the sinks. Again, this class is compatible with Class-A specification of LoRaWAN.
Vii Evaluation based on London Bus Network
In this section, we describe our experimental setup, communication network, evaluation metrics and present the results of our simulations.
Vii-a Experimental Setup
LoRaWAN is suitable for long-distance, low data-rate communication, and so it is particularly suitable for many urban or smart city scenarios. The primary goal of our opportunistic data collection protocol is to collect data in areas of low coverage or over-used spectrum. One of the most suitable use-cases is logistic networks, where LoRa devices are attached to high-value parcels to track and report their conditions in real-time.
To simulate logistic networks, we choose London for our evaluation as it is representative of a large-scale city. We evaluate our protocol in a 600 km area with 24-hour simulations.
Vii-A2 Bus Network
To simulate the mobility of logistic networks in such a large-scale area, we choose the trace-driven London bus network illustrated in Figure 6 for our evaluation. The dynamic nature of this bus network provides an iconic example of a complex vehicle network, where the distances between buses and gateways change with the speed of each vehicle. For our evaluation, we collect the routes from the London bus network based on the dataset provided by Transport for London (TFL) [TFLOpen]. This dataset consists of the timetable recorded from real-world for each route, based on which we can simulate the mobility of each bus. The total number of active buses and their travel time distribution are illustrated in Figure 7 (a) and (b), respectively.
Vii-A3 Simulation Framework
We use the SUMO simulator [lopez2018microscopic], widely used in ad-hoc traffic network research community, to create our mobility network. SUMO is a microscopic and continuous traffic simulator designed to handle large road networks. The system takes the map and bus information, like start time, stop time and frequency, to create the buses. All the communication networks are simulated in OMNeT++ using FLORA[Slabicki2018]. For every bus generated by the SUMO simulator, a corresponding node is also created in OMNeT++.
Vii-A4 LoRaWAN Network
In our simulation, LoRaWAN is a one-hop communication network where all nodes can communicate with any gateway in the network. All the gateways are connected to a single central server (network server) where all the data is collected via Ethernet. Every bus in the simulation is equipped with a LoRaWAN device. These devices generate a 20-byte message every 3 minutes and store it in a first-in-first-out (FIFO) data queue. The devices are half-duplex, and so they are in a receive state unless they are transmitting. The nodes use modified Class-C. They are always listening on one channel which is the normal data transmission channel instead of the channel dedicated for downlink traffic.
Vii-A5 LoRaWAN Physical and Network Parameters
In [ADRMobility], the authors prove that the benefits of Adaptive Data Rate of LoRaWAN decrease as mobility increases. For this reason, we use a single spreading factor (SF) 7 (where maximum data packet size is 255 bytes for our experiments). We also use one channel for transmission instead of multiple channels to increase the probability of overhearing a message. We use the log-distance path loss model with shadowing as the physical layer model with a path loss exponent of 2.32 as it is representative of a sub-urban environment for LoRa communications . Upon message generation, devices select up to 12 messages from the queue and create a new data packet. They also append their RCA-ETX value and data queue size to the data packets before transmissions. If any gateway successfully receives the packet, it sends an acknowledgement to the devices. We assume that the acknowledgement messages are delivered instantly. If the packet fails, the nodes try to retransmit the message after the duty-cycle timer of 1% time-on-air runs out. Every device tries to transmit every message up-to eight times unless it generates a new packet in which case it resets the retransmission counter. Since the nodes are all using the same SF7 and listening on the same channel, they can overhear all the messages transmitted in their neighbourhood. Upon message reception, devices can choose to forward part of their queue or ignore the reception based on the chosen data forwarding scheme.
Vii-A6 Network Deployment
The gateways are deployed in a uniform grid instead of a randomly deployed topology. Although it is highly unrealistic to have a perfect grid, it is challenging to discern the performance gain either from gateway locations or our data forwarding protocols if gateway locations are randomly chosen. The gateway-to-device communication range was set to 1 km for an SF7, and we use 0.5 km and 1 km to simulate device-to-device communications in an urban (where signals are likely to be blocked by buildings) and rural environments, respectively.
Vii-A7 Schemes evaluated
In this work, we evaluate three different schemes.
NoRouting: We use the modified Class-C as described in Sec.VI. In addition, we introduce a queuing system at the application layer. The nodes keep all messages in queue that were not acknowledged. At every transmission, the nodes transmit a maximum of 12 messages from its queue in a data packet.
RCA-ETX: In addition to the NoRouting scheme, the nodes also append their RCA-ETX value to the data packet. Based on the value of this metric, the nodes decide whether to forward data to another node or not.
ROBC: In addition to the NoRouting scheme, the nodes also append their RCA-ETX value and queue lengths to the data packet. Based on the value of this metric, the nodes decide whether to forward data to another node or not.
Vii-B Simulation Results
In this subsection, we compare RCA-ETX and ROBC proposed in Section IV and V, with modified LoRaWAN without data forwarding in MLoRa-SS. The moving average parameter, that is in Eq.(4) was set to . Two metrics below are used in the rest of the evaluations.
End-to-end delay. One of the major contributions for our approaches is to reduce end-to-end delays by utilising nearby LoRaWAN devices for data forwarding. This end-to-end delay is measured by , where denotes the time when message is generated, and denotes the time when message is received at the server.
Throughput. In contrast, throughput is a typical trade-off for the delay. This throughput is measured by the number of messages received at the server in a certain period.
We evaluate our approaches in networks with different gateway densities. The number of gateways deployed in the area illustrated in Figure 6 is varied from 40 to 100. Also, to simulate the MLoRa-SS networks in both urban and rural environments, the device-to-device communication ranges were set to 500 m and 1000 m, respectively. Figure 8 depicts the average end-to-end delays. As shown, RCA-ETX and ROBC successfully reduce 10%-25% delays compared to original LoRaWAN without data forwarding in both urban and rural settings in lower gateway densities. However, they are less effective when gateway density increases (e.g. scenarios with 90 and 100 gateways). According to our analysis, this is because RCA-ETX is computed based on real-time PST depicted in Eq.(3). This equation exploits past information to estimate the next successful gateway contact in the future, leaving higher errors when gateways are deployed in a grid topology. It is also worth mentioning that the performance gain in the rural environment is not as significant as expected. More extended device-to-device communication range only contributes to the scenarios where the number of gateways is less than or equal to 50.
It is worth mentioning that all three approaches yielded longer delays when the number of gateways was set to 80. Accordingly to our analysis, we realised that the density of our grid has significant impacts on gateway locations, which further impact delay and throughput. When the number of gateways equals to 80, their locations were less accessible for the buses (given their fixed route and mobility) compared to some other networks consist of fewer gateways. However, we can still observe that RCA-ETX and ROBC still outperformed standard LoRaWAN without data forwarding.
Figure 9 depicts the total throughput of the network under the same setting. As expected, RCA-ETX receives its performance gain by trading throughput. Fewer messages have arrived at the gateways. In contrast, by exploiting queue dynamics, ROBC not only reduces end-to-end delay but further improves throughput when being compared with original LoRaWAN. As to our observation, the improvement in throughput of ROBC is more significant when applied to rural scenarios where device-to-device communication reaches 1000 m, identical to device-to-gateway communication. The throughput increases by 38% on average for a network with 100 gateways.
Figures 10 and 11 illustrate the number of messages arriving at the gateways every 10 minutes over 24 hours. As can be seen, in urban environments, we observe RCA-ETX trades throughput for end-to-end delay performance. Meanwhile, ROBC can reach similar throughput performance as the original LoRaWAN while providing lower end-to-end delays. In rural environments, similar results are observed for RCA-ETX, while ROBC outperforms original LoRaWAN in both throughput and delay. Furthermore, higher bus density encourages better data forwarding between LoRaWAN devices, resulting in higher throughput when ROBC is applied. One can easily observe that higher performance gain in throughput for ROBC happens during the daytime (i.e. 20,000 - 75,000 seconds), where more buses are active as shown in Figure 7 (a). The throughput achieved is up to 53% higher compared to original LoRaWAN with 100 gateways in the rural environment.
Figure 12 shows the average number of hops a message travels before reaching its destination. As can be seen in the figure, all LoRaWAN messages have a hop count of 1. The average number of hops with ROBC is higher than RCA-ETX for large number of gateways. This shows that on average a message travels 5-6 hops. The result shows that a gateway has to listen to less number of nodes at the same time as a lot of messages are bundled together before reaching the gateway.
Figure 13 shows the average number of messages a node sends. This can approximate the energy overhead. In all our schemes, since the nodes are always listening to a particular channel to receive messages, we only consider the energy overhead as the additional number of messages sent by a node. The message overhead for RCA and ROBC is in the range of 1.6 to 2.2 times that of LoRaWAN. The network throughput can be improved by 53% by this scheme and so the energy overhead seems reasonable as it significantly reduces the load that a gateway would need to handle.
Vii-C Further Observations and Future Work.
Our chosen scheme uses a fixed spreading factor and one channel. As in [ADRMobility], the effectiveness of the adaptive data rate of LoRaWAN reduces as mobility increases. So, it may be better to use a single spreading factor for all buses instead of adapting it to the scenario. Our scheme is oblivious to the chosen spreading factor or channel number. As the number of spreading factors or channels used increases, the number of neighbours would reduce. We could in future optimise the system by implementing channel and SF sweeping algorithms to find neighbours using different settings.
Although we only report the results with grid-topology gateways, we have also run extensive experiments where gateways were randomly deployed. We observed that gateway locations have a significant impact on performance for these situations. Although ROBC almost always outperforms the other two approaches, significant performance variations were also observed. Since RCA-ETX and ROBC do not have prior knowledge of the mobility and gateway locations, they both rely on estimated delay instead of actual delay, resulting in errors when computing RCA-ETX values. For example, comparing with a LoRaWAN device which is moving away from gateways, a device moving towards the gateways might have higher delays (i.e. higher RCA-ETX value) since it had less contact with gateways in the past. Consequently, selecting better gateways positioning could be another valuable research topic where we aim to find the gateway location where can better support mobility and device-to-device data forwarding in both urban and rural environments.
In this work, we also assume acknowledgements have a 100% success ratio and gateways can acknowledge all messages. This assumption does not fit-well as gateways like end-devices have to adhere to duty-cycling. We plan to extend this work to add this duty-cyling regulation and also choosing the best gateway to acknowledge a message.
Energy is another topic worth studying in these handover systems. Our data forwarding algorithms between devices does help to reduce delay and increase throughput. However, it also requires a higher energy consumption. To this end, we implemented a Queue-based Class-A algorithm. The performance of that algorithm was on-par with the results described above, but less than 20% energy saving was possible. So our other objective is to propose better scheduling schemes to further reduce the energy consumption.
We proposed a metric to provide an indicator of connectivity to support improved resilience of LoRa based mobility which we term ‘Real-time Contact-Aware Expected Transmission Count’. It reduces latency while improving throughput for devices in Mobile LoRaWAN Network with Static Sinks (MLoRa-SS). We also proposed alternative routing through real-time opportunistic backpressure collection to handle the stochastic behaviours in MLoRa-SS. We performed experiments on the London bus network to demonstrate the relevance of our work to smart city applications. We showed that RCA-ETX could effectively reduce delays by up to 25% by trading throughput. Meanwhile, ROBC can provide similar delay reductions with 15% to maximum 53% throughput improvement against original LoRaWAN devices with up to 2.2 times message overhead.
RCA-ETX and ROBC are already contact-aware, accounting for prior communications with base stations in decision making. For future work, we will extend this data forwarding problem to determine better communications parameters for the LoRaWAN specification (e.g. spreading factors) to improve energy usage, important for LoRaWAN devices with limited battery capacity. We found that the selection of gateway locations has a significant impact on data transfer performance, with or without data forwarding in mobile scenarios. How to find better gateway locations that optimise data transfer performance is another topic worth studying.