LoRaWAN networks offer the availability of several communication patterns, ranging from unidirectional to bidirectional ones, from synchronous to asynchronous ones. So far, such flexibility has not been studied as whole. The needed interaction with delay-tolerant satellite links, and the mobility of the gateway in the LEO-based scenario, put a strong constraint on the design of these communication patterns.

LoRSAT will design synchronization and scheduling techniques that ensure successful delivery of (group of) ACK and downlink traffic, taking into account gateway mobility, satellite network conditions, SFs options and duty cycle limitations. LoRSAT will investigate how to combine Class B and Class A devices functionalities, and use reserved slots to receive ACK (or data) that could not be delivered within the receiving windows.

According to the current implementation of the LoRaWAN standard, all the LoRaWAN gateways within the transmission range of a given end-device, receive the frame that it transmits. Those that are able to correctly decode the frame and extract the encapsulated payload, forward it to the remote server. This will result in several copies of the same data sent over the satellite link. And it may translates into waste of bandwidth over the satellite return channel; and longer latency to delivery all the copies to the network server, and receive the ACK back.

LoRSAT will investigate more efficient techniques that allow selecting a priori a subset of gateways (among those in the visibility of the end-device), which communicate with the network server, over a GEO satellite link. The selection of the subset of gateways may be operated according to the network conditions (collision, interference) on the satellite channel, and application requirements (high reliability, packet loss tolerant, etc.).

While LoRa and LoRaWAN are implemented respectively at the PHY and MAC layer, the data generated by the end-devices will be encapsulated into an application protocol, to be accessible to the application server. LoRSAT will compare different IoT application (MQTT, CoAP) and transport protocols (TCP, UDP), running on top of a LoRaWAN network, study their impact on the e2e system performance (in term of traffic overhead, delay, etc.) and propose appropriate cross layer optimisations over the satellite backhaul network.

A number of simulators, accounting for different LoRa PHY layer characteristics as well LoRaWAN MAC behaviour have been developed and used in literature for testing the LoRaWAN network performance. Most of them are NS3 (Network Simulator 3) compatible, being NS3 one of the most common used network layer simulator.

LoRSAT will leverage on NS3 and its extension for satellite networks (Satellite NS3, SNS3) to simulate the entire LoRSAT network system. It will add support for LoRaWAN multi-gateways scenarios, for downlink traffic, and acknowledge uplink/downlink traffic, as well support for LEO satellite, currently not fully implemented in SNS3.

The successful demonstration of the LoRSAT capabilities at simulation level will be completed by the development of a proof-of-concept (PoC). The PoC aims at reproducing the monitoring of the precision agriculture scenario, e.g. collection of IoT data from LoRa end devices deployed in a large scale field, and transmission over satellite to the remote server, through the gateways. Prototyping products offering exceptional flexibility to introduce the protocol modifications proposed by LoRSAT, will compose the network infrastructure of the PoC. Finally, LoRSAT will rely on the satellite OpenSAND emulator  to reproduce the satellite backhaul.